如何识别事务表？答案

【问题标题】：How to identify a transaction table?如何识别事务表？
【发布时间】：2015-12-18 03:40:01
【问题描述】：

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

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

更新这是我的数据库的一个例子

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 表？

【问题讨论】：

一般来说，事务表中有一个日期，通常是一个数值。它通常包含一个或多个主表的外键。 PK 应该定义表的唯一性，该表可能是也可能不是主表的唯一组合。通常不会，尤其是在涉及日期的情况下。
@Nick.McDermaid 可以给我举个例子吗？
“交易”一词非常宽松。但我可以试一试
@Nick.McDermaid 如果我能看到一个样本，那就太好了，因为我拥有的数据库没有一致性......
我已经发布了一些信息，但如果您更详细地描述一些表格会有所帮助。

标签： sql-server database sql-server-2008 sql-server-2008-r2

【解决方案1】：

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

当某件事“发生”时，它就会进入交易。有人在商店买玩具。创建一行记录它是一个玩具，它发生的日期时间和成本。

十分钟后别人买了一个玩具

我们的事务表中有两条记录：

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 将是一个有效的数据模型。

“事务表与主表”的一些特征

“事务”表和“主”表通常具有多对一关系，这意味着许多事务匹配一个主记录。许多购买记录与同一个玩具记录相匹配。尽管“主”表也有 FK

“事务”表通常具有日期或某种事件 ID，并且在报告时通常是“汇总”的。这可以是记录数或金额的总和。

现实世界系统的一些特征

很可能有人忘记使用 FK 或 PK，或者可能是有一个唯一的密钥（不是 PK）来执行您期望看到的内容。

我见过密钥明显不正确或根本没有密钥的实时系统。

【讨论】：

我已经用我的数据库中的两个表示例更新了我的原始帖子！
你能不能也看看这个链接，因为我已经把这个贴在 C# 角落c-sharpcorner.com/forums/thread/330184/…
我完全不同意该网站上的评论。 EMP不是事务表。它确实像事务表一样具有多对一关系，但它没有诸如事务日期或事件日期或 ID 之类的“时间”组件。它不记录交易（随着时间的推移发生的事件）。这是一个主表。
我对定义事务表的混淆就像您所说的带有日期时间列的一样，但在我的数据库中，所谓的主表和事务表的标记与 c-sharp 角上发布的内容完全相同。 .. 可能是用于像 Emp 表这样的表的错误命名约定
也许您可以发布混乱表的 DDL。

【解决方案2】：

Master - - - - - - - - - - - - - - - - - - - - - 交易

国家 .... 员工 ...... 客户 ...... 订单

主表和查找表存在于范围内，而不是二进制开/关状态，并反映了对表将经历的活动量的预期

查找/参考表，如州、货币、国家等。很少有新记录或更改——非常“大师”

员工偶尔会添加或更改记录，但不会经常（希望）如此“大师”而不是“交易”

客户比员工更频繁地添加或更改记录（也希望如此），因此仍然是衡量“大师”但也具有“交易”品质的衡量标准

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

如果一个表没有 FK 字段，它可能非常“大师”

具有 FK 的表对它们有一定数量的“事务”，您期望的新记录越多 - 表的“事务”就越多。

键：

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

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

【讨论】：