这个数据库设计有什么问题？

Question

我被其他人指出，以下数据库设计存在严重问题，有谁可以告诉我为什么？

1. tb_user表保存所有用户信息
2. tb_user表只有3到8个用户。
3. 每个用户的数据将保存在一个单独的表中，以用户名命名。 假设用户被叫：bill_admin，那么他有一个单独的表，即bill_admin_data，以保存属于他的所有数据。所有用户的数据共享相同的结构。

指出这个问题的人说我应该将所有数据合并到一个表中，并使用FK来区分它们，但我有以下声明：

1. 用户只会是3-8，所以无论如何都不会有很多桌子。
2. 每个用户都有一个非常大的数据表，比如500K记录。

设计这样的数据库是不好的做法？为什么？谢谢。

Answer 1

因为它不太可维护。

1）向数据库添加数据永远不需要修改结构。在您的模型中，如果您需要添加其他人，则需要一个新表（或两个）。你可能认为你不需要这样做，但请相信我。你会。

因此，假设您要为应用程序添加功能以将新用户添加到数据库。使用此结构，您必须为最终用户提供创建新表的权限，这会产生安全问题。

2）它违反了DRY principle。也就是说，您正在创建相同表结构的多个副本。这使维护成为一种痛苦。

3）查询多个用户将不必要地复杂化。没有充分的理由将每个用户分成一个单独的表，除了对必须针对该数据库模型编写查询的人进行仇杀。

4）如果你将它分成多个表以提高性能，因为每个用户都有很多行，你就是在重新发明轮子。您正在使用的RDBMS无疑具有索引功能，允许它有效地查询大型表。你的本土黑客不会胜过平台处理大数据的方法。

Answer 2

我不会说这本身就是糟糕的设计。它不是为其设计和优化关系数据库的设计类型。

当然，您可以按照提及的方式存储数据，但许多操作并不简单。例如：

• 添加新人
• 删除某人
• 根据所有人的数据生成报告

如果你真的不在乎这样做。继续按照你的建议做你的表，虽然我建议使用非关系型数据库，比如MongoDB，它更适合这种类型的结构。

如果您更喜欢使用关系数据库，则按类型聚合数据，而不是按人员聚合，这样可以在添加新人和计算报告时提供很大的灵活性。

500k线不是“非常大”，所以在制作设计时不要担心尺寸。

Answer 3

最好使用像mongoDB这样的基于文档的数据库来满足这些类型的要求。