对于巨大的文件大小,在代码和数据库中使用什么类型?

发布于 2024-09-30 20:18:08 字数 376 浏览 3 评论 0原文

我的项目 (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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

穿越时光隧道 2024-10-07 20:18:09

如果我没记错的话,文件大小在 .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.

﹎☆浅夏丿初晴 2024-10-07 20:18:08

将精确值存储在long中,格式化/解释为MB等应由客户端完成。

Store the exact value in a long, formatting/interpreting as MB, etc should be done by the client.

树深时见影 2024-10-07 20:18:08

您应该使用 long/BigInt,原因如下:

  1. 文件大小以字节为单位,这是一个精确的离散度量 - 因此您不妨使用精确的离散值。
  2. 如果您使用小数,则很难知道您正在处理什么比例 - kb?字节? mb?但如果您处理的是整数,您可能会知道它是以字节为单位的。
  3. 没什么大不了的,但在大多数使用长数的处理器上,性能比使用小数的处理器稍好一些。
  4. 据我所知,这是常规做法。

You should use long/BigInt, for a few reasons:

  1. File sizes are in bytes, which are a precise discrete measure -- so you might as well use a precise discrete value.
  2. If you use a decimal, it's hard to know what scale you're dealing with -- kb? bytes? mb? But if you're dealing with integers, you'll probably know that it's in bytes.
  3. Not a super big deal, but performance is slightly better on most processors with longs than with decimals.
  4. As far as I know, it's the conventional thing to do.
梦屿孤独相伴 2024-10-07 20:18:08

使用 uintulong,因为:

  • 文件大小不能为负,并且
  • 文件不能占用字节的一小部分(例如 3,231.5 字节不是有效答案)

对于您所描述的大小的文件来说,最大值为 4,294,967,295,uint 似乎是最佳解决方案,只要您可以保证它们永远不会大于这么多字节。它比 longdouble 占用的空间更少,而且只有 32 位,根据处理器等的不同,它的计算速度甚至可能更快。

Either use uint or ulong, since:

  • you can't have negative file sizes, and
  • you can't have files that take fractions of bytes (e.g. 3,231.5 bytes is not a valid answer)

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 a long or a double, and with only 32 bits it might even be quicker to evaluate depending on the processor and such.

鼻尖触碰 2024-10-07 20:18:08

为什么不是十进制Decimal.MaxValue 具有以下属性:

该常数的值为正数
79,228,162,514,264,337,593,543,950,335

SQL 在大多数 .Net 有效范围内支持此功能。注意到转换的限制此处

Why not Decimal? Decimal.MaxValue has this property:

The value of this constant is positive
79,228,162,514,264,337,593,543,950,335

SQL supports this for most of the .Net valid range. Limitations in conversion are noted here.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文