这个数据库设计有什么问题？
有人指出，下面的数据库设计存在严重的问题，有人能告诉我为什么吗？
information
- tb_user表只保存3-8个用户。
- 每个用户的数据将保存在一个单独的表中，并以用户名命名。假设一个用户被调用: bill_admin，那么他有一个独立的表，即bill_admin_data，以保存属于他的所有数据。所有用户的数据共享相同的结构。
指出这个问题的人说，我应该将所有数据合并到一个表中，并使用FK来区分它们，但我有以下声明：
- 用户将只有3-8个，所以无论如何也不会有很多表。
- 每个用户都有一个非常大的数据表，比如500 K记录。
像这样设计数据库是一种不好的做法吗？为什么？谢谢。
回答 3
Stack Overflow用户
发布于 2012-05-29 04:51:27
因为它不是很容易维护。
1)向数据库添加数据不需要修改结构。在您的模型中，如果您需要添加另一个人，您将需要一个新的表(或两个)。你也许不认为你会需要这样做，但相信我。你会的。
因此，假设，例如，要向应用程序添加功能，以便向数据库添加新用户。使用这种结构，您将必须授予最终用户创建新表的权限，这会造成安全问题。
2)违反了DRY principle。也就是说，您正在创建相同表结构的多个副本。这使保养很痛苦。
3)跨多个用户查询将不必要地复杂。没有充分的理由将每个用户分成一个单独的表，除了对必须针对这个DB模型编写查询的人进行报复之外。
4)如果由于每个用户都有很多行，所以要将其分割成多个表以提高性能，则需要重新创建车轮。您使用的RDBMS无疑具有索引功能，它允许高效地查询大型表。在处理大数据方面，您的本土黑客不会超过平台的方法。
Stack Overflow用户
发布于 2012-05-29 04:54:10
我不认为这本身就是糟糕的设计。它并不是关系数据库设计和优化所针对的设计类型。
当然，您可以像前面提到的那样存储数据，但是许多操作并不简单。例如：
person
- Removing
- 添加了一个新的a person
- Generating报告，该报告基于所有人员的
的数据
如果你真的不关心这个的话。尽管我建议使用非关系数据库(如MongoDB )，但它更适合这种类型的结构。
如果您更喜欢使用关系数据库，则通过按类型而不是按人员聚合数据，可以在添加新人员和计算报表时提供很大的灵活性。
500 K线不是“非常大”，所以在设计时不要担心尺寸。
Stack Overflow用户
发布于 2012-05-29 04:53:46
将基于文档的数据库(如mongoDB )用于这些类型的需求是很好的。
https://stackoverflow.com/questions/10793184
复制相似问题
腾讯云开发者
