数据库规范化和结构

我有了下面的表格数据库规范化和结构

Customers 
Transactions (Type A) 
Transactions (Type B)

我们正在增加一个Comments表

Customers多了一个更多Transactions A和Transactions B Comments可以与数据stucture要么该Transactions或Customer

我们正在对数据库进行内部讨论格式。

一边想创建一个评论表，3个十字表。一边想创建一个表注释与外国关键客户和2个可空键交易。

有没有说一个比其他更好的一个范式的规则？有什么共识吗？

编辑：

更多的答案和细节

评论将永远不会与一个以上的客户
评论将永远不会与一个以上的交易
评论仅会相关的关联与交易A，交易B或两者都不相关;但从来都
客户和交易可能有0或多个注释

来源

2013-04-29 Bill Bonar

我投“......创建一个表评论与外国关键客户和2个可空键交易”。恕我直言...... PS：是否有任何机会组合交易ID +交易日期（例如）将是唯一的系统范围？一些“组合外键”唯一地标识了一个交易（不管类型a或类型b），这将是理想的解决方案。 – paulsm4 2013-04-29 19:17:05

更多的信息会有帮助。与多个客户或同一类型的多个交易（A或B）相关联的评论是否合法？与客户，交易A和交易B有关的评论是否合法？评论是否需要有一些或任何这些关系？ – 2013-04-29 19:21:18

最重要的范式（1NF-6NF，BCNF和衍生工具）不允许在表中的空值，因为所有的人都只是基于与价值的关系，而不是空值。更有用的是有一个称为“正交设计原则”的设计原则，它指定具有相同属性的元组不应该被允许出现在模式中的多个位置。看起来您的两个交易表和在多个地方有评论可能会违反正交设计规则。

您可以创建，结合你的两个交易表的共同属性，包括注释属性（父/子模式）父事务表。

来源

2013-04-29 20:38:27 sqlvogel

这两笔交易完全是独一无二的。因此，您的投票是针对单个评论表，并将表交给每个交易和客户？ – 2013-04-29 20:55:48

如果他们将共享相同的属性，则它们不是“唯一”的 - 它们重叠。通常最好避免具有重叠属性集合的表。 *将注释与事务标识符相关联的一个*表应该这样做，并且将避免需要多个可为空的列。 – sqlvogel 2013-04-29 21:15:22

数据库规范化和结构

回答

相关问题