如何识别交易表？

Question

我的数据库包含前缀为mt_的主表和前缀为tr_的交易表。但是当我浏览数据库时，我开始想知道事务表和主表的实际定义是什么。据我所知，事务表应该有一个复合主键（主键由两个或多个其他表的PK组成）。但是当我查看数据库中的事务表时，有些表具有前面提到的复合键，它还有表标记为tr_但只有一个键标记为PK，并且它们也有PK键属于其他表，但它们甚至没有被标记为FK ......

那么这里有没有人可以解释主表和事务表之间的区别以及如何在数据库中识别它们？

更新 这是我的db

的一个例子

tr_orders

OrderId int PK
CustomerId int Fk
OrderDate datetime  etc

tr_reciept

RecieptId int PK
OrderId int **(but not FK)**
PaindAmount money
recieptDate datetime

以下是完整两个表的表结构：

tr_orders

tr_reciept

我不明白为什么这些表是 tr 表？

Answer 1

为什么你不总是在所有外键上放置主键

当事情发生时＆＃39;它进入交易。有人在商店买了一个玩具。创建一行记录它是一个玩具，它发生的日期时间和成本。

其他人十分钟后买了一个玩具

我们的交易表中有两条记录：

Date          Time     Product_Key     Shop_Key    Amount
--------------------------------------------------------------------------
18 Dec 2015   13:05    7                12           10
18 Dec 2015   13:15    7                12           10

这里我们有两个外键：Product_Key和Shop_Key

我们无法在这两个外键上创建PK，因为那时一家商店只能卖一个玩具。

因此PK不会自动进行所有FK的

但真的要带走的是你的数据模型（表，字段，键，数据类型）反映了你的业务所做的事情。如果一家商店真的只能销售一个玩具，那么在这两个领域拥有PK将是一个有效的数据模型。

事务与主表的某些特征

＆＃34;事务＆＃34;和＃34;主人＆＃34;表通常具有多对一关系，这意味着许多事务与一个主记录匹配。许多购买记录与同一玩具记录相匹配。虽然＆＃34;掌握＆＃34; FK是这种关系的死亡赠品。桌子也有FK＆＃39;

＆＃34;事务＆＃34;表通常有一个日期或某种事件ID，并且经常被聚合在一起＃39;报告时这可以是记录计数或金额的总和。

现实世界系统的一些特征

完全有可能是有人忘记穿上FK或PK，或者可能是因为有一个独特的钥匙（不是PK）强制执行您所希望看到的内容。

我已经看过密钥显然不正确的实时系统，或根本没有密钥。

Answer 2

Master - - - - - - - - - - - - - - - - - - - - - - Transaction

Country .... Employeee ...... Customer ........... Order

Master＆amp;查找表存在于范围中，而不是二进制开/关状态，并反映了表将经历的活动量的期望

查询/参考表，如州，货币，国家等。轻微有新记录或更改 - 非常“主”

员工偶尔会添加或更改记录，但不会经常（希望）更多“主人”而不是“交易”

客户比员工更频繁地添加或更改记录（也有希望），所以仍然是“主”的衡量标准，但也有“交易”质量

订单会一直添加和更改（希望如此）并且非常“交易”， 与Reciepts相同

如果一张表没有FK字段，那么很可能是“Master”

带有FK的表格对他们有一定数量的“交易”，你对新记录的期望越多 - 表格的“交易”就越多。

键：

在我看来，每张桌子都应该有代理PK，与FK或任何自然键无关。这个观点有很多原因，但是对你有用的东西也很酷。

通常，如果有明显的自然键，那么除了PK之外，表还需要该键的唯一约束