В справочной таблице я должен использовать идентификатор или текстовое поле?

Question

В справочной таблице я должен использовать идентификатор или текстовое поле?

У меня есть справочная таблица item_type с полем id и поле name, В моем приложении элементы должны обрабатываться по-разному в зависимости от их item_type.

В моем коде приложения, должна ли моя условная логика сверяться с id или name? Или есть другая лучшая практика для этого?

Редактировать:
id будет первичным ключом, но name все еще будет уникальным; это будут параметры в раскрывающемся списке, которые будут определять тип добавляемого пользователем элемента. Позже они определят, как обрабатывается предмет.

1

database-design logic mysql php

Решение

Другие решения

Это может быть сложная ситуация.

Учитывая, что у вас есть этот вопрос, указывает, что ваш дизайн не определяет, какие ключи у вас есть для этой конкретной таблицы. Я бы назвал это неполным проектом, пожалуйста, вернитесь к этой части и явно укажите все ключи, которые существуют для все ваши отношения;
Если у вас есть оба, id а также name (Что ж, name неправильное наименование столбца в том виде, в котором мы его передаем, так как это зарезервированное слово), я предполагаю, что id добавляется искусственно, то есть в этом столбце нет необходимости описывать ваши Данные. Это так называемый суррогатный ключ. Вы должны быть осторожны с ними — они не спасут вас от дубликатов! Представьте себе случай, когда у вас будет:
```
 id |   name
----+--------
1 | type_a
2 | type_b
3 | type_a
```
Несмотря на то, что у вас есть id быть первичным ключом здесь а также все значения уникальны, у вас все еще есть дублирование данных;
Поэтому ты должен создайте 2 ключа здесь: Primary on id колонка и уникальный на name колонка.
Теперь это не плохая ситуация сама по себе, но убедитесь, что у вас есть и то и другое ключи.

Лично я использую следующие правила:

если таблица — это словарь с небольшим (до 10) количеством значений, я использую:
- только 1 столбец в этой таблице, что делает его varchar (или же text скорее);
- присвойте этому столбцу одинаковое имя;
- сделать этот столбец первичным ключом.
Это держит стол чистым и маленьким. И я предпочитаю использовать специальные таблицы над ENUMs.
если я знаю, что количество записей будет расти или же Мне нужно будет добавить больше столбцов по пути, я буду:
- создать выделенный числовой столбец, назвав его следующим образом <table_name>_id (например. customer_id) и сделать его первичным ключом;
- использовать этот PK в другом месте в модели данных;
- создать уникальное ограничение для реальных данных, чтобы избежать дублирования данных (это обязательно).

РЕДАКТИРОВАТЬ:
Я не вижу необходимости использовать id как суррогатный ключ вообще за такую крошечную вещь. Я сомневаюсь, что значения в этой таблице будут часто меняться, если они вообще будут. Стоимость внедрения искусственного ключа — это будет обязательно присоединиться к этой таблице, чтобы проверить записи определенного типа. В то время как естественный text ключ позволит вам избежать этого и использовать такие запросы, как:

SELECT * FROM item WHERE item_type='type_a';

Я рекомендую взглянуть на этот вопрос: Есть ли РЕАЛЬНАЯ разница в производительности между первичными ключами INT и VARCHAR?

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

1

Если у вас есть такой код:

TABLE ITEMS:
id
type_id
name
etc_etc

ITEM_TYPES
id
name

Идите по id. ВСЕГДА используйте столбец int, предпочтительные столбцы индекса (например, ваш основной столбец идентификатора auto_incrementing), если только у вас нет веских причин. Это компьютер, компьютеры делают цифры, а не слова 🙂

Если этого недостаточно (это должно быть):
Допустим, вы добавили тип в виде строки вместо идентификатора. У вас есть несколько мест, которые вы знаете (и некоторые из них вы забыли), ссылающихся на «голубые» элементы. Год спустя вы думаете, что «Чирок» был бы лучше, поэтому вы обновляете таблицу. Теперь вам нужно будет просмотреть весь код, чтобы изменить все «Cyan» на «Teal». В большой среде это не удастся.
Вероятность изменения идентификатора намного меньше.

0

Источник

Accepted Answer

Существует два способа создания таблиц:

Используйте натуральные ключи, то есть номер сотрудника, код страны и т. Д.

создать таблицу страны (код char (2), имя varchar (100), ...);
создать таблицу сотрудника (empno номер (5), имя varchar (100), ...);
создать порядок таблицы (номер заказа (5), код страны (2), ...);

Используйте технические идентификаторы:

создать таблицу страны (id номер (9), код char (2), имя varchar (100), ...);
создать таблицу сотрудника (идентификационный номер (9), empno номер (5), имя varchar (100), ...);
создать порядок таблицы (номер идентификатора (9), номер заказа (5), номер id_country (9), ...);

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

Что касается технического идентификатора: они предназначены только для ссылок внутри базы данных. Вы будете использовать их в своей программе только тогда, когда вы делаете соединения. Например: пусть пользователь выбирает страну из списка, а затем использует ее идентификатор для доступа к заказам, размещенным в этой стране.

Когда дело доходит до того, чтобы ваша программа знала коды, вам также не следует использовать их. Например, если вы хотите, чтобы Великобритания отличалась от других стран, потому что это ваша родная страна, используйте ее код «GB». Конечно, вы можете попросить вашу программу выбрать идентификатор страны ‘GB’ и сравнить ваши заказы с этим идентификатором. Только никогда не иметь что-то вроде select ... from orders where id_country = 187 в вашем приложении.

Что касается вашей таблицы: страны, как в моем примере, уже имеют код; Вы можете использовать код ISO. Ваши типы предметов, вероятно, нет. Итак, вы изобрели код. Это может быть код, который вы даже показываете пользователям, так что они могут привыкнуть к ним через некоторое время и начать говорить о RC, а не о гоночных автомобилях, как раньше. Или вы храните коды от пользователей и используете их только в программах, чтобы они никогда не видели код «RC», но для всех ваших программ гоночные автомобили — это RC.

Так что у вас есть

create table item_type (code char(2), name varchar(100), ...);

или же

create table item_type (id number(9), code char(2), name varchar(100), ...);

и использовать поле кода в вашем приложении независимо.

Еще одно замечание: при использовании естественных ключей и использовании их пользователями, вы обычно используете короткие коды как «RC», потому что они используются для ссылок (внешние ключи) и также легко вводятся. При использовании идентификаторов и только при использовании внутренние коды, вы также можете использовать длинные коды, такие как ‘RACING_CARS’ для удобства чтения в ваших программах.

0