如何更好的设计数据表？

Question

问题描述下面是两张数据表：分别为 order,user。表关系 order.user_id 关联 user.id。设计一个场景：在后台管理中，我们需要进行订单搜索，如：根据时间、用户名进行搜索。一：以前的做法是只在 order 表中存入 user.id,通过 order.user_id 表明表关系。然后在程序中进行关联搜索。二：现在的想法如上面的图示：将 user.username 一并存入 order 中。这样做的想法是方便搜索，减少表的关联问题1：两种做法那种好，或者不同优点或缺点。2：在第二种做法中，存在一个问题，如果用户修改了 username。那么 order 中的字段必须相应修改。如何处理更好？我目前的想法是：一个是在用户修改用户名时，去修改相应 order 中的 username。第二种使用触发器(未实践)。谢谢！

Answer 1

1. 数据量不大的时候可以考虑只保存关联字段

2. 数据量大的话可以考虑数据适当冗余，就order而言，其实username改动的频率比较小，呈现有差异的概率比较小，对不影响关键数据把，我认为也可以不用同步，或很长一段时间定时去同步

Answer 2

如果数据量大，访问量大，建议上elasticsearch之类的专业的搜索工具。
如果数据量不大，访问量一般般，你不用elasticsearch，那么只是用mysql。建议遵循范式设计。
如何设计？我认为分为3个表是最好的。

1、订单表
2、用户表
3、订单用户搜索关系表。

其实表3的作用跟elasticsearch作用一样的。3表其实是存储冗余数据，以空间换时间。

如何解决username改动造成的影响，username改动，表3的数据需要进行更新即可。
一个username能对应几个订单，几百个？几千个？几万个？我认为不多。最多几万个。而且username更新频率多大？一天？一个月？
这样想下来，其实username每次改动更新表3不是什么麻烦事。

其实你把冗余数据放到表1也是可以的。但我认为订单就是订单、用户就是用户。保持他们的独立性，日后你扩展就很容易了。

试想一下，假如以后你们公司做大了，老板需要你用elasticsearch来解决搜索的问题，你把冗余数据存储到了表1，等于这部分的冗余数据其实没有用处了。
但如果我把这部分的冗余数据存储到了表3，我大可直接删除表3即可。对业务丝毫无影响，也不会产生垃圾数据。