如何更好的设计数据表？

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

数据量不大的时候可以考虑只保存关联字段数据量大的话可以考虑数据适当冗余，就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即可。对业务丝毫无影响，也不会产生垃圾数据。