您会将二进制数据存储在数据库或文件系统中吗？

这是一个之前被问过的问题(大文本和图像在sql中),但主要用于将要更改的数据.在我的情况下,数据将被存储并且永远不会改变.把所有东西放在一起似乎是明智的.

我有什么理由不将静态二进制数据存储在数据库中吗？

假设这是一件明智的事情,将这些数据存储在单独的表中是否有任何好处？(你可能现在开始意识到我不是数据库专家......)

澄清:可能会有不超过10-20个用户,但这些用户将在美国和英国.在任何情况下都必须传输二进制数据.

1> Mehrdad Afsh..：

---

在DB中存储数据的优点是利用数据库安全机制并降低维护成本(备份,...).它的缺点是增加了数据库负载和消耗连接(这对于每个连接的许可数据库服务器来说可能很昂贵).如果您使用的是SQL Server 2008,则FILESTREAM可能是一个不错的选择.

顺便说一句,对于Web应用程序(或任何其他可能需要流式传输数据的应用程序),在数据库外部存储数据通常更为明智.

---

@jrwren我的观点是你不需要单独备份文件并手动保持它们同步,以确保数据库备份中包含的数据的完整性.根据具体情况,*可以*更简单,更便宜.

---

我不确定它如何降低维护/备份成本.如果有的话,它会增加它们,因为通常备份数据库比备份文件系统更昂贵,更苛刻.你能详细说说吗？

2> 小智..：

---

所有这些都谈到了当表中有一个LOB时,做一个"select*from table"会导致巨大的内存和/或带宽问题,这是一个非问题.返回的所有内容都是指向所讨论的LOB的指针.没有足够的声誉将评论放在上下文中,但看着这个的人应该知道这不是问题.

3> Vasil..：

---

如果要存储BLOBS,最大的缺点是内存消耗.你能想象来自x的select*会为成千上万的记录做些什么吗？

正如Mehrdad所说也有优势.因此,如果您决定采用该方法,则应尝试设计数据库,以便大多数查询返回较少的结果,其中包含BLOB数据.也许例如为此目的建立一对一的关系.

---

恕我直言,这不是一个有效的论点.在大多数情况下做`select*from x`是一个坏主意,除了你需要在你的应用中使用*每个*列的那个.将blob放在单独的表中更糟糕,因为它需要连接并使请求复杂化.

4> Nils Weinand..：

---

从原则的角度解决问题,关系数据库(主要)用于存储结构化数据.如果您无法创建查询条件或加入数据元素,则它可能不属于数据库.我没有看到在WHERE子句中使用的图像BLOB,所以我要说它保持在数据库之外.另一方面,CLOB可用于查询.

---

我们可能也不会在WHERE子句中使用电话号码,因为根据电话号码搜索任何内容都不常见(除非您正在使用反向查找系统).也就是说,我们将电话号码存储在数据库中,而不是存储在外部文件中,即使它很少用作连接或过滤条件.我的意思是,这个原因不足以放弃在关系数据库中保存图像的可能性.

---

但是你可以*在电话号码上查询条件,或者将它用于连接,这是BLOB列无法合理的.

5> dkretz..：

---

我熟悉一个相当大的OSS项目，该项目从一开始就决定将图像存储在MySQL数据库中，事实证明，这是自此以来他们一直在处理的三大坏主意之一。（“无情地重构”是一种厌恶的事实，但这是另一回事了。）

在这引起的严重问题中：

超过最大有效数据库大小（mysql）。（图像所需的总空间至少比其他图像大2个数量级）。

图像文件失去其“文件性”。没有日期大小等，除非（冗余地）存储为日期（这需要管理代码）。

无论是存储还是操作，任意字节序列都不能一直很好地处理。

“我们永远都不需要从外部访问图像”是一个危险的假设。

易碎。因为整个安排是不自然和敏感的，而且您不知道接下来会在哪里咬人（有助于反重构思维）。

好处？除了当时可能是阻力最小的途径，我没有想到。

6> JoshBerke..：

---

我认为这取决于您的建筑应用.如果您正在构建CMS系统,并且数据的使用将在Web浏览器中显示图像,则将图像保存到磁盘而不是放入数据库可能是有意义的.虽然老实说,我会同时做到这两点,这可能允许将服务器添加到服务器场而无需在整个地方复制文件.

另一个用例可能是复杂的对象,例如工作流,甚至是具有大量相互依赖性的业务对象.您可以将这两种格式序列化为二进制或基于文本的格式,并将它们保存在数据库中.然后你就可以获得数据库的好处:ATOMIC,备份等......

我认为人们不应该首先使用select *查询.你所做的是提供两种获取数据的方法,一种方法返回摘要信息,第二种方法返回blob.我无法想象为什么你需要同时返回数以千计的图像.