哪种 .NET 数据类型最适合在 NHibernate 中映射 NUMBER Oracle 数据类型?
我见过一些在 NHibernate 项目中使用十进制来映射到 Oracle 中的整数列的示例。现在我在程序中使用 int
和 long
。
decimal
相对于 int
/long
有哪些优势?它的性能更好吗?
I've seen some examples in which decimal
is used in NHibernate projects for mapping to whole number columns in Oracle. Right now I'm using int
and long
in my program.
What are the advantages of decimal
over int
/long
? Does it perform better?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这可能是因为 .NET
decimal
和 OracleNUMBER
映射比long
和NUMBER
更好一点,而且还为您提供了更大的灵活性。如果您稍后在 Oracle 列中添加小数位数,那么如果您已经使用了十进制
,则无需更改数据类型。decimal
肯定比int
和long
慢,因为硬件支持后两者。也就是说,您必须处理大量数据才能发挥作用。我仍然认为您应该使用long
如果这就是您正在处理的内容,那么您还应该让表列定义来表示它。NUMBER(18,0)
表示long
等等。decimal
映射得更好一点的原因是long
是 64 位,而decimal
是(某种)128 位。.NET
Oracle
NUMBER
默认为 38 位有效数字,小数位数为 0(整数)。Microsoft 已意识到该问题并注释
想想看,您实际上需要
BigInteger
能够表示与NUMBER
默认值相同的有效数字。我从未见过有人这样做,我认为这是一个非常罕见的需求。而且BigInteger
仍然不会削减它,因为NUMBER
可以是正无穷大和负无穷大。That's probably because .NET
decimal
and OracleNUMBER
maps a bit better thanlong
andNUMBER
and it also gives you more flexibility. If you at a later stage add a scale in the Oracle column then you wouldn't have to change datatype if you already useddecimal
.decimal
is certainly slower thanint
andlong
since the later two are supported in hardware. That said, you have to crunch some serious amount of data for it to make any difference. I still think that you should uselong
if that that's what you're dealing with and then you should also let the table column definitions represent that.NUMBER(18,0)
forlong
and so on.The reason
decimal
maps a little better is thatlong
is 64 bits anddecimal
is (kind of) 128 bits..NET
Oracle
NUMBER
defaults to 38 significant digits and scale 0 (integer).Microsoft is aware of the problem and notes
Come to think of it you actually need
BigInteger
to be able to represent the same number of significant digits as to whatNUMBER
defaults to. I've never seen anyone do that and I would suppose it's a very rare need. AlsoBigInteger
still wouldn't cut it sinceNUMBER
can be of positive and negative infinity.