我们正在开设机票预订平台，用户可在此选择门票数量，填写与会者表格并进行付款。在数据库级别，我们存储表中单个事务的事务条目和不同表中的多个参与者条目。因此，事务表和与会者表之间存在one to many关系。
交易表：
txnId | order id | buyer name | buyer email | amount | txn_status | attendee json | ....
参加者表：
attendeeId | order id | attendee name | attende email | ......
现在你可能会想“为什么我在交易表中有参与者json？”。答案是，当用户启动交易时，我们将参与者数据存储在json中，并将交易标记为INITIATED。成功交易后，同一交易将被标记为SUCCESS，与会者json将被保存在Attendee表中。另外，我们使用此json数据向仪表板上的组织者显示与会者，这样我们就可以在参与者表中保存数据库。与会者json无法查询，这就是为什么我们有参加者表来解雇所需的查询。
问题：现在由于某种原因，我们正在考虑合并这些表并删除json列。假设如果为4位与会者启动了一项交易，我们正在考虑创建四个交易条目。我们有算法在仪表板上将这些条目显示为单个条目。如果我采用这种方法，它将如何影响性能？你的建议是什么？
现在表格如下所示：
txnId | order id | buyer name | buyer email | amount | txn_status | attendee name | attendee email ....
1 | 123 | abc | abc@abc.com | 100 | SUCCESS | xyz | xyz@xyz.com....
2 | 123 | abc | abc@abc.com | 100 | SUCCESS | pqr | pqr@pqr.com....
答案 0 :(得分：2)
Normalization尝试组织数据库以最大限度地减少冗余。您正在使用的技术称为denormalization，它用于通过添加冗余数据来尝试和优化读取表以避免连接。当非规范化是合适的时候，这是激烈的争论。
在您的情况下，只要您的外键被编入索引，就不会有两个表和一个简单连接的性能问题。
我甚至会说你应该删除attendee json列，因为它是多余的，可能会导致错误导致同步失败。与会者表将需要UPDATE，INSERT和DELETE触发器以使其保持最新，从而减慢写入表的速度。 Many databases have built in JSON functions可以非常快速地创建JSON。 至少将缓存的JSON移动到与会者表。
此外，在与会者和txn表中都有order id，表示另一个数据冗余。 buyer name和buyer email建议也应将其拆分为另一个表，避免使用太多信息来填充txn表。
除非您拥有可靠的数据，否则经验法则是为了规范化。使用EXPLAIN指示使用索引。然后，只根据需要进行非规范化，以使数据库按需运行。即使这样，也可以考虑在应用程序端放置一个缓存。
您现在可能能够廉价地从数据库中剔除一些性能，但是您正在抵押您的未来。如果要添加与参加者信息有关的功能而与事务无关，会发生什么？设想自己向新开发者解释这个......
您也可以从交易表中获取参与者信息......买家信息。但是单个与会者可能是多个交易的一部分，因此您需要使用DISTINCT或GROUP BY ...这将减慢所有事情。另外，他们可能会有略微不同的信息，所以你必须使用在这里插入复杂的混乱来计算全部...这会减慢一切。为什么会这样？优化，当然！欢迎来到公司！