对于巨大的文件大小,在代码和数据库中使用什么类型?
我的项目 (C#
) 处理许多大小约为 1 MB ~ 2 GB
的文件。使用SQL server 2008
数据库。从长远来看,我需要对它们进行一些操作,例如它们的大小总和......
乍一看,我计划将它们的大小以字节为单位存储(在 C# 代码 long
中,在数据库中 < code>BigInt),因为文件大小的性质及其精确性。我在想也许使用双精度并考虑以 MB 为单位的文件大小是一个更好的主意,因为它们中的大多数是 1~2000 MB
并且在谈论这个项目的文件时更有意义。这两种设计在代码(有许多数学运算时的性能问题)和数据库(对许多文件的批量操作)方面是否有任何优点/缺点?
My project (C#
) deals with many files about 1 MB ~ 2 GB
in size. SQL server 2008
database is used. In long-term I need to do some operations over them like total sum of their size and ...
At first glance I was planned to store their size in byte (in C# code long
, in database BigInt
) because of file size nature and its precise. I was thinking maybe its a better idea to use a double and consider file size in MB because most of them are 1~2000 MB
and make more sense while talking about files of this project. Is there any advantage/disadvantage over these two kind of designs both in code (performance issues when there are many mathematics operations) and database (batch operations over many files) ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
如果我没记错的话,文件大小在 .Net 中已经以 long 形式返回。另外,浮点数是 64 位,长整数也是 64 位,但浮点数速度较慢。
另外,如果您计算的是双精度数,则必须在每个文件上将长整型转换为双精度型,而如果等到最后,则只有一次转换。
以字节形式进行所有计算,然后在最后一步,您可以转换为浮点数以报告 2.051GB 或其他值。
If i remember correctly, file size is already returned as a long in .Net. Also, floats are 64bit and longs are 64bit, but floats are slower.
Also, if you do calculations are doubles, you will have to convert a long to a double on every file, while if you wait until the end, then there's only one conversion.
Do all of your calculations as bytes, then at the last step you can convert to a float to report something like 2.051GB or whatever.
将精确值存储在
long
中,格式化/解释为MB等应由客户端完成。Store the exact value in a
long
, formatting/interpreting as MB, etc should be done by the client.您应该使用
long
/BigInt,原因如下:You should use
long
/BigInt, for a few reasons:使用
uint
或ulong
,因为:对于您所描述的大小的文件来说,最大值为 4,294,967,295,uint 似乎是最佳解决方案,只要您可以保证它们永远不会大于这么多字节。它比
long
或double
占用的空间更少,而且只有 32 位,根据处理器等的不同,它的计算速度甚至可能更快。Either use
uint
orulong
, since:With a max value of 4,294,967,295 a
uint
seems the best solution for files of the size you're describing, as long as you can guarantee they'll never be any larger than this many bytes. It takes less space than along
or adouble
, and with only 32 bits it might even be quicker to evaluate depending on the processor and such.为什么不是十进制?
Decimal.MaxValue
具有以下属性:SQL 在大多数 .Net 有效范围内支持此功能。注意到转换的限制此处。
Why not Decimal?
Decimal.MaxValue
has this property:SQL supports this for most of the .Net valid range. Limitations in conversion are noted here.