Небольшой вопрос по проектированию

[Nelius]

Небольшой вопрос по проектированию

В таблице есть поле status оно может принимать различные значения.
Пример статусов: published, hidden, deleted и.т.д.
Таблица будет приличная, несколько миллионов строк.
Есть вариант сделать status как tinyint и статусы закодировать числами 0 - hidden, 1 - published, -1 - deleted итд...
Или сделать поле типа varchar и статусы задавать так как в примере.
Я понимаю что в последнем случае все более понятно в коде будет, а если tinyint то фиг разбери что там за код.

Вопрос вот в чем, даст ли ипользование tinyint какую-либо ощутимую экономию и прирост в производительности?
И если есть, то стоит ли оно того или лучше более явное указание статусов?

 

[HraKK]

СтОит использовать 3 атомарную форму.

 

[Nelius]

HraKK
Вы про третью нормальную форму? Или не так понял?

 

[HraKK]

да

 

[Nelius]

HraKK
Изначально был статус один, 1 или 0, показать или скрыть и вопросов не возникало. Потом потребовались еще статусы.
Я подумал о том чтобы вынести их в отдельную таблицу. (3NF?) Но глянул таблицу в Wordpress (последней версии) и обнаружил что у них там varchar. Удивился и решил спросить что сподвигло людей на денормализацию?

 

[HraKK]

Множество причин (одна из них безграмотность или сделать абы работало). Вы смотрите на свою ситуацию.

 

[Nelius]

HraKK
Ситуация в том чтобы это работало максимально быстро.

Почему смотрел вордпресс, потому что схожая ситуация, требуется выводить данные основываясь на статусе (всегда присутствует в выборке) и отображать текущий статус записи в админке с возможностью его изменить.
Я предполагаю что в вордпрессе использовали varchar потому что удобно выводить статус в админке, там мультиязычность c использованием gettext наверное так и юзают прям значение этого поля... но может и ошибаюсь.
Вопрос в том даст ли подобный подход реальный прирост?

 

[HraKK]

нет

 

[Nelius]

HraKK
Спасибо, тогда приведу к 3NF и не буду дергаться, денормализовать всегда успею...
Еще раз спасибо!)

 

[fixxxer]

сначала всегда стоит проектировать 3нф, а уже потом денормализовать при необходимости.
но варчар это совсем страшно, почему не enum?

а вообще, вордпресс, это, м. как бы сказать
учитывая, что нахожусь в культурном обществе, скажу так - далеко не лучший пример для подражания =)

 

[phprus]

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

Одна из причин - это более наглядные запросы из-за отсутствия лишних join'ов. А неверное значение занести в базу все-равно не получится, так как СУБД должна проверять допустимые значения enum'ов.

 

[Nelius]

fixxxer
Да, согласен про 3НФ.
У них там (в вордпрессе) вообще что-то странное, щас порылся, используют varchar(20) там где значения могут быть только Y или N ...
Я смотрю не только в вордпресс, много разных опенсорс движков... встречал еще в нескольких подобную реализацию, наверное тоже на вордпресс смотрели
Кстати буду благодарен за ссылочку на приличный движок где можно глянуть что-нить чтоб не изобретать велосипеды и не наступать грабли. (с хорошей структурой БД)

phprus
Спасибо за подсказку. Дело в том что использование внешней таблицы тут действительно не очень рационально, так как статус записи меняется не только в админке, но и тем юзером кто ее создал (хоть и ограничено), а это значит что мне придется каждый раз когда юзер смотрит свою запись и видит панель модерирования дергать 2 таблицы вместо одной...
Только надо определиться необходимо ли будет динамическое добавление этих статусов или нет... если да, то не знаю насколько подойдет enum.

 

[Gas]

что касается скорости enum vs int (varchar даже рассматривать не нужно):
http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/

то есть разницы нет.
Если нужно "динамическое добавление", то я бы enum не пользовал, особенно когда "таблица будет приличная, несколько миллионов строк".

 

[HraKK]

Изначально был статус один, 1 или 0, показать или скрыть и вопросов не возникало. Потом потребовались еще статусы.

что касается скорости ... то есть разницы нет.

Еще что-то надо для принятия решения? Или Join 1 таблицы сферх ресурсо емкая задача?

 

[Nelius]

HraKK
Уже вполне достаточно информации, спасибо!
По поводу ресурсо емкая, есть такая поговорка "Копейка рубль бережет" или как-то так)

Gas
Большое спасибо за ссылку. Очень полезный материал.

 

[phprus]

Nelius

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

В случае если есть частое изменение возможных статусов, то тогда enum'ы тут не очень то и подходят. В данном случае будет лучше дополнительная таблица статусов.
Так-же не надо ударяться в другую крайность, те засовывать большое количество неизменных значений в один enum. Пример такой крайности это все штаты в одном enum'e, как в тесте, ссылку на который дал Gas. Для такой задачи надо использовать отдельную таблицу(набор строк) и join.

 

[Nelius]

phprus
Благодарю за подробные пояснения, теперь все понятно, буду пробовать на практике.

 

[Духовность™]

3нф

а что это такое? расскажите.

 

[Gas]

http://ru.wikipedia.org/wiki/Нормальная_форма

 

[pilot911]

лучше добавить каждому статусу свое поле в таблице

deleted hidden published

поскольку опубликованное может быть скрытым на время и тп