Cелективность в составном индексе

Итак, продолжаем нашу викторину по вопросу чем KEY(`a`,`b`,`c`) отличается от KEY (`c`,`b`,`a`). Кто же даст правильный ответ, не прибегая к умным терминам, селективность, кординалити? Все подсказки были даны.

vasa_c


А чего поле d забыл написать, из-за которго весь сыр бор?

это еще почему?

Во первых, если нужно, что-то изменить придется лезть в БД. Во вторых ENUM плохо сочетается с другими типами данных давая не самую высокую производительность при выборках.

можно подробней?

T1grOK

это к неграмотному проектировщику вопросы, а не к БД

Пруф в студию, он не чем не отличается от них для MySQL, только более конкретен и занимает меньше места.

ИМХО

Та какие-то надуманные проблемы, по-моему. Особенно про "изменить", тут любители триггеров и хранимок обнялись, заплакавши.

Использую ENUM везде, где это уместно, и ни разу не сталкивался ни с какими проблемами. Может это конечно мне так везет, не знаю...

Это один из вариантов, ситуаций бывает множество, тестами все не покроешь, так что поверь на опыт людей, которые сталкивались с подобными проблемами.

Так и есть, во втором случае будет проверена значительная часть индекса.

речь не идет про синтетические тесты, у меня используется ENUM в реальных рабочих проектах.

всегда рад, когда есть тому подтверждение, например:

http://ruseller.com/lessons.php?rub=28&id=692

+ еще куча ссылок, где все советую именно так делать.

http://oleyniknv.ru/int/section_2/page_1
...
http://www.internet-technologies.ru/articl...ticle_1697.html

Попробуй сравнить производительность, если делать выборку ENUM & VARCHAR, ENUM & ENUM. Скорость может отличаться в несколько раз.
Сортировка ENUM это вообще отдельная тема, так как эта операция производится по внутреннему указателю, а не по значениям, то есть придется то ли заведомо вносить значения в ENUM поле в алфавитном порядке, то ли извращаться с применением FIELD().
И по поводу обновления ENUM полей, надуманным это не считаю. Придется давать привилегии на обновление структуры таблицы, чтоб изменить значения в ENUM поле.

Я бы сказал очень определенных(избранных)....
Я на проекте отказался от enum(не спорю, что многое зависит от архитектуры приложения), при этом запросы к таблицам(а они не маленькие >34 млн. строк) ускорились в среднем на 8%.

ну это как бы логично

не понял, имеешь в виду юзать в where условия по этим полям? Если да, то у меня к сожалению нет таблиц с более, чем 1 enum-полем

Ну, в примере, вместо ENUM куда лучше бы BOOL вписался. И изменить список вариантов для большой таблицы будет весьма небыстро.

Наткнулся на оогромную статью посвященную ENUM, точнее почему ENUM лучше не использовать, а если использовать, то когда лучше.

Все доходчиво расписано по 8 пунктам.

Статья на английском, гуглом читабельно. Также с удовольствием почитал комменты.

Читать статью


p.s. Итог, согласен с автором статьи, как и с любым из вас, прежде чем что-то использовать нужно подумать головой, а не Ж.

Позволите небольшой оффтоп?

Ребят, я с огромным интересом следил за топиком. И даже начал болеть и переживать за первенство в викторине от vasa_c

Но вот почему то все скатилось к ENUM...

Нет, статьи интересные, вопросов нет. Но вот почему то, когда вникаешь в такие диспуты, вспоминается астрономя. Особенно раздел про черные дыры. Сидят именитые, с кучей степеней и прочих регалий ученые мужи и рассуждают: а есть ли у черных дыр горизонт событий... И как он, этот горизонт, соответствует постулатам квантовой механики и не нарушает ли теорию относительности...

Вот скажите мне, человеку недалекому приземленному. Кто на практике сталкивался с проблемой ENUM. Только не так, как подавалось:

Я помню, что когда то, где то, давно-давно, было замечено, что он тормозит события на пару микросекунд.

Я про реальные проблемы.

Неужели у вас действительно больше нет проблем, чем искать черную кошку в темной комнате?

Если так, я просто вам завидую. Тут и без этого куча проблем...