Php 数据库中的200个表是否太多？

很明显，如果没有更多的信息，这个问题是不可能回答的，所以让我进一步说明

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

它们分为13大类产品

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

这4个或5个（总共约65个）各自有4个或5个

我所做的是为每一位单亲家长及其直系子女制作一张桌子。然后为每个孩子和他们的孩子准备桌子

就逻辑而言，它将满足我的编程需求，但我想知道拥有这么多表是否完全是非正统的，是否有更好的方法来实现这一点

还想知道在查询时是否有那么多表会使系统过载/滞后

---

我可以在两个表中完成整个工作，我只是为每个类别分配了一个父id，但从视觉角度看，这看起来不是很有组织或层次，而这就像一棵完美的树。

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

此外，编写糟糕的代码将导致数据库性能不佳

---

除此之外，为每个页面制作一些小的计时脚本。确定每个查询所需的时间，然后将其乘以您预期的用户数。如果您希望每秒有400个查询，那么如何编写代码以及使用谁来承载基础结构等问题将非常重要。

使用具有适当索引的关系数据库结构（具有一对多或多对多关系）。为每个类别提供单独的表在逻辑上没有任何意义——这就是关系数据库被发明的原因

您的解决方案应该是可行的，但从数据的角度来看，这不是很好的实践

以获得更具体的信息

数据库结构，如

TABLE categories:
id  title   parent_id(NULL)

---

然后使用PHP中的一些递归对由此得到的结果进行排序。

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

一些注意事项：

在多表场景中，随着产品/类别等的增长，您将需要不断添加越来越多的表，但这将使查找速度更快（完整表扫描较少的记录），查询更干净，关系更健全

在两个表的场景中，通常是通过自连接来获取数据，查找可能会变慢，因为所有数据都将驻留在这几个表中。同样从个人经验来看，在同一个表中有如此多的代码和关系，特别是当它成为n级亲子关系时，维护它们是一件痛苦的事情。Oracle在这种情况下有关系解析SQL语法，这使得查询更容易。但我认为MySQL缺少它们

---

如果我是你的话，我会选择第一种结构。也许会平复一些孩子和父母的关系，但大多数情况下会保持它们的原子性。（顺便说一句，我曾经使用过400多个表的（遗留）MySQL数据库，因此我认为您应该可以使用200多个表）

200个表对于您描述的问题来说太过分了。您可以在一个表中存储关于存储的数据，在另一个表中存储关于类别的数据，在第三个表中存储关于子类别的数据，最后在第四个表中存储关于子类别的表。然后，您可以将属于给定存储和给定子类别的数据存储在第五个表中

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

它简单得多，性能更好，而且更适合未来。您可以在不改变数据库结构的情况下添加新存储。不仅如此，在构建数据库后，还可以对数据执行各种查询

以各种方式利用相同的数据才是数据库真正的意义所在。根据您的结构，每当您想以新的方式利用数据时，您都必须编写一个新程序。对于经典设计，您只需用SQL编写查询

---

顺便说一下，我见过一个数据库，其中大约有400个表。但该数据库管理着一所中型大学的所有行政数据。从学生、课程、报名、成绩到校友捐款、高中成绩单、体育赛事和停车场，应有尽有。你的问题远没有这么复杂

对于您的问题，表面上的答案是否定的，一个数据库中有200个表没有什么错。但是，正如下面的答案所示，通常不应该创建多个表来存储相同类型的信息。另一方面，如果每种存储类型需要表中的不同信息，那么为每种类型提供一个表可能是一种方法。如果表的数量合理，数据库中的200个表也不错。有200列的表通常意味着数据库设计很差。