Статические данные SQL / списки поиска IDENTIFIER - PullRequest
Новая
       21

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

1 голос
/ 05 июня 2009

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

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

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

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

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

Что бы вы предложили? Почему?

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

Ответы [ 2 ]

7 голосов
/ 05 июня 2009

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

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

3 голосов
/ 05 июня 2009

Если вы используете ID INT или CHAR, ссылочная целостность сохраняется в обоих случаях.
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: страны, языки, валюты относятся к числу таких случаев.

...