Здравствуйте, quwy, Вы писали:
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
Здравствуйте, _ABC_, Вы писали:
_AB>Я бы поставил вопрос более конструктивно — не разумнее ли нанять приходящего специалиста для таких дел — администратора БД? :xz:
...который не применяет РСУБД для того, для чего они не предазначены — для временных рядов?
Ну-ну. Админ зачастую ставит просто обновления от разработчика, незабывая бэкапится.
Бэкап базы может идти часами, например на/с всё того же стриммера — всё упирается исключительно в доступные носители и их объем. "Резервный" сервант — это как правило полудохлая (в плане производительности) тачка (к примеру виртуализированная), и равняться на неё смысла не имеет, и ожидать чего-то огромного тоже.
Тестовая "реструктуризация" базы — это хорошо, но всё нужно делать со смыслом и при необходимости. Я такой тест проводил, но упаси боже проверять команды навроде drop index, обычно чистой прикладухи и так сверх головы хватает.
Из моей практике было так — тесты могли занимать около 5 часов, — в то время как то же самое на боевом — ~5-10 минут. При том задачи были в чём-то схожи (drop index был ), но была массовая реструктуризация базы вообще. С таким подходом разумеется ни о каких 5-10 минутах речи быть не могло в принципе, даже если изначально выбрать "правильный" путь.
Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
KDK>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
Это, кстати, один самых геморройных моментов мускуля — выбор движка.
Здравствуйте, Mamut, Вы писали:
KDK>>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
M>Это, кстати, один самых геморройных моментов мускуля — выбор движка.
Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде
Здравствуйте, Antikrot, Вы писали:
F>>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция. A>вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.
LOCK TABLES WRITE. Или репликация. А еще у них есть прокси, который умеет перенаправлять запросы по разным направлениям.
Здравствуйте, Sharowarsheg, Вы писали:
M>>Это, кстати, один самых геморройных моментов мускуля — выбор движка. S>Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде
Здравствуйте, Sheridan, Вы писали:
a>> Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
S>Да, я иногда умею завернуть так, что даже самому потом непонятно что хотел сказать
Здравствуйте, DOOM, Вы писали:
DOO>MySQL — хороший продукт. Просто имеет границы применимости. DOO>Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD.
Автор почему-то не стал делать — это правда, может просто ему Access не попался на глаза во время придумывания архитектуры.
То, что MySQL хороший продукт — усомнюсь. Ладно бы у них просто не было части функционала — это правда дает границы применимости, так у них же с заявленным функционалом бардак. Впрочем в enterprise мире пользуются и продуктами куда более плохого качества и не жужжат.
VV>То, что MySQL хороший продукт — усомнюсь. Ладно бы у них просто не было части функционала — это правда дает границы применимости, так у них же с заявленным функционалом бардак.
Что не мешает MySQL по распространенности делать любую другую бесплатную СУБД.
VV>Впрочем в enterprise мире пользуются и продуктами куда более плохого качества и не жужжат.
Не только в Enterprise. Можно привести кучу ситуаций, когда "мыши плакали, кололись, но продолжали жевать кактус".
Пока Postgre каких-то внезапных рывков в популярности не делает — значит по суммарному количеству параметров MySQL предпочтительнее.
Здравствуйте, Sheridan, Вы писали:
S>Ты — программист? S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Вот ведь жопошники эти программисты. Понакодили тут, еще вытворяют, идеи в головах видите ли. Нет чтоб как люди: прочел ман, поправил конфиг, и все завертелось! Романтика!
Здравствуйте, Anton Batenev, Вы писали:
f>> RO>nginx — наше всё! f>> Он уже научился правильно понимать HTTP-хидеры? AB>Например?
URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично. Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился?
Здравствуйте, fddima, Вы писали:
f> URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично.
Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding.
f> Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился?
Он достаточно быстро развивается и обрастает функционалом. Иногда даже кажется, что слишком много на него пытаются навешать.
Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
