Mysql 合并两个数据库表好吗？

我们正在售票平台上工作，在这个平台上，用户可以选择票数，填写与会者表格并付款。在数据库级别，我们在一个表中存储单个事务的事务条目，在不同的表中存储多个与会者条目。因此，事务表和与会者表之间存在一对多关系

交易表：

txnId | order id | buyer name | buyer email | amount | txn_status | attendee json | ....

attendeeId | order id | attendee name | attende email | ......

 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....

与会者表：

txnId | order id | buyer name | buyer email | amount | txn_status | attendee json | ....

attendeeId | order id | attendee name | attende email | ......

 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....

现在您可能会想“为什么在事务表中有attendee json？”。答案是，当用户启动事务时，我们将与会者数据存储在json中，并将事务标记为已启动。交易成功后，同一交易将被标记为成功，并且attendee json将保存在attendee表中。另外，我们使用这个json数据向仪表板上的组织者显示与会者数据，这样我们就在与会者表上保存了一个数据库点击。而且attendee json是不可查询的，这就是为什么我们有attendee表来触发所需的查询

问题：出于某种原因，我们现在考虑合并这些表并删除json列。假设一个交易是为4个参与者发起的，我们考虑创建4个交易条目。我们有算法将这些条目显示为仪表板上的单个条目。如果我采用这种方法，将如何影响性能？你有什么建议

现在表将如下所示：

txnId | order id | buyer name | buyer email | amount | txn_status | attendee json | ....

attendeeId | order id | attendee name | attende email | ......

 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....

尝试组织数据库以最小化冗余。您正在使用的技术被调用，它用于通过添加冗余数据来避免连接，从而尝试优化读取表。什么时候去规范化是合适的，这是一个激烈的争论

在您的情况下，只要外键被索引，拥有两个表和一个简单联接就不会有性能问题

我甚至想说，您应该删除

attendee json

列，因为它是多余的，并且可能会失去同步，导致bug。attendee表将需要更新、插入和删除触发器，以使其保持最新状态，从而减缓对表的写入。它可以非常快速地创建JSON。至少将缓存的JSON移动到attendee表

此外，在attendee和txn表中都有

订单id

，提示另一个数据冗余<代码>买方名称和

买方电子邮件

建议也应将其拆分为另一个表，避免在txn表中添加太多信息

经验法则是朝着标准化方向努力，除非您有可靠的数据。使用EXPLAIN指示的索引。然后，仅根据需要进行反规范化，以使数据库按需运行。即使这样，也可以考虑在应用程序端设置缓存。 现在，您可能可以廉价地从数据库中挤出一些性能，但您正在抵押您的未来。如果要添加与与会者信息有关而与交易无关的功能，会发生什么情况？设想你自己向一个新的开发人员解释这一点

您可以从事务表中获取与会者信息。。。还有买家信息。但单个与会者可能是多个交易的一部分，因此您需要使用DISTINCT或GROUP BY。。。这会让一切变慢。而且他们可能有稍微不同的信息，所以你必须在这里使用insert-complex-mess来解决所有问题。。。这会让一切变慢。为什么是这样？当然是优化！欢迎光临本公司

---

谢谢你的回复。