考虑一个允许客户使用可变支付系统的购物车。
每个系统都有一组不同的参数：系统 A 有参考 id、xml 响应、交易 id 等属性，系统 B 有交易 id 和状态，系统 C（支票）只有付款日期。每个系统的状态也不同。
在支付系统选择页面上有支付系统的名称和描述，它们也将存储在数据库中（例如，不硬编码为 HTML）。
您将如何设计数据库？
我能想到的最好的事情是每个系统都有一个表 + 一个链接到相关表名称的支付系统描述表 + 订单表中的 2 个额外字段：支付系统 ID（将链接到“描述table")，支付记录 id（将链接到相关支付系统表中的 id）。这也将允许提供特定功能（订单通知处理等）以在支付系统模型之间分离，而不是使用ifs。可以吗？
如果有的话，该项目基于 PHP 5、Doctrine 和 MySQL。
【问题讨论】：
标签： database-design rdbms
可以说，您可以有一个包含任何常见信息（id、名称等）的主 System 表，然后是第二个表，用于收集属性的名称/值对：
CREATE TABLE system_table
(id int,
name char(50),
...
);
CREATE TABLE system_properties
(system_id int,
name char(50),
value varchar
);
由于属性的模糊映射，这可能对人们没有吸引力，但另一方面，获取任何系统的属性变成了简单的连接，而不是试图将几个表拉到一起。
请注意，上面的 SQL 创建语句是伪代码。
【讨论】：
支付系统的每个类型都有一个表 - 类型是一个或多个支付系统共有的一组独特属性。拥有所有这些类型的父表，其中包含所有这些类型的共享属性（例如系统名称）。
【讨论】：
dportas 和 jaydel 所说的话加上我的两分钱。
每个支付系统都应该在表格的一行中，而不是在自己的表格中。每种类型的支付系统（专业支付系统）都需要一个自己的表来存储仅为该类型收集的数据。
此外，还应该有一个通用的支付系统表，其中包含与所有类型的支付系统相关的数据。
通用支付系统表和专用支付系统表之间的关系是经典的“gen=spec 设计模式”。如果您查找“泛化专业化关系建模”，您会发现教您如何为 gen-spec 模式设计关系表的文章。
简短的回答是 gen 表有一个经典的 ID 字段作为 PK。每个专用表都有一个 ID 字段，该字段与 gen 表中的 ID 字段重复。这意味着它既是专业领域的PK，又是引用gen表的FK。
对数据库中其他地方的支付系统的 FK 引用应该引用 gen 表。
【讨论】：