将文件存储在 SQL Server 中还是将它们保留在文件服务器上?

发布于 2024-07-27 02:46:32 字数 811 浏览 6 评论 0原文

目前,我们有数千个 Microsoft Word 文件、Excel 文件、PDF、图像等存储在文件夹/子文件夹中。 这些由应用程序定期生成,并且可以在该应用程序中随时访问。 当我们寻求升级时,我们现在正在考虑将所有这些文档存储在 SQL Server 2005 中。 这样做的原因是能够压缩文档、添加附加字段来存储有关这些文档的更多信息以及在必要时应用索引。

我想我所追求的是使用 SQL Server 作为文档存储库而不是将它们保存在文件服务器上的优点和缺点,以及您在执行此操作时可能拥有的任何经验。

我们将使用 C# 和 Windows Workflow 来完成此任务。

感谢您的意见。

编辑


文件有多大?

大小在 100k = 200k 之间(平均 70KB)

有多少个?

目前大约有 310 万个文件(包括 Word/Excel 和 PDF),并且每天会增加 2,600 个文件。 (增长也会随着时间的推移而增加)

阅读量有多少?

这个很难量化,因为我们的旧系统/应用程序很难解决这个问题。


类似帖子中指出的另一个有用的链接涵盖了两种方法的优缺点。

存储在数据库上的文件与文件系统 - 优点和缺点

Currently we have thousands of Microsoft Word files, Excel files, PDF's, images etc stored in folders/sub folders. These are generated by an application on a regular basis and can be accessed at any time within that application. As we look to upgrade we are now looking into storing all these documents within SQL Server 2005 instead. Reasons for this are based on being able to compress the documents, adding additional fields to store more information on those documents and applying index’s where necessary.

I suppose what I’m after is the pros and cons of using SQL Server as a document repository instead of keeping them on the file server, as well as any experience you might have in doing this.

We would be using C# and Windows Workflow to do this task.

Thanks for your comments.

Edit


How big are the files?

between 100k = 200k in size (avg. 70KB)

How many will be?

At the moment it’s around 3.1 Million files (ranging from Word/Excel and PDF's), which can grow by 2,600 a day. (The growth will also increase over time)

How many reads?

This one is difficult to quantify as our old system/application makes it hard to work this out.


Also another useful link pointed out on a similar post covers the pros and cons of both methods.

Files Stored on DB vs FileSystem - Pros and Cons

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(7

旧梦荧光笔 2024-08-03 02:46:32

文档大小的经验法则是:

size < 256 kb: store in db
265 kb < size < 1 MB: test for your load
size > 1 Mb: store on file system

编辑:此经验法则也适用于 SQL Server 2008 中的 FILESTREAM 存储

rule of thumb for doc size is:

size < 256 kb: store in db
265 kb < size < 1 MB: test for your load
size > 1 Mb: store on file system

EDIT: this rule of thumb also applies for FILESTREAM storage in SQL Server 2008

鹿童谣 2024-08-03 02:46:32

如果您一路升级到 SQL Server 2008,那么您可以使用新的 FILESTREAM 功能,该功能允许文档显示为表中的列,但仍作为文件驻留在共享上,可以直接访问该共享通过程序(如 Word)。

If you upgrade all the way, to SQL Server 2008, then you can use the new FILESTREAM feature, that allows the document to appear as a column in a table, yet to reside as a file on a share, where it can be directly accessed by a program (like Word).

壹場煙雨 2024-08-03 02:46:32

我会两者兼而有之。

我会用唯一的名称重命名文件,从而更易于管理,并且我会将所有元数据保留在数据库内(文件名、内容类型、文件系统上的位置、大小、描述等),因此文件是通过数据库访问(间接)。

优点:

  • 文件容易处理; 您可以混合使用多个驱动器,
  • 数据库可以保存任意数量的元信息,包括您可以搜索的文件描述。
  • 跟踪文件访问和其他统计信息
  • 使用各种范例重新排列文件:树(目录结构)、标签、搜索或上下文

您也可以在驱动器上进行压缩。 您可以使用 RAID 来实现备份和速度。

I would have both.

I would keep the files renamed with an unique name, thus easier to manage, and i would keep all meta data inside the database (file name, content-type, location on file system, size, description, etcetera), so the files are accessed through the database (indirectly).

Advantages:

  • files are easy to handle; you can bring several drives in the mix
  • the database can keep any number of meta information, including file description on which you can search against.
  • keep track on file accesses and other statistic information
  • rearrange the files using various paradigms: tree (directory structure), tags, search or context

You can have compression on a drive also. You can have RAID for backup and speed.

隐诗 2024-08-03 02:46:32

我们正在谈论什么样的文件?

在 SQL Server 中存储文档可能很有用,因为您可以将文档与其他表相关联,并使用全文索引等技术以及执行模糊搜索等操作。

缺点是创建文档的备份可能有点困难。 还可以使用 NTFS 压缩或其他技术进行压缩。

What kind of documents are we talking about?

Storing documents in your SQL server might be useful because you can relate the documents to other tables and use techniques like Full-text indexing and do things like fuzzy searches.

A downside is that it might be a bit harder to create a backup of the documents. And compression is also possible with NTFS compression or other techniques.

筑梦 2024-08-03 02:46:32

这些文档是基于文本的吗?您是否计划使用 SQL Server 的全文搜索来搜索这些文档? 如果没有,我认为将这些文档存储在数据库中没有任何好处。 当然,您始终可以存储与文档相关的元数据,包括数据库的路径信息。

Are these documents text based and are you planning on using SQL Server's full text search to search these documents? If not, I don't see any benefit in storing these documents on the database. Ofcourse, you can always store the meta data related to the documents including the path information to the database.

寂寞笑我太脆弱 2024-08-03 02:46:32

在数据库中存储文档的一大好处是控制对它们的安全访问变得更加容易,因为您可以通过应用程序中的访问控制来完成这一切。 将它们存储在文件服务器上需要处理文件和文件夹级别的访问权限,以防止任何直接访问。 还将它们放在数据库中以实现单点备份,因此您可以更轻松地制作完整副本和/或在需要时移动它。

A big benefit of stroing docs in the DB is it becomes much easier to control security access to them, as you can do it all via access control in your app. Storing them on a file server requires dealing with access priveledges at the file and folder level to prevent any direct access. Also have them in a DB makes for a single point of backup, so you can more easily make a full copy and/or move it around if needed.

深海夜未眠 2024-08-03 02:46:32

您可能应该考虑购买一个或使用 WSS / SharePoint,而不是编写自定义 DMS(文档管理系统),因为这将处理所有日常细节(存储、索引、元数据)并让您在其上构建自定义功能。

Rather than writing a custom DMS (document management system), you should probably consider buying one or using WSS / SharePoint as this will handle all the mundane details (storage, indexing, meta-data) and let you build your custom functionality on top.

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