SQL статические данные/списки поиска IDENTIFIER

Question

Что касается дизайна таблицы статических данных. Наличие статических данных в таблицах, как показано:

• Валюта (код, название). Пример строки: USD, Доллар США
• Страны (код, название). Пример строки: DE, Германия
• XXXObjectType (Код, Имя, ... дополнительные атрибуты)
• ...

имеет смысл иметь другой (Integer) столбец в качестве первичного ключа, так что все ссылки на внешние ключи будут использовать его?

Возможные решения:

1. использовать дополнительные ЦЕЛОЕ, как PK и FK
2. использования кодекса (обычно СИМ (N), где N мал) в качестве PK и FK
3. использовать код, только если меньше определенного размера ... Какой размер?
4. Другое _______

Что бы ваше предложение? Зачем?

Я обычно использовал колонки INT IDENTITY, но очень часто короткий код достаточно хорош, чтобы показать пользователю пользовательский интерфейс, и в этом случае запрос будет иметь один JOIN меньше.

Answer 1

Настоящая INTENTITY абсолютно не нужна. используйте вместо меня 2-значную мнемонику. Если у вас есть объект с небольшим уникальным свойством, вам следует рассмотреть возможность использования синтетического ключа. Но коды валют и коды стран не подходят для этого.

Я когда-то работал над системой, в которой у кого-то на самом деле была таблица лет, и каждый год был YearID. И, правда, чтобы сформировать, 2001 год был 3, а 2000 год был 4 годом. Он сделал все остальное в системе , поэтому гораздо сложнее понять и запросить, и это было напрасно.

Answer 2

Если вы используете ID INT или CHAR, ссылочная целостность сохраняется в обоих случаях.
INT INT имеет длину 4 байта, поэтому он равен размеру CHAR (4); если вы используете CHAR (x), где x < 4, ваш CHAR-ключ будет короче, чем INT; если вы используете CHAR (x), где x> 4, ваш CHAR-ключ будет больше, чем INT; для коротких клавиш не обычно имеет смысл использовать VARCHAR, поскольку последний имеет 2-байтовые служебные данные. Во всяком случае, когда речь идет о таблицах с - скажем - 500 записями, общая накладная CHAR (5) по ключу INT будет всего 500 байтов, что является весомым для базы данных, где некоторые таблицы могут иметь миллионы записей.
Учитывая, что страны и валюты (например,) ограничены числами (всего несколько сотен, не более), вы не получаете выигрыша от использования ID INT вместо CHAR (4); кроме того, ключ CHAR (4) может быть легче запомнить для конечного пользователя и может облегчить вашу жизнь, когда вам придется отлаживать/тестировать ваши Sql и/или данные.
Поэтому, хотя я обычно использую ключ ID INT для большинства своих таблиц, в некоторых случаях я выбираю, чтобы PK/FK из CHAR: страны, языки, валюты относятся к числу этих случаев.