database - 为彼此共享大量数据的模型设计数据库表

Question

我目前正在开发一个应用程序，该应用程序本质上是一组由模块组成的单独表单。表格填写完毕后，它们将被上传到数据库。表单中的每个单独模块都被上传到该模块的表中。这是一个例子。

• 有人打开 CombustionGas 表单（测试数据输入到此）。
• CombustionGas 有 7 个不同的模块和字段（技术员详细信息、预测试数据、测试数据）
• 用户填写这些并按下按钮上传它们，每个不同的模块都被上传到具有相应名称（dbo_pre_test_data 等）的表中，单个表单测试本身的 id 号（在本例中为 CombustionGases）用作桌子的钥匙。

现在这适用于大多数情况。但是，一些测试具有相同的模块，但模块内的字段略有不同。因此，如果“预测试数据”中有 9 个字段，则在不同的测试中可能会有额外的 3 个字段。目前，我们刚刚将额外的列添加到表中，如果它们未在该测试中使用，则将它们设置为 null，但是随着我们创建越来越多的测试，这些表中已经有大量未使用的列.

我不是数据库设计方面的专家，但这并不适合我，我想知道当你有大量共享数据时，人们是否对最佳实践有什么建议，但也有可能出现这样的列差异.

标签： database

Answer 1

我不确定我是否理解域问题，但从长远来看，您可能会从重新思考表的结构中受益。

看起来像预测试数据这样的“模块”实际上不是您的数据组织的“基础”单元。这是因为它内部有单独的测试，其中一些在整个模块中共享，而另一些则不是。看起来每个测试都需要一个不同的表和一个键来将它与父模块表相关联。具体来说，测试表将包含仅与特定测试相关的记录。然后，模块表将包含每个模块唯一的数据（仅限模块 - 不是它们包含的测试）。然后，您可以将它们与连接表 ModuleTests 相关联，其中列出了每个 Modules 和 Tests 的外键。

警告：听起来这是一个现场数据收集应用程序。我上面建议的更改肯定是重大更改，即使在 RAD 平台上也是如此。您必须权衡标准化数据的好处与应用程序将使用多长时间以及您将使用数据的目的。如果您只在一个季节、学习或其他时间使用它，那么我怀疑改变您的表格结构是否值得。另一方面，如果您的组织打算使用此应用程序及其数据多年，那么值得研究一下。

进一步阅读：https ://www.amazon.com/Database-Design-Mere-Mortals-Hands/dp/0321884493

此外，听起来很明显：创建一个测试服务器环境来测试您的更改。不要只更改生产中使用的表。