所以目前在我们的系统中，我们一直在数据库中存储图像文件（SQL Express 2005）。 不幸的是，它并没有被认为会达到SQL Express许可证所允许的最大数据库大小。 所以我提出了一个在文件系统中存储图像的计划，并且只对文件在数据库中的位置进行索引。
计划是将OptionsTable中的根path保存为ImagesRoot ，然后只保存表中的实际imageID，这基本上就是图像logging中的PK的FK。 我已经确定，最好是根据每1000张图像将其分成几个子目录（ImagedID / 1000）\（ImageID％1000）（例如ImageID为1999，它将在％ImageRoot ％\ 1 \ 999）。
我正在寻找这个系统的任何潜在的陷阱，任何可以改善的东西，因为我已经收到来自公司所有者的一些阻力，希望一切都在数据库中。 顺着这些路线，我也会理解为什么它应该全部在数据库中。
我应该提到，我们已经实现了自动备份，这些备份可以运行在我们所有的客户数据库以及由我们的程序生成的任何需要在一段时间内保存的文件。这些是可选的，但如果有人不使用我们的系统预计他们正在使用自己的或数据丢失不是我们的问题（这是如果我们的系统失败，他们正在使用它！）。
谢谢
编辑
有人build议使用2008 R2作为可能的解决scheme。 这是一个好主意，我只需要看看涉及使用这些数据库的传统程序的问题。 并不是所有的人都使用stored procedures，有些人不太友善。
如果你打算打破目录结构（你应该），你不应该使用你提出的方法，这将容易聚集。 你应该实现相同的概念，但基于文件名的哈希值。
例如，而不是你的build议，做一个文件名的散列（我将使用md5），然后创build基于散列值的子节点：
Your proposal: FILE=1999, H1=1, H2=999, FILEPATH=1\999\1999 FILE=1998, H1=1, H2=998, FILEPATH=1\998\1998 FILE=1997, H1=1, H2=997, FILEPATH=1\997\1997 Hashed solution: FILE=1999, MD5=2554fe5cd0a1b3fb7f9ec112fd326744, H1=2, H2=54, FILEPATH=2\54\1999 FILE=1998, MD5=82ec15656dd2b8a3e50ff36643a713ad, H1=8, H2=2e, FILEPATH=8\2e\1998 FILE=1997, MD5=9cc2e1e538bd538014d294138a85e20b, H1=9, H2=cc, FILEPATH=9\cc\1997
这样做的好处是可以更均匀地分散文件夹的利用率，从而使您能够跨文件夹传播文件夹以提高性能等。
您的数据库可能具有内置的散列函数，可以让您快速计算path，还可以轻松地在代码中计算一次，并保存整个path。
我的MD5的例子可能不是标准，（我认为SHA1更常见），但只是为了得到一个工作的例子。
将所有东西（主要是图像和文件）放在db中的主要原因是保护问题。 为了保护我的意思，在这种情况下，访问控制，以保护copywrited的东西。 通过这种方式，您可以控制何人以及何时查看/访问特定资源并进行跟踪，并通过login过程还可以决定谁有权访问这些资产。
为什么在R2中达到最大分贝大小（10GB）？
存储在文件系统中的BLOB不计入大小限制。
有关这个非常好的function的更多信息：