2015-03-14 4 views
4

Простой вопрос проектирования БД, который я, честно говоря, не могу наложить.SQL-таблицы, один столбец, нет Id

Во многих случаях у меня есть таблица типов, состоящая из идентификатора и имени типа. . Ala таблица код языка будет иметь 2 колонки

ТАБЛИЦА: language

language_id (1,2,3)     
language_code (et, en-us, de) 

Теперь я всегда раздавать LANGUAGE_ID в качестве внешнего ключа к другим таблицам,

НО

Какие лучше?

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

ИЛИ

оставить вне language_id совсем так, что мы имеем

ТАБЛИЦА: language

language_code (et, en-us, de) 

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

Мнения?

+0

Поскольку эти коды языков довольно короткие (не более 5 символов - en_us) и * стандартизованные * по ISO, похоже, что они будут использовать хорошие кандидаты для непосредственного использования - я не вижу большой пользы при добавлении еще одного ' ID' здесь .... –

+0

Это действительно просто «суррогатный ключ против естественного ключа». Я не уверен, какой наиболее рекомендуемый подход; afaik оспаривается, что лучше.ИМО, поскольку коды коротки и вряд ли меняются, я бы рекомендовал только подход 'language_code'. –

ответ

7

Ответ, это зависит.

В большинстве случаев желательно использовать справочную таблицу с внешним ключом. Вот несколько причин:

  • Вы можете включить ссылку внешнего ключа, которая проверяет правильность значения.
  • Вы можете легко добавить другое значение.
  • Вы можете включить другую информацию, такую ​​как добавленная дата, и полное имя «английский», а не «en».

Повреждение в целом, как правило, незначительное. У вас будет индекс первичного ключа на идентификаторе языка, и это будет очень быстро.

Ваш код языка всего два символа. Если вы использовали типичный 4-байтовый ключ для ссылки, вы использовали бы до двух байтов в каждой записи. Бывают ситуации, когда включение языкового кода может сэкономить место и усилия. Однако, чтобы это имело значение, вы бы говорили об оптимизации в очень большой базе данных (скажем, сотнях миллионов строк).

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

+0

В дополнение к ответу выше, идентификация в качестве первичного ключа защитит ОП от ситуаций, когда кто-то по какой-либо причине решает изменить 2-символьный код (ISO 639-1) языка или когда ваши преемники решают используйте трехсимвольный код (ISO 639-2) для представления кода языка. – zedfoxus

+0

Не обязательно, я мог бы установить каскадные правила, так что, когда кто-то меняет язык_кода, скажем «et» на «est», он также каскад меняет все остальные таблицы! –

+0

Коды языков имеют некоторую иерархию - я имею в виду, например, 'es' и' es-pt', 'es-mx'. Иногда вам приходится иметь дело с самыми узкими кодами, и иногда вы хотите иметь дело только с частью кода верхнего уровня (es, en, ru и т. Д.). С справочной таблицей было бы намного проще! – pkuderov