1

我有一张服务台。每个服务由 1 个主要类别和 1 个子类别定义。

例如，

服务 = Joe's Web Company，MainCategory = 信息技术，SubCategory = Web Development

提供的每项服务都有一组共同的属性（成本、位置等）

每个服务还将具有一组特定于 SubCategory 的属性。

因此，在我上面的示例中，Joe's Web Company 可能具有以下属性：PHP(BOOL):1、MySql(BOOL):0、Javasctipt(BOOL):1 等

或者对于演员来说，它们可能具有以下属性： EyeColour(ENUM): Blue, Height(float): 5.11

所以，我认为超类型/子类型关系效果最好，但是我们可以谈论超过 500 个表。

我还需要能够跨主要类别搜索服务。为此，我正在考虑在主服务表中创建一个关键字列，因此我不需要查找每个子类型的表（某些类别可能有 50 个子类型/表）。我每晚都会运行一个脚本，用解释每个服务子类型属性的文本填充此列（例如，对于 Joe，他的关键字列将包含“PHP Javascript”）。

这种方法看起来不错，或者考虑到表格的数量，EAV 解决方案是否更适合？

4

3 回答 3

0

我不认为创建 500 多个表是一种方法。在我看来，您的结构是“无模式”而不是纯粹的关系。我会考虑一个专门的面向文档的 dbms（Mongodb，Tokyo Cabinet）或者推出你自己的，使用 mysql 作为低级数据存储（看这里http://bret.appspot.com/entry/how-friendfeed-uses- mysql是一个很好的例子）。

于 2009-10-13T23:30:21.770 回答
0

我认为面向文档的 dbms是一个很好的建议，请参阅CouchDB/PHP或MongoDb / PHP。我可能更喜欢图形数据库，我会想到RDF 。我在 PHP 中找到了两个实现，但我自己没有尝试过：Easy RDF和RAP。

于 2009-10-14T09:41:06.877 回答
0

第二个问题..

如果面向文档的 dbms 解决方案被证明太棘手而无法开发/维护，那么如何寻找替代解决方案？

在子类别上拥有属性包使我的设计模式更少。如果我将属性包移到主类别级别会怎样。无论如何，每个子类别中的许多属性都将与其他子类别共享。这样做的缺点是一个完全独特的子类别会将其属性强加于主猫中的每个其他子类别，但是我们可以限制在唯一子类别上使用这些属性。我可以使用应用程序逻辑来确定子类别可以使用的属性等。

基本上，这种替代方法将使用传统的关系超类型/子类型模型，但是我会有相当广泛的子类型。

ps：当我获得足够的学分时会投票给你的答案！还需要两个大声笑

于 2009-10-14T11:03:10.423 回答