Является ли использование вставки идентичным с метаданными

Question

У меня есть несколько таблиц в моей базе данных, которые содержат только «метаданные». Например, у нас есть разные типы групп, contentItemTypes, языки и т. Д.

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

Теперь мне интересно, не лучше ли использовать autonumbering внутри этих таблиц?

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

Что вы, ребята, думаете?

Answer 1

Если это таблицы FK, используемые только для того, чтобы развернуть коды в описание или содержать другие атрибуты, тогда я НЕ использовал бы IDENTITY. Идентичность навсегда всегда вставляет пользовательские данные, таблицы метаданных обычно статичны. Когда вы развертываете обновление для своего кода, вы не хотите быть удивленным и иметь значение IDENTITY, отличное от ожидаемого.

Например, вы добавляете новое значение в таблицу «Языки», вы ожидаете, что идентификатор будет 6, но по какой-либо причине (разработка не синхронизирована, другой человек не реализовал свой следующий тип языка и т. Д.), следующий идентификатор, который вы получаете, отличается от другого. 7. Затем вы вставляете или конвертируете кучу строк, используя идентификатор языка = 6, которые все терпят неудачу, потому что он не существует (это 7 в таблице метаданных). Хуже того, все они активируют вставку или обновление, потому что значение 6, которое, по вашему мнению, было вашим, уже было в таблице medadata, и теперь у вас есть сочетание двух элементов, разделяющих одно и то же значение 6, и ваше новое значение 7 остается неиспользованным.

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

, например, если у вас есть только несколько групп, и вы будете часто смотреть на необработанные данные, то символ (1) может быть хорошим:

GroupTypes table 
----------------- 
GroupType   char(1) --'M'=manufacturing, 'P'=purchasing, 'S'=sales 
GroupTypeDescription varchar(100) 

однако, если есть много разных значения, то некоторая форма int (tinyint, smallint, int, bigint) может сделать это:

EmailTypes table 
---------------- 
EmailType   smallint --2 bytes, up to 32k different positive values 
EmailTypeDescription varchar(100) 

Answer 2

Я бы использовал столбец идентификации, как вы предлагаете быть вашим основным ключом (суррогатным ключом), а затем назначить свой ключ-кандидат (идентификатор из вашей системы) стандартным столбцом, но примените к нему уникальное ограничение. Таким образом, вы можете гарантировать, что вы не вставляете повторяющиеся записи.

Имеют смысл?

Answer 3

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

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

Answer 4

Если номера жестко закодированы в коде, не используйте поля идентификации. Жестко кодируйте их в базе данных, а также они будут менее подвержены изменениям, потому что кто-то плохо написал сценарий базы данных.

Answer 5

Я бы использовал столбцы идентификации как первичный ключ и просто для простоты вставки записей в базу данных, но затем используйте столбец для типа метаданных, я вызываю my LookUpType (int), а также столбцы для LookUpId (значение int в коде) или значение в списках выбора, LookUpName (строка), и если эти значения требуют дополнительных настроек, так сказать, используйте дополнительные столбцы. Я лично использую две дополнительные функции LookUpKey для иерархических отношений и LookUpValue для аббревиатур или альтернативных значений LookUpName.