sql – 对于Oracle中的NUMBER列,是否指定了长度帮助性能?

前端之家收集整理的这篇文章主要介绍了sql – 对于Oracle中的NUMBER列,是否指定了长度帮助性能?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
@H_502_1@NUMBER,NUMBER(3)和NUMBER(10)之间的表现是否有任何真正的差异?不管RDBMS是否使用32位来存储值,并且只是在看作字符串时限制数据的长度?

例如,一位同事辩论说,使用NUMBER(10)和NUMBER / NUMBER(11)更有效率,认为n是字节数而不是字符数据的长度.通常,如果行数保证不超过10 ^ n左右,我同意限制列大小,但对于这个特定的数据库,行数的限制实际上是“尽可能多”,例如2 ^ 32或〜40亿,即使我们永远不会达到这个数额.对于这种情况,提出“最低最大值”似乎毫无意义,浪费时间,我认为使用NUMBER而不指定长度会更简单并且不会受到惩罚.我对么?

解决方法

从技术上讲,您没有定义长度,而是定义精度和比例.

无论定义列的精度和比例如何,相同的数值(例如100,4.3)都采用相同的内部值.

列可以容纳的最大值由BOTH精度和比例确定.也就是说,您可以将值100存储在NUMBER(3,0)列中,但不能存储在NUMBER(3,1)列中.

通常,如果列不应存储小数,则比例应为零.请记住,如果您尝试在NUMBER(3,0)中存储10.12,它将存储值10.它不会出错(因为如果确实如此,您将很难存储三分之一的值)任何东西).如果您希望它出错,您希望允许更高的比例并使用约束来阻止它被使用.

我也相信你也应该尝试使用’合理’的精确度.如果你在一千年内每秒存储一千个值,你仍然可以在14位数内存储.如果我看到一列NUMBER(14,0),那么我知道在我的屏幕或打印输出上我应该允许显示14个数字字符.如果我只看到NUMBER或NUMBER(38,那么我没有得到任何指导,可能会猜到14个字符.如果他们开始在那里放16个字符的信用卡号码,我就错了.这就是我不想猜的原因.

同样在PL / sql中,它们的PLS_INTEGER数据类型最高可达2147483647.如果我看到NUMBER(9,0)列,我知道我可以将它放入PLS_INTEGER中.当他们想要确定在将数据拉/推到数据库时使用的数据类型,规模和精度时,可能会有类似的Java或.Net等注意事项.

猜你在找的MsSQL相关文章