Я не знаю, какой тип данных выбрать для идентификаторов Microsoft SQL Server - PullRequest
Новая
       6

Я не знаю, какой тип данных выбрать для идентификаторов Microsoft SQL Server

0 голосов
/ 20 января 2019

Я создаю базу данных на SQL Server, размещенную на AWS RDS (я хочу использовать версию 2016 или 2017).

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

Структура моего идентификатора будет выглядеть следующим образом: 

[Two items for schema][Three items for tables][Five items for rows]

Пример, который я рассмотрел: 

Data type and length | Example    | Storage (bytes)
---------------------+------------+---------------
VARCHAR(10)          | S1TA100001 |   10 bytes 
NUMBER(10,0)         | 0100100001 |    9 bytes
BIGINT               | 100100001  |    8 bytes

Если я использую VARCHAR, у меня будет больше диапазона (0-9 и AZ -38-), поэтому, возможно, я смогу уменьшить de ID ([Схема первая] [Таблица одна] [Строка- (дерево | четыре)]это 5 или 6 байтов, что предполагает 54,872 или 2,085,136 строк. Но я предполагаю, что это приводит к вычислительным затратам.

Если я использую NUMBER, у меня есть только диапазон (0-9), который предполагается 100,000 строк.

Если я использую BIGINT, который имеет диапазон от -2 ^ 63 (-9,223,372,036,854,775,808) до 2 ^ 63-1 (9,223,372,036,854,775,807). Я использую только несколько из них, но я не использую, если вычислениястоимость актуальна.

Большое спасибо!

Ответы [ 2 ]

0 голосов
/ 21 января 2019

Моя рекомендация будет четко использовать числовой тип данных - предпочтительно INT или BIGINT - для идентификатора базы данных.

Эти типы маленькие, быстрые, шустрые - и онине испытывайте проблем с нижним / верхним регистром, региональными / языковыми настройками, Unicode или не-Unicode и многими другими вещами, которые имел бы идентификатор на основе строки.Избавьте себя от этой проблемы, если сможете!

Если вам нужно INT или BIGINT, зависит от того, сколько строк вы ожидаете - 2 миллиарда против 9 квинтиллионов: -)

  • С типом INT, начиная с 1, вы получаете более 2 миллиардов возможных строк - этого должно быть достаточно для большинства случаев.
    Если вы используете INT (как IDENTITY в SQL Server), начиная с 1, и каждую секунду вы вставляете строку, вам нужно 66,5 лет , прежде чем вы достигнете предела в 2 миллиарда ...

  • Если вы используете BIGINT, начинающийся с 1, и вставляете тысячу строк в секунду , вам нужно ошеломить 292 миллиона лет , прежде чем вы достигнете квинтиллиона 9,22предел ...

0 голосов
/ 20 января 2019

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

Так что для больших таблиц вы должны спросить себя, превысит ли вас 2 миллиарда(или 4 миллиарда, если вы начнете с -2147483648).Если это так, то вам следует перейти на bigint, в противном случае int будет достаточно.

С точки зрения производительности, varchar намного хуже из-за более дорогого сравнения (из-за случая инечувствительность к акценту)

decimal лишь немного медленнее, чем bigint.Поскольку decimal требует больше места, он никогда не нужен для сгенерированного ключа.

...