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

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

• 有人打开一个燃烧气体表格（测试数据被输入其中）
• CombustionGas有7个不同的模块和字段（技术人员详细信息、测试前数据、测试数据）
• 用户填写这些内容并按下按钮上传，每个不同的模块被上传到一个表中，并带有相应的名称（dbo_pre_test_data等），单个表单测试本身的id号（本例中为CombustionGas）被用作该表的键

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

---

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

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

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

警告：听起来这是一个野外数据采集应用程序。我在上面建议的更改肯定是破坏性的更改，即使在RAD平台上也是如此。您必须权衡数据规范化的好处与应用程序的使用时间以及数据的用途。如果你只在一个赛季、学习或其他什么时候使用这个，那么我怀疑改变你的桌子结构是否值得。另一方面，如果您的组织将使用此应用程序及其数据多年，则值得一看

进一步阅读：

---

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

查找SQL表继承或子类型/超类型关系