Tip za upotrebu za stupce “Status” u sql tablici
Imam (lažnu) strukturu tablice kako slijedi:
ticket id: int(11) PK name: varchar(255) status: ?????????
Pitanje je koji tip podataka trebam koristiti za status? Evo mojih opcija, kako ih vidim:
- varchar koji predstavlja status - BAD jer nema integriteta
- enum koji predstavlja status - BAD jer bih za promjenu vrijednosti morao izmijeniti tablicu, a zatim bilo koju kod sa padajućim padajućim vrijednostima, itd itd itd
- int FK u tablicu statusa - DOBRO jer je dinamično, LOŠE jer je teže pregledati iz vida (što može biti korisno)
- varchar FK u tablicu statusa - DOBRO jer je dinamičan i vidljiv prilikom pregleda. LOŠE jer tipke imaju smisla, na što se uglavnom mrzi. Zanimljivo je da je u ovom slučaju potpuno moguće da tablica statusa ima samo 1 stupac, što je čini proslavljenim nabrajanjem
Jesam li tačno pročitao situaciju? Je li posedovanje smislenog ključa zaista toliko loše? Jer iako me naježi, nemam razloga za to ...
Ažuriranje: Za opciju 4, predložena struktura bi bila status : char (4) FK , u tablicu statusa. Dakle,
OTVORENO>> "Otvoreno"
ZATVORENO => "Zatvoreno"
"PEND" => "Odobrenje na čekanju"
"PROG" => "U toku
Koji je nedostatak u ovaj slučaj? Jedina korist koju vidim u ovom slučaju je korištenje int over char je mala izvedba.
4 ответа
Перейдите к номеру 3. Создайте представление, которое объединяет значение статуса, если вы хотите что-то проверить.
Я бы пошел с номером 4, но я бы использовал столбец char(x). Если вы беспокоитесь о производительности, char (4) занимает столько же места (и, как можно подумать, дисковый ввод-вывод, пропускную способность и время обработки), чем int, для хранения которого также требуется 4 байта. Если вы действительно беспокоитесь о производительности, сделайте ее char (2) или даже char (1).
Не думайте об этом как о «значимых данных», думайте об этом как об аббревиатуре естественного ключа. Да, данные имеют значение, но, как вы заметили, это может быть полезно при работе с данными - это означает, что вам не всегда нужно объединяться (даже если речь идет о простой таблице), чтобы извлечь значение из база данных. И, конечно, ограничение внешнего ключа гарантирует, что данные действительны, так как они должны быть в таблице поиска. (Это может быть сделано и с ограничениями CHECK, но таблицы поиска, как правило, легче обслуживать и поддерживать с течением времени.)
Недостатком является то, что вы можете попытаться найти смысл. char (1) имеет сильную привлекательность, но если вы получите десять или более значений, может быть сложно найти хорошие значимые значения. Меньше проблем с char (4), но все же возможная проблема. Другой недостаток: если данные могут измениться, то да, ваши значимые данные ("PEND" = "Ожидание авторизации") могут потерять свое значение ("PEND" = "Переслать в домашний офис для первоначального утверждения"). Это плохой пример; если подобные коды меняются, вам, вероятно, будет лучше провести рефакторинг вашей системы, чтобы отразить изменение в бизнес-правилах. Я предполагаю, что моя точка зрения должна быть такова: если это введенное пользователем значение поиска, суррогатные ключи (целые числа) будут вашим другом, но если они определены и поддерживаются внутри, вам определенно следует учитывать более удобные для человека значения. Это или вам понадобятся заметки на вашем мониторе, чтобы напомнить вам, что, черт побери, Status = 31 должно означать. (У меня три на моем, и Stickum изнашивается каждые несколько месяцев. Поговорим о стоимости для поддержания ...)
Могу ли я порекомендовать вам вместо этого использовать поле statusID и иметь отдельную таблицу, сопоставляющую идентификатор с varchar?
РЕДАКТИРОВАТЬ: Я думаю, это именно то, что вы описали в пункте 3. Я думаю, что это лучший вариант.
Создание отдельной таблицы со статусом - хорошая идея, если вы хотите отобразить список статуса в форме HTML. Вы можете показать подробное описание из справочной таблицы, и оно поможет пользователю выбрать статус, если требования таковы.
С точки зрения разработки я бы хотел использовать целое число в качестве первичного ключа. Вы можете оптимизировать его, используя маленькое / крошечное целое число, если знаете, что оно не превысит лимит.
Если вы используете аббревиатуру в качестве внешнего ключа, вам придется каждый раз думать, чтобы сделать его уникальным все время, как @Philip Kelley упомянул об этом как о недостатке.
Наконец, вы можете объявить тип таблицы MYISAM, если хотите.
Обновление: отражает мнение @Philip Kelley, если статус слишком много, то лучше использовать целое число в качестве внешнего ключа. Если есть только пара статусов, то можно использовать abbr в качестве внешнего ключа.