我即将在我们的应用程序中实现一项功能,允许用户“上传”PDF 或 Microsoft PowerPoint 文档,然后该应用程序将在查看器中向其他用户提供该文档(这样他们就无法“下载”)它在“另存为..”的意义上)。

我已经知道如何在数据库列中保存和检索任意二进制信息,但由于这将是我们应用程序的常用功能,我担心该解决方案会导致数据库表变得非常大(因为我们知道我们的一位客户会想要将PowerPoint 文档中的视频)。

我知道有一种方法可以在 Oracle 中创建“目录”对象,但是有没有一种方法可以使用此功能来存储和检索数据库服务器上其他位置保存的二进制文件?

或者我对数据库大小过于偏执?

(为了完整性,我们的应用程序是 .Net WinForms,使用 CoreLab / DevArt OraDirect.Net 驱动程序 到 Oracle 10g)

有帮助吗?

解决方案

几个选项:您可以将 BLOB 列放在自己的表空间中,具有自己的存储特性;您可以将 BLOB 存储在它们自己的表中,并通过 ID 列链接到另一个表。无论哪种情况,正如您所建议的,您都可以将列定义为 BFILE,这意味着实际文件存储在数据库外部的目录中。可能需要担心的是,BFILE LOB 不参与事务,并且无法与数据库的其余部分一起恢复。

Oracle 10gR2 SQL 参考第 2 章第 23 页开始对此进行了全部讨论。

其他提示

我想这取决于你认为什么是巨大的。

这确实取决于用例。如果文档很少被访问,那么将其放入数据库中就可以了(优点是获得“免费”备份,例如使用数据库)。

如果这些文件将被一遍又一遍地访问,您可能最好将它们直接放在磁盘上并仅存储位置,或者甚至(如果其带宽确实很高)查看类似的内容 莫吉莱FS

没有人能够对此给出“是”或“否”的答案。

您可以使用普通的 LOB 列类型并设置该字段的存储参数,以便它位于单独的表空间上。在可以处理大量数据的地方创建表空间,这样您就可以最大程度地减少影响。

如果您对磁盘使用情况非常偏执,您还可以通过将表空间标记为这样来压缩表空间。大致如下:

创建表空间binary_data1 datafile some_san_location默认压缩存储(...)

根据我的经验,包含附件文件名的简单 VARCHAR2 字段是更好、更简单的解决方案。文件系统大小比数据库大小更容易管理。

数据必须存放在某个地方,无论是在数据库内部还是只是存储到(服务器)可访问文件路径的链接,您仍然需要占用空间。

我过去只使用过简单的 LOB 字段,它似乎工作得很好。如果将数据保存在数据库中,至少可以减少备份的麻烦 - 您可能有大量数据需要备份,但当您恢复它们时,它们都会存在。拆分二进制文件意味着如果您不小心备份内容,您可能会破坏数据库或丢失数据。

仅存储链接或可用于构建链接的 ID 的原因之一是,通常用于 Oracle DB 的存储相当昂贵。如果您有大量大文件,将它们放在较便宜的磁盘阵列上通常会更具成本效益。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top