在数据库中存储文件大小
我目前正在开发一个系统，该系统涉及存储多个研究及其内容的详细信息（一项研究通常可以包含 1 < X < ~2000 个图像）。我和我的同事正在讨论在数据库中存储文件大小（特别是图像大小）的最佳方法是什么。
文件大小通常范围为 < 1kB 至 > 20MB。
我们目前正在争论将图像大小存储为：
# of kilobytes (as an integer value)
# of bytes (as a large integer value)
# of megabytes (possibly as a decimal value)
Other Options...
我没有太多地存储文件大小，并且想知道实现此目的最有效/实用的方法是什么？
I am currently working on a system that involves storing multiple studies and details of their contents (A study can typically contain 1 < X < ~2000 images). My colleagues and I were discussing what might be the best method of storing files sizes (specifically the image sizes) in a database would be.
The file sizes typically range from < 1kB to > 20MB.
We are currently debating between storing the images sizes as:
# of kilobytes (as an integer value)
# of bytes (as a large integer value)
# of megabytes (possibly as a decimal value)
Other Options...
I haven't worked with storing file sizes much and was wondering what might be the most efficient / practical method of accomplishing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您要显式存储大小，请存储字节数。使用其他单位时存在太多混乱/歧义。
示例：不同的人可能会将
kb解释为：...无论如何，千字节有多大？
也就是说，如果您将实际数据存储在数据库中，我根本没有看到显式存储数据长度的立即令人信服的理由。
If you're going to explicitly store the size at all, store the number of bytes. There is just too much confusion/ambiguity when using other units.
Example: different people might interpret
kbas:...and how big is a kilobyte, anyway?
That said, if you're storing the actual data in your database, I do not see an immediately compelling reason to explicitly store the length of the data at all.
没有正确答案。我喜欢马特的回答，因为它很精确。我喜欢 Abe 的答案，因为可以节省空间......（是的，表中的空间比文件系统上的空间更具“影响力”）
真正的答案是，您存储该值的目的是什么？这是一种向存储数据的用户开具发票的机制吗？那么你就必须依赖合同。这是为了测量驱动器上的空间吗？如果是这样，文件实际上占用了一些“块”而不是一些字节。如果最小块大小是 2KB，那么您应该说每个文件都是 2kb 增量...如果您存储该值或该值乘以 2kb，则由您决定。
也许您正在存储该值，因为检索算法有 2 种优化路径，一种用于较大的文件，一种用于较小的文件，并且该进程希望在不询问文件系统的情况下知道大小。 （在这种情况下，也许您只需要一个“is_greater_than_x_kb”标志列。）
这里没有人可以告诉您您的要求是什么。现有答案给您的唯一信息是意见，而不是正确答案。
There is no right answer. I like Matt's answer for reasons of precision. I like Abe's answer for reasons of space saving... (Yes, space in a table is much more 'impactful' than on the Filesystem)
The real answer is, for what purpose are you storing the value? Is this for a mechanism to invoice the user storing the data? Then you'd have to rely on the contract. Is this to measure space on a drive... if so, files REALLY take up some number of 'blocks' and NOT some number of bytes. If the minimum block size is 2KB then you should say that EVERY file is increments of 2kb... If you store that value or that value times 2kb is up to you.
Maybe you're storing the value because the retrieval algorithm has 2 optimization paths, one for larger files and one for smaller and that process would like to know the size WITHOUT interrogating the file-system. (in this case maybe just an "is_greater_than_x_kb" flag column is all you need.)
No one here can tell you what your requirement is. The only thing the existing answers give you is an opinion, not a right answer.
我将文件大小以字节为单位存储在数据库中。 mysql 的（有符号）整数字段的最大值为 2147483647，因此可以毫无问题地存储高达 2GB 的文件大小。
I store filesizes in bytes as an integer in the database. The (signed) integer field of mysql has a maximum value of 2147483647 so filesizes up to 2GB can be stored without a problem.
我个人会选择 # of kb 作为 int 列（只要你永远不会有任何小于 1kb 的东西）。 bigint 占用两倍的空间（8 字节 vs 4 字节），只要有充分的记录，人们就不应该太困惑。
I would personally go for # of kb as an int column (as long as you will never have anything smaller than 1kb). bigint takes up twice as much space (8 bytes vs 4) and as long as it's well documented people shouldn't be too confused.