将文件系统视为数据库是一种好习惯吗？

Question

我正在开发一个使用SQL作为数据库后端的ASP.net Web应用程序。我遇到的一个问题是，有时需要一段时间才能让我的DBA在数据库中创建或修改表格，在任何情况下都不允许我自己修改。

我希望用户能够上传包含数据的文件。

假设用户为名为Student_Records的表上传新记录。用户使用fname Bob和lname Smith上传记录。记录已分配主键123用户还会上传两个文件：attendance_record.pdf和homework_record.pdf。假设我有一个网络共享：\\ foo \ bar保存文件。

处理此情况的一种方法是设置一个表格Student_Records_Files，将关键字123与Bob Smith相关联。但是，由于我无法创建表格，所以我已经完成了不同的工作：当我将文件保存在服务器上时，我称之为123_attendance_record.pdf和123_homework_record.pdf。这样，我可以轻松识别每个文件关联的表记录，而无需创建新的SQL表。实际上，我使用文件系统本身作为连接表（显然，文件系统是一种数据库）。

在我检索文件的代码中，我扫描目录\\ foo \ bar并查找以Student_Records中每个主键编号开头的文件。

它看起来效果很好，但这是好的做法吗？

Answer 1

使用文件系统存储文件没有任何问题。这就是它的用途。

但有几件事要记住。

1. 我会考虑更好的存储文件的方法 - 也许是每个用户的目录，而不是简单地将用户ID附加到文件名。
2. 确保文件存储具有弹性，并以与数据库相同的规律进行备份。如果您的数据库配置为每10分钟为您提供一次备份，但您的文件存储仅每天（或更糟的一周）进行备份，那么您可能会陷入痛苦的世界。
3. 还要考虑如果用户上传两个同名文档会发生什么。

Answer 2

首先，我认为根据您的DBA响应程度来设计您的架构是一种不好的做法。基于这种方法的任何特定折衷方案可能也可能不是什么大问题，但随着时间的推移，它将导致设计不良的系统。

其次，将文件名设为关键对我来说似乎很危险;在没有意识到其重要性的情况下，没有任何人或应用程序修改文件名的保护。

第三，使用表来维护人和文件之间的连接的一个好处是，您可以添加其他数据，例如：文件上传时间，MIME类型是什么，文件是任何人都可以通过系统阅读，这个文件是以前文件的新版本等等。元数据可以非常强大，文件系统只提供有限的存储方式。

Answer 3

这里真的有两个问题。一个是，鉴于出于管理原因，您无法对数据库模式进行更改，是否可以设计一些解决方法。为此，我不得不说是的。你还能做什么？理论上，如果让DBA为您进行架构更改需要两周的时间，那么这两周应该添加到您给出的任何截止日期。在实践中，这几乎从未发生过。在我开始工作之前，我经常在一些文书工作或其他任何需要的地方工作，然后我会有两周一天的时间来完成这个项目。有时你只需要将它与橡皮筋和绑带一起放在一起。

两个是，在文件名中构建命名约定并使用它来识别文件及其与其他数据的关系是一个好主意。我有时候这样做了，这对我来说一般都有用，虽然我有一种非理性的情感感觉，这不是一个好主意。

另一方面，（a）通过将信息构建到文件名中，可以使计算机和人类轻松识别文件关联。 （只要命名约定足够简单，人类可读。无论如何。）（b）通过消除链接的单独存储，可以消除链接错误的可能性。当然，具有适当名称的文件可能不存在，但可能不存在具有适当密钥的数据库记录，或者此类记录中的文件引用可能为空或无效。所以它似乎解决了一个问题而没有产生任何新问题。

潜在的缺点是：（a）您可能在密钥中包含文件名中不合法的字符。您可以将这些字符剥离出来，否则可能会导致重复。唯一安全的做法是以某种方式逃避它们，这是一种痛苦。 （b）您可能超过文件名的法定长度。不像8.3天那样糟糕的问题。 （c）您无法共享文件。如果数据库记录指向文件，则两个db记录可能指向同一文件。如果必须制作文件的两个副本，这不仅会浪费磁盘空间，而且还意味着如果文件已更新，则必须确保更新所有副本。如果在您的应用程序中共享文件没有意义，那么这不是问题。

你必须以某种方式管理文件，但无论如何你必须这样做。

我真的想不出任何超越的弊端。正如我所说的那样，我已经完成了这个并没有遇到任何特殊问题。我很想看到其他人的回应。

Answer 4

我认为这不是一个好的做法，因为你使你的工作应用程序非常依赖于具体的实现细节，这将使得将来很难维护，或者如果其他人以后需要访问你的代码/ API。

现在天气你应该这样做或不是一个完全不同的问题。如果你真的受到了很大的性能影响，并且使用它的方式更容易处理，那么我会说继续打破规则。理想情况下，最好遵循最佳实践方法，但有时你必须稍微改变规则才能使事情发挥作用。

Answer 5

首先，为什么这是一个表更改而不是数据更改？设置表后，每次用户添加新文件时，只需更新该表中的行。如果你不得不忍受这一次，两周的延迟，那么咬紧牙关就可以完成它。

其次，不是试图解决问题，为什么不尝试解决问题呢？为什么实现表变化的过程如此缓慢？您是否至少能够使用开发数据库（您可以在其中控制测试并尝试这些更改）？即使它是您自己的笔记本电脑，您至少可以继续开发。与您的经理，DBA以及您需要的任何其他人一起工作，以改进流程。如果你的脚本经过正式的测试过程，然后你把它们交给DBA，那么它是否有助于加快速度，这样他就不需要自己测试脚本等了？

第三，如果这是一个生产数据库，那么你应该在这两周的延迟中建立你的开发周期。您知道DBA需要两周的时间来审核并实施生产中的更改，因此请确保如果您有一个发布功能的截止日期，那么您有足够的准备时间。

将这种“数据”构建到文件名中有其他人指出的固有问题。您没有关系完整性保证，并且可以在不了解应用程序/数据库的其余部分的情况下更改“数据”。

Answer 6

最好将所有内容保存在数据库中。

网络文件I / O充其量只是参差不齐。另外，它比DB I / O慢。

如果DBA很难对数据库进行小的更改，那么你 可能正在处理：

• 政治控制问题。也许他只是知道DB的东西而且受到了威胁 当他感觉到其他人在他的地盘上移动时。无论他的原因是什么，你都需要 完成工作。期。记录所有额外时间/沟通/工作
  你需要为每一个小小的变化做些什么，然后再与管理层接触 如果第一级管理层不愿意按自己的方式看事，那么 （无论他们的理由是什么），升级问题 进入下一级管理层。在过去，我已经以这种方式取得了成果 这更像是一个政治领土问题，而不是一个技术问题 DBA最终放弃并让我完全访问TEST系统但是 他还规定我需要学习他的测试过程，
  命名惯例，他的数据库标准和实践，他的测试方式等 我是游戏。
  我还需要解决因我引入的更改而引起的任何数据库问题 这是公平的，除了开发者帽子之外我还要戴DBA帽子 我得到了自己需要的自由，而且他还有一件事要担心。

• 流程问题。也许DBA需要提交您提交的每个小数据库更改 通过一系列的测试和性能分析。也许他有很高的成绩 规范化的数据库模式，因为他有大局，他需要规范化或者 对请求的数据库更改进行非规范化以适应现有模式 要求与他合作。请他提供完整的数据库设计图 深入了解他的数据库设计理念。用
  实现数据库更改 他的DB设计理念。表明你明白他正在尝试 保持数据库的良好状态（理解规范化，关系约束，
  检查约束）给他少担心。他需要相信你 不会破坏他的数据库。
  将所有小的更改累积到一个冗长的脚本中并提交给DBA 这样，你就不必等待每一个小小的变化都能完成他的所有工作 过程/测试。另外，你给他一个更大的图片视图 发展规划（与他的数据库设计理念同步）而不是 只是玩游戏。