mysql - 数据库设计 - 多对多或一对多 "Deal"系统？

Question

我有一个系统，用户可以互相“交易”，我想知道我应该使用什么样的关系。 像这样思考这个系统。 我们有一个数据库，有两个表，一个“用户”表和一个“交易”表 “交易”表中的每一行都与两个“用户”行相关。 因此，当创建交易时，一个用户是买方，一个用户是卖方。 我应该如何设计这个数据库？ 我的意思是表格的逻辑应该是什么？ 一对一还是多对多？为什么？

/image/so7iS.jpg

Answer 1

嗯，有点像 1:many 和many:many。

CREATE TABLE Deals (
    seller_id SMALLINT UNSIGNED NOT NULL,  -- link to `Users`
    buyer_id  SMALLINT UNSIGNED NOT NULL,  -- link to `Users`
    object_id SMALLINT UNSIGNED NOT NULL,  -- link to `Objects`
    price DECIMAL(8,2) NOT NULL,
    etc.,
    PRIMARY KEY(seller_id, buyer_id, object_id),
    INDEX(...)
) ENGINE=InnoDB;

这允许两个“用户”之间进行多个对象销售，同一对象以其他价格在其他人之间出售，等等。

“交易”是一个实体，只是“用户”是一个实体。但是，由于一笔交易只涉及一个买方、卖方和一个对象，因此 deal:person 和 deal:object 之间的关系是 1:多。

另一方面，Deals 的作用就像一个多对多关系表，将卖家和买家、卖家和对象等联系起来。

有关架构的一些详细信息:

• 您可能希望将 seller_id 和 buyer_id 链接到单个 Users 表。 (除非买家和卖家之间存在足够的差异来证明不同模式的合理性。)
• 我提议的架构中的 3 个 id 代表 jpg 中的彩色线条。也就是说，您几乎完成了架构!
• SMALLINT UNSIGNED(仅 2 个字节)允许 64K id。如果您认为这还不够，请选择更大的数据类型。
• DECIMAL(8,2) 允许最高 999999.99 美元、欧元等的价格；如果这不符合您的货币需求，请进行更改。
• 交易中不需要AUTO_INCRMENT PRIMARY KEY。
• 根据需要添加更多 INDEX。

(已添加...)

如果相同卖家/买家对可以出售/购买相同 object_id，则 PK(上述)将不起作用。 (注意:PK 必然是“唯一的”。)要解决此问题，您需要具有

deal_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
PRIMARY KEY(deal_id),
INDEX(seller_id, buyer_id, object_id),  -- in some order
INDEX(...)

在设计一组表格时，我喜欢关注需要收集在一起的内容(例如，“交易”的属性)。并确保关系得到处理(例如，seller_id)。通常情况下，事物会分为“实体”(交易、用户)和“关系”(ID，当 1:多时；当多:多时，一个单独的映射表)。在您的例子中，多对多关系表本身就是一个实体。

我还喜欢勾勒出SELECT，以查看表是否方便地支持查询。

只有到了最后，我才会考虑FOREIGN KEY。一般来说，INDEX 映射到 FK。

我很少使用 FK 或触发器 - 我希望应用代码能够阐明任何事务的所有步骤，包括否则会隐藏在 FK 和触发器中的副作用。