数据库设计问题

Question

我正在尝试为产品聚合器设计数据库。每个产品都有关于它来自哪里，它的成本，它是什么类型，价格，颜色等的信息。用户需要能够根据这些产品类别中的任何一个来搜索和过滤结果。我也期望拥有大量用户。我最初的想法是有一个包含每个产品的大表，每个信息的列都有一个我需要能够搜索的任何内容的索引，但我认为这可能是效率低下的，很多用户都会对这个产品感兴趣表。我的另一个想法是组织数据库以促进表格的树状导航，但因为你可以搜索任何东西，我不知道如何组织表格。

对某些良好做法的想法？

Answer 1

一个产品表 - 数据库旨在让很多用户在桌面上敲击。

（来自评论）

您需要为数据建模。这来自于查看您拥有的所有数据，确定与什么相关的内容（表称为关系，因为行中的所有属性都与候选键相关）。您还没有真正提供有关这些产品的数据范围（非结构化？）及其变化方式的足够信息。您是否会遇到困难，因为鞋子有品牌，型号，尺寸和颜色，但书桌只有品牌，型号和表面处理？所有这些都将通知您的数据模型。通常，您有一个产品表，其他东西链接到它。

其中一些属性将是查找表的外键，其他（价格）将是简单的标量。适当的索引，你会没事的。对于高级分析，请考虑维度建模的星型模式，但可能不适用于您的实时事务系统 - 取决于您的数据流/工作流/事务。或者在交易数据库中考虑其原则的一些好处。 Ralph Kimball是关于维度建模的良好信息的来源。

Answer 2

我认为这里不需要树形结构。你可以用单桌做。

如果您坚持使用层次结构的树结构，那么example就可以帮助您入门。

Answer 3

用于基于文本的搜索，以及易于启动和设计方面，我强烈推荐Apache SOLR。 SOLR API易于使用（尤其是JSON）。数据库的文本搜索效果不佳，我建议您只是确保它们正确响应主要/唯一密钥查询，这些是您应该索引的字段。

Answer 4

产品的一个表格和产品类别层次结构的另一个表格（你没有具体说明你有这个但是“表格的树状导航”让我觉得你可能会这样做。）

如果您计划对几乎每列进行索引，我可以看到您可能会担心过度索引会导致问题。在这种情况下，最好在您认为用户可能搜索的前5或10列上进行索引，除非用户可以搜索任何列。在这种情况下，您可能希望了解如何构建数据仓库。也许你会想要查看数据立方体，看看它们是否有帮助......？

---

对于分层数据，您需要一个PRODUCT_CATEGORY表，如下所示：

ID
PARENT_ID
NAME

一些示例数据：

ID     PARENT_ID     NAME
1                    ROOT
2      1             SOCKS
3      1             HELICOPTER PARTS
4      2             ARGYLE

某些SQL引擎（例如Oracle）允许您编写递归查询以在单个查询中遍历层次结构。在此示例中，树的根具有PARENT_ID NULL，但如果您不希望此列可以为空，我还会看到-1用于此列目的。