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

本文关键字:约束 属性 动态 存储 SQL | 更新日期: 2023-09-27 18:04:53

我不确定我正在尝试做的事情是否完全不正确/不可能,或者是否有更简单的方法,我错过了重点。

使用SQL Server 2012

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

例如,

我希望一个表列出各种公司,另一个表存储为每个公司创建的"文件"-这用于存储历史信息,另一个表列出各种生产部门(生产阶段),另一个表列出生产数据(公斤,单位等),还有一个表列出每个月针对这些数据的实际生产捕获。也有表格显示哪些生产部门可以使用哪些生产数据,以及哪个公司有哪些生产部门。

一些公司在生产中有相同的阶段,以及其他公司没有的额外阶段。

这些数字是按月计算的,所以我有一个表来描述一年中所有的月份。

每个生产部门可能有相似类型的记录要捕获,尽管它们并不都具有相同的生产读数。

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


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

之后我需要写报告,这些报告需要以这些信息为中心。


如有任何帮助或建议,我将不胜感激。

谢谢

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

对于一个有效的数据库设计,理解两个主要要求是非常重要的:

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

这一点在很大程度上是由以下因素决定的:

  • 我们要存储多少数据,所以我们需要对存储分解冗余的成本有一些了解。良好的规范化数据库可以减少冗余。您的DB正常化非常好,但这真的需要吗?一般来说,现在的存储成本非常低,所以如果我们能想到稍微冗余一点的设计,应该没问题。当然,除非你打算使用标准版本的SQL server,它在数据库大小方面有自己的限制。
  • 数据检索和更新是慢还是快?数据库规范化程度越高,join次数越多。在您的例子中,如果您希望在单个结果中返回多个属性的值,例如n,那么您需要在ProductionProperty表上进行n次连接,这将从本质上降低查询性能,从而降低用户体验。所以,除非你的UI要求不是很高,并且你的用户可以忍受小延迟,否则就使用标准化的数据库设计。
  • ORM不匹配-由于关系数据库模型和对象模型(假设编程语言遵循oop概念)通常不匹配,并且它们将在像这样的规范化场景中严重不匹配;您将需要花费更多的时间进行编码或故障排除,这可能需要您在更改这些模型时痛苦地扭动。我建议您使用一个好的ORM框架来解决这个问题,并更多地了解ORM不匹配的场景。

  • 您是否有单独的报告数据库或报告表? 基本上这转化为您的数据库是OLTP数据库还是报告数据库?如果数据输入人员每天都要大量处理这个数据库,那么考虑到第1点已经满足,规范化形式应该是合适的。然而,如果报告是一个主要的需求,那么非规范化的形式应该首选(这意味着你不需要这么多单独的表)。

PS:主数据应该保存在自己的表中。我可以说月份绝对是一个主数据,UoM也是,除非你也计划对UoM度量做CRUD。还要注意,将月份保存在单独的表中几乎没有关系,特别是当SQL中的列可以强制执行相同的业务逻辑/约束时。