При разработке таблиц у меня сложилась привычка иметь один столбец, который является уникальным, и что я делаю первичный ключ. Это достигается тремя способами в зависимости от требований:
- Идентификатор целочисленного столбца, который автоматически увеличивается.
- Уникальный идентификатор (GUID)
- Столбец с коротким символом (x) или целочисленным (или другим относительно небольшим числовым типом), который может служить столбцом идентификатора строки
Номер 3 будет использоваться для довольно небольшого поиска, в основном для чтения таблиц, которые могут иметь уникальный статический код длины строки или числовое значение, например год или другой номер.
По большей части все остальные таблицы будут либо иметь первичный ключ с автоматическим приращением целых чисел или уникальный идентификатор.
Вопрос: -)
Недавно я начал работать с базами данных, у которых нет согласованного идентификатора строк, а первичные ключи в настоящее время группируются по различным столбцам. Некоторые примеры:
- Дата и время/символ
- DateTime/целое число
- Дата и время /VARCHAR
- char/NVARCHAR/NVARCHAR
Есть ли для этого действительный случай? Я бы всегда определял столбец идентификатора или уникального идентификатора для этих случаев.
Кроме того, существует множество таблиц без первичных ключей вообще. Каковы веские причины, если таковые имеются, для этого?
Я пытаюсь понять, почему таблицы были спроектированы так, как они были, и, похоже, это большой беспорядок для меня, но, возможно, для этого есть веские причины.
Третий вопрос, чтобы помочь мне расшифровать ответы: В случаях, когда несколько столбцов используются для составного первичного ключа, существует ли конкретное преимущество этого метода против суррогатного/искусственного ключа? Я думаю в основном о производительности, обслуживании, администрировании и т.д.?