-1

显然，如果没有更多信息，这个问题是不可能回答的，所以让我展开。

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

它们分为13大类产品。

这 13 个大类各有 4 或 5 个子类

这 4 个或 5 个（总共约 65 个）每个人都有大约 4 个或 5 个。

我所做的是为每个单亲父母及其直系子女制作一张桌子。然后为每个孩子和他们的孩子提供桌子。

在逻辑方面，它将满足我的编程需求，但我想知道拥有这么多表是否完全不正统，以及是否有更好的方法来做到这一点。

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

我本可以在 2 个表中完成整个事情，我只是为每个类别分配了一个 parent_id，但从视觉角度来看，它看起来不是很有条理或层次结构，而这就像一棵完美的树。

4

5 回答 5

4

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

您的解决方案应该可以工作，但从数据意义上讲，这不是很好的做法。

为了更具体

像这样的数据库结构

TABLE categories:
id  title   parent_id(NULL)

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

于 2012-09-27T02:25:20.013 回答
2

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

于 2012-09-27T02:27:01.257 回答
2

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

您可以使用外键/主键引用定义将这些表中的行与其他表中的行联系起来，并根据需要使用连接来组合数据。

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

以各种方式利用相同的数据确实是数据库的全部内容。有了你的结构，每次你想以新的方式利用数据时，你都必须编写一个新程序。使用经典设计，您只需用 SQL 编写查询。

顺便说一句，我见过一个数据库，里面有 400 个表。但该数据库管理着一所中型大学的所有管理数据。从学生、课程、入学和成绩到校友捐赠、高中成绩单、体育赛事和停车位，应有尽有。你的问题几乎没有这么复杂。

于 2012-09-27T12:57:44.250 回答
1

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

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

除此之外，为每个页面制作一些小的计时脚本。确定每个查询需要多长时间，然后将其乘以您希望拥有的用户数。如果您希望每秒有 400 个查询，那么您如何编写代码以及使用谁来托管基础设施等事情很快就会变得非常重要。

于 2012-09-27T02:24:51.427 回答
1

一些考虑：

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

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

如果我是你，所有的事情都考虑到我会采用第一个结构......也许会使一些孩子与父母的关系变平，但主要是让它们保持原子性。（顺便说一句，我使用过（遗留）具有 400 多个表的 MySQL 数据库，所以我认为你应该可以处理 200 多个表）

于 2012-09-27T02:34:29.860 回答