Здравствуйте, Testator, Вы писали: T>А что тут смешного?
Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.
Здравствуйте, Mr.Cat, Вы писали:
MC>Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.
С кластерным индексам мсскл скорее имеют отношения оракловские index organized tables, не?
Здравствуйте, _d_m_, Вы писали:
_> S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет. _> AB>Да ладно — отлично работает, если его правильно работать. _> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.
Эту фразу можно применить к любому программному продукту.
Вот только проблема в подавляющем большинстве случаев не в MySQL, а в том, что люди не читают документацию (которая уж явно меньше BOL).
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет. _>> AB>Да ладно — отлично работает, если его правильно работать. _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.
AB>Эту фразу можно применить к любому программному продукту.
Вот уж нет.
AB>Вот только проблема в подавляющем большинстве случаев не в MySQL, а в том, что люди не читают документацию (которая уж явно меньше BOL).
Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция. И что перед этим надо делать копию ажно всей БД. Ну а чо, для большинства закоренылых MySQL-евцев это нормально. Потому что от этого, с позволения сказать продукта, всего можно ожидать.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Testator, Вы писали: T>>А что тут смешного? MC>Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.
Еще бы в Oracle не было, сложнее найти чего там нет.
Даже если подходящих индексов нет, сгенерируется искусственный уникальный. А если есть, возьмется либо primary key, либо первый UNIQUE NOT NULL. Пальцем в небо, но похоже это и есть причина проблемы с drop index.
Здравствуйте, lazymf, Вы писали: L>С кластерным индексам мсскл скорее имеют отношения оракловские index organized tables, не?
Ну да, по идее что-то в таком духе.
Приветствую, Vamp, вы писали:
V> S>Достатояно zfs, она сама будет делать. V> А ее в Linux портировали что ли?
Ты хотел сказать "А ее в ядро включили, чтоли?", да?
Здравствуйте, _d_m_, Вы писали:
_> _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли. _> AB>Эту фразу можно применить к любому программному продукту. _> Вот уж нет.
Ты готов озвучить безграбельный продукт?
_> Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция.
А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают.
_> И что перед этим надо делать копию ажно всей БД.
Здравствуйте, frogkiller, Вы писали:
F>Не на время работы с копией, а в процессе переключения со старой на новую. От этого практически никуда не деться, разве только какими-то внешними средствами, которые "придержат" все пользовательские запросы на время переключения, а потом отправят их новой базе. Разумеется, "гасить" старую базу желательно уже после подъёма новой. Для пользователей весь процесс может быть практически неотличим от, например, сетевых ретрансмитов.
Вообще, правильно это делается не так. Изначально надо было делать master-slave репликацию (а если точнее, то master — second master), все изменения (и индексами и не только) проводить на slave (можно хоть неделю играться, лишь бы вместимости логов хватило), затем когда на слейве сделали все, что надо, меняем их местами (то есть мастер становится слейвом) и он затягивает все изменения (опять таки пусть хоть неделю работает). Пользователи вообще ничего не замечают.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли. _>> AB>Эту фразу можно применить к любому программному продукту. _>> Вот уж нет.
AB>Ты готов озвучить безграбельный продукт?
Черное-белое, оттенков не различаешь? Вопрос не в наличии грабель, а в их количестве. В MySQL по доброму так обильно насыпано грабель-фич.
_>> Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция.
AB>А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают.
Ну тогда можно придумать и свой язык и назвать его, например SQL. Ну и что, что к всем известному языку он не будет иметь никакого отношения. Просто в документации описать. Типа такого "оператор SELECT — удаляет данные из таблицы".
_>> И что перед этим надо делать копию ажно всей БД.
AB>Ну это ты уже сам придумал.
Да нет, вон народ в этом топике на полном серьезе предлагает и обсуждает.
Здравствуйте, _d_m_, Вы писали:
_> AB>Ты готов озвучить безграбельный продукт? _> Черное-белое, оттенков не различаешь? Вопрос не в наличии грабель, а в их количестве. В MySQL по доброму так обильно насыпано грабель-фич.
Опять общие слова...
_> AB>А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают. _> Ну тогда можно придумать и свой язык и назвать его, например SQL. Ну и что, что к всем известному языку он не будет иметь никакого отношения. Просто в документации описать. Типа такого "оператор SELECT — удаляет данные из таблицы".
Отвечу твоими же словами: "Черное-белое, оттенков не различаешь?"
_> _>> И что перед этим надо делать копию ажно всей БД. _> AB>Ну это ты уже сам придумал. _> Да нет, вон народ в этом топике на полном серьезе предлагает и обсуждает.
Ну так это от незнания. DROP INDEX делается за доли секунды при правильном администрировании.
