在数据库中存储文件大小

Question

我目前正在开发一个系统，涉及存储多个研究及其内容的细节（一个研究通常包含 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...

我没有太多关于存储文件大小的经验，想知道最有效/实用的方法是什么？

- Rion Williams

Answer 1

如果你要明确地存储大小，那么请存储字节数。使用其他单位时会有太多的混淆和不确定性。

例如：不同的人可能将kb解释为：

- 千字节 - 千比特 - 基比字节 - 基比特 ...而且一个千字节到底有多大呢? 话虽如此，如果你在数据库中存储实际数据，我并没有立即看到明显的理由来明确地存储数据的长度。

- Matt Ball

---

我不确定为什么它被存储了 - 因为我并没有真正从事系统的那一方面。但是，我知道它被存储了，并且想知道是否有人对此有什么意见或者是否有一些"最佳实践"或其他建议性用途来存储文件大小。 - Rion Williams

将数据长度存储起来在云环境中可以很有用，因为文件大小的请求可能会受到计量。总的来说，在表示存储在其他地方的文件的行中记录文件大小可能更加有效。 - Cameron Wilby

Answer 2

我在数据库中以整数形式存储文件大小（单位为字节）。MySQL的整数字段是有符号的，最大值为2147483647，因此可以轻松地存储高达2GB的文件大小。

- Stefaan Colman

Answer 3

没有标准答案。我喜欢Matt的回答，因为它更精确。我喜欢Abe的回答，因为它节省空间……（是的，在表格中的空间比在文件系统中的空间更具“影响力”）。

真正的答案是，你存储该值的目的是什么？这是用于向存储数据的用户发票的机制吗？那么你必须依靠合同。这是为了测量驱动器上的空间……如果是这样，文件确实占用一定数量的“块”，而不是一定数量的字节。如果最小块大小为2KB，则应说每个文件都是2kb的倍数……如果你存储该值或该值乘以2kb的值取决于你。

也许你正在存储该值，因为检索算法有两条优化路径，一条针对较大的文件，另一条针对较小的文件，并且该过程想要知道大小，而不必询问文件系统。在这种情况下，也许只需要一个“is_greater_than_x_kb”标志列。

没有人能告诉你你的要求是什么。现有答案给出的唯一东西是意见，而不是正确答案。

- Stephanie Page

---

谢谢Steph- 我知道没有确切的答案，我只是想听听人们对存储文件大小的不同原因以及以某种方式存储它们的好处的想法。每个人的回答都非常有帮助。 - Rion Williams

它们都很有帮助，但不能替代明确的需求。我看到的95%问题源于缺乏明确的需求。此外，76%的统计数据完全是捏造的。;-) - Stephanie Page

我想不出存储文件大小的理由，除非这是一个要求。正如Stephanie所说，“is_greater_than_x_kb”有用处。如果文件大小是某个BA设计的一部分，以便应用程序可以检查是否获得了正确的文件，请询问他们是否考虑使用校验和或其他类型的文件唯一标识符，以便应用程序知道它已经获取到了它想要的文件。 - RC_Cleland

我也是这样，RC...所以我在推动我们提出需求。太多的编程是因为我们IT部门认为业务需要什么而进行的。也许就像在Sharepoint中一样...你想在你的“文档库”<--Sharepoint的东西>中看到一个名称列，一个上传时间列，一个大小列。因此，在用户尝试下载文件之前，他会知道可以期望什么。但现在，20MB已经不算什么了。 - Stephanie Page

Answer 4

如果你永远不会有小于1kb的数据，我个人会选择将# of kb作为int列（只要它是良好记录的）。bigint占用的空间是int的两倍（8字节对4字节），只要文档说明得足够清楚，人们就不应该太困惑。

- Abe Miessler

---

如果他们存储的文件大小不超过20MB，我认为在描述文件大小时节省4个字节并不是一个最优先考虑的事情。;-) - Stephanie Page

大多数Linux/Unix工具中存储的默认单位是“字节”。 - Yousha Aleayoub