我正在AWS RDS上托管的SQL Server中创建数据库（我想使用2016或2017版本）。
我的问题是关于为我怀疑将有很多行的表创建ID（确实，我的数据库可能不会有很多行，但是我想学习如何正确地完成工作）。我不知道哪种数据类型更好选择。
我的ID的结构将是：
[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，则只能输入应该是100.000行的范围（0-9）。
如果我使用BIGINT，其范围为-2 ^ 63（-9,223,372,036,854,775,808）至2 ^ 63-1（9,223,372,036,854,775,807）。我只使用其中的一些，但是如果计算成本合适，我就不用。
非常感谢您！
答案 0 :(得分：1)
我的建议显然是使用数字数据类型-最好是INT或BIGINT-作为数据库ID。
这些类型小，快速，灵活-它们在小写/大写，区域/语言设置，Unicode或非UNicode以及基于字符串的ID会具有的更多功能方面没有任何问题。如果可以，请避免麻烦自己！
您是否需要INT或BIGINT取决于您期望的行数-20亿对9位数：-）
使用类型INT（从1开始），您可能会获得超过20亿行-在大多数情况下应该足够了。
如果您使用从1开始的INT（作为SQL Server中的IDENTITY），并且每秒插入一行，则需要66.5 年年，才能达到20亿限制...
如果您使用从1开始的BIGINT，并且每秒插入一千行，则需要令人难以置信的 2.92亿年 >在达到9.22亿的上限之前...
答案 1 :(得分：0)
如果您没有自然键，则应该只考虑任何整数数据类型。
因此，对于大型赌桌，您必须问自己是否超过20亿（或者如果从-2147483648开始，则超过40亿）。如果是这样，那么您应该选择bigint，否则int就足够了。
从性能的角度来看，varchar由于比较昂贵（由于大小写和重音不敏感）而变得更糟
decimal仅比bigint慢。由于decimal需要更多空间，因此您不需要生成密钥。