数据库中有200个表太多了吗？

Question

显然，如果没有更多信息，这个问题就无法回答，所以让我扩展一下。

我正在建立一个拥有约1000家商店的商店数据库

它们分为13大类产品。

这13个主要类别每个都有大约4或5个子类别

那些4或5（总共约65个）各有约4或5个。

我所做的就是为每一位父母及其直接子女制作一张桌子。然后为每个孩子及其子女提供表格。

在逻辑方面，它将满足我的编程需求，但我想知道如果有这么多表并且有更好的方法可以完全非正统。

还想知道在查询时是否会有多个表超载/滞后系统。

我本可以在2个表中完成整个过程，我只为每个类别分配了一个parent_id，但是从一个看起来非常有组织或层次的视觉角度来看，这就像一棵完美的树。

Answer 1

使用关系数据库结构（具有一对多或多对多关系）和正确的索引。每个类别都有一个单独的表在逻辑上没有任何意义 - 这就是发明关系数据库的原因。

您的解决方案应该有效，但从数据的角度来看，这不是很好的做法。

获得更多specefique

像

这样的数据库结构

TABLE categories:
id  title   parent_id(NULL)

然后使用PHP中的一些递归对您从中获得的结果进行排序。

Answer 2

如果所有表都具有相同的字段或大多数相同的字段，并且它们代表相同的东西（即产品），那么仅使用两个表的解决方案是设计此数据库的更标准方法。一个表列出了所有产品及其所属的类别（最具体的类别），另一个表列出了类别。有关处理此表中显示的分层信息的不同方法的讨论，请参阅this question。 nested set model也可能符合您的需求。 （这个问题没有讨论，因为它不能满足提出问题的人的需求。）根据你选择的模型，你可能需要添加第三个表来实现模型。

Answer 3

对于您描述的问题，200个表格过于苛刻。您可以在一个表中存储有关商店的数据，在另一个表中存储有关类别的数据，在第三个表中存储有关子类别的数据，最后在第四个表中存储有关子子类别的表。然后，您可以在第五个表中存储与给定商店和给定子类别相关的数据。

您可以使用外键/主键引用定义将这些表中的行绑定到其他表中的行，并使用join根据需要组合数据。

它更简单，性能更好，并且更具前瞻性。您可以在不更改数据库结构的情况下添加新存储。不仅如此，您还可以在构建数据库后对数据进行各种查询。

以各种方式利用相同的数据实际上是数据库的全部内容。使用您的结构，每次要以新的方式利用数据时，您都必须编写新程序。使用经典设计，您只需在SQL中编写查询。

顺便说一下，我看到一个数据库里面有400个表格。但该数据库管理了中等规模大学的所有管理数据。从学生，课程，招生，成绩到校友捐赠，高中成绩单，体育赛事和停车位。你的问题几乎不复杂。

Answer 4

这个问题无法回答，因为您没有提供最重要的信息：加载。有多少用户将使用此数据库？同样重要的是，您使用哪家公司来托管基础设施？

此外，编写得不好的代码会导致数据库效果不佳。

除此之外，为每个页面制作一些小的计时脚本。确定每个查询所花费的时间，然后将其乘以您期望拥有的用户数。如果您希望每秒有400个查询，那么诸如编写代码的方式以及用于托管基础结构的用户将非常重要。

Answer 5

一些注意事项：

在多表方案中，随着产品/类别等的增长，您将需要不断添加越来越多的表，但它会使查找速度更快（较少记录的全表扫描）和查询更清晰，关系更清晰。

在双表方案中，它通常是自联接以获取数据，但查找可能会变慢，因为所有数据都将驻留在这几个表中。同样从个人经验来看，在同一张桌子中维持这么多代码和关系是很痛苦的，特别是当它成为n级亲子关系时。 Oracle有这样的情况解析SQL语法的关系，这使得查询更容易。但我认为MySQL缺乏它们..

如果我是你的话，所有事情都会考虑我会选择第一个结构。也许可以压扁一些孩子与父母之间的关系，但大多数都是保持原子性的。 （顺便说一句，我曾与400多个表一起使用过（遗留）MySQL数据库，所以我觉得你应该可以使用200多个表）