在我当前的项目中，我遇到了我们的主数据库脚本。仔细看看，我注意到我们所有原始主键的数据类型都是数字（38,0） 我们目前正在运行SQL Server 2005作为我们的主要数据库平台。
对于一些小环境，我们支持Oracle和SQL Server作为后端。在Oracle中，我们的主键的数据类型为 number（38,0）。
是否有人知道此类实施可能产生的副作用和性能影响？我一直主张并实现 int 或 bigint 作为主键，并且很想知道数字（38,0）是否是更好的选择。
答案 0 :(得分：12)
好吧，你 花费更多的数据来存储你永远无法真正达到的数字。
bigint在8字节中上升至9,223,372,036,854,775,807
int以4字节为单位上升到2,147,483,647
如果我正在进行数学计算，那么NUMERIC（38,0）将会占用17个字节。
没有太大区别，但是：较小的数据类型=内存中的行数较多（或相同行数的页面数较少）=查找的磁盘I / O较少（索引或数据页搜索）。对于复制，日志页面等也是如此。
对于SQL Server：INT是IEEE标准，因此CPU更容易比较，因此使用INT与NUMERIC（这是一种压缩十进制格式）可以略微提高性能。 （注意在Oracle中，如果当前版本与我长大的旧版本匹配，则所有数据类型都被打包，因此INT内部与NUMERIC（x，0）几乎相同，因此没有性能差异）
因此，在宏观方案中 - 如果您有大量磁盘，RAM和备用I / O，请使用您想要的任何数据类型。如果你想获得更多的表现，请保守一点。
否则此时，我会保持原样。无需改变一切。
答案 1 :(得分：3)
除了存储方面的考虑以及未来DBA的一些初步混淆之外，我没有看到任何理由为什么NUMERIC（38,0）会是一个坏主意。您在表格中允许最多9.99 x 10 ^ 38条记录，您肯定无法到达。我对此的快速挖掘并没有发现任何不使用它的明显理由。我怀疑你唯一的潜在问题是它所消耗的存储空间，但看看存储空间是如此便宜，这应该不是问题。
我在Oracle数据库中已经看过很多次，因为它是一个非常大的默认值，在创建表时不需要考虑，类似于在SQL中默认使用INT或BIGINT服务器
答案 2 :(得分：3)
这太大了，因为你永远不会有那么多行。尺寸越大，存储空间越大。这本身并不是什么大问题，但也意味着需要更多的磁盘读取来从表或索引中检索数据。这意味着更少的行将适合数据库服务器上的内存。
我认为它没有被打破到足以让人感到困扰。
答案 3 :(得分：3)
你最好使用GUID。真。不使用一个的正常原因是整数表现更好。但GUID小于数字（38），并且还有一个额外的好处，就是让它更容易做一些让断开连接的用户创建和同步新记录的事情。