SQL - 存储具有动态属性和约束的值

Question

我不确定我尝试做的事情是不正确/不可能，或者是否有更简单的方法而且我错过了这一点。

我正在使用SQL Server 2012

我想要做的是有一个表，可以存储与另一个表中的存储属性相关的值的行。基本上，键值对。问题是，我想确定哪些实体可以使用哪些键值。

例如， 我想要一张列出各种公司的表格，另一张表格可以存储文件＆＃39;为每个公司创建 - 这用于存储历史信息，另一个列出各个生产部门（生产阶段），另一个列出生产数据（KG，单位等），另一个列出每个月对这些数字的实际生产捕获。还有表格显示哪些生产部门可以使用哪些生产数据以及哪个公司有哪些生产部门。

有些公司在生产阶段和其他阶段都没有相同的阶段。

这些数字仅按月收集，因此我有一张描述一年中所有月份的表格。

每个制作部门可能会有类似的录制类型，但它们并不都具有相同的制作读数。

这是指向表格布局的图形表示的链接： http://tinypic.com/r/30a51mx/8 ..

我的最终结果是当用户输入程序的这一部分（通过传递FileID）时，用新添加的数字自动填充/更新表，并允许用户使用datagridview（或至少）编辑它从datagridview中选择要编辑的值）

我稍后需要编写报告，需要关注这些信息。

非常感谢任何帮助或建议。

由于

Answer 1

对于有效的数据库设计，了解两个主要要求非常重要：

1. 数据库设计是否应该从应用程序的角度或从高效的存储角度考虑到易用性。

这一点很大程度上决定了以下因素：

• 我们要存储多少数据，因此我们需要了解存储因素冗余的成本。良好的标准化DB可减少冗余。 你的数据库很好地规范化了，但这确实是需要的。通常，在当今的时间内，存储成本非常低，因此如果我们能够考虑设计稍微多余一些，那么应该没问题。除非您计划使用标准版本的SQL服务器，它在数据库大小方面有自己的限制。
• 数据检索和更新速度是否慢/快？标准化程度越高的数据库就越多，JOPE数量就越多。在您的情况下，如果您想在单个结果中返回多个属性的值（例如n），那么您需要在ProductionProperty表上进行 n join ，这实际上会降低查询性能，因此用户体验缓慢。因此，除非您的UI要求不高，并且您的用户可以忍受小的延迟，否则请继续使用标准化的数据库设计。

• ORM不匹配 - 由于关系数据库模型和对象模型（假设编程语言遵循OOP概念）通常不匹配，并且它们会在这样的标准化场景中发生重大影响;您需要花费更多时间进行编码或排除故障，这些情况可能需要您在对这些模型中的任何一个进行更改时感到痛苦。我建议你使用一个好的ORM框架来解决这个问题，并且更加了解ORM不匹配的情况。

  1. 您是否有单独的报表数据库或报表？ 基本上，这会转换为您的数据库是OLTP数据库还是报表数据库？如果数据输入人员日复一日地对这个数据库进行大量工作，那么考虑到第1点满足，标准化表格应该是合适的。但是，如果报告是主要需求，那么应该首选去标准化表格（这意味着您不需要这么多单独的表格）。
PS：主数据应该保存在自己的表中。我可以说Months肯定是主数据，因此UoM也是如此，除非你打算在UoM测量上做CRUD。另请注意，将月保存在单独的表中几乎不重要，尤其是在SQL中的列上可以强制执行相同的业务逻辑/约束时。