帮助超类型/子类型？（和类别..）答案

【问题标题】：Help with Supertype/Subtype? (and categories..)帮助超类型/子类型？（和类别..）
【发布时间】：2009-10-13 22:45:32
【问题描述】：

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

例如，

服务 = 乔的网络公司， MainCategory = 信息技术，子类别 = 网络开发

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

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

所以在我上面的例子中，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 解决方案是否更适合？

【问题讨论】：

标签： php mysql database entity-attribute-value

【解决方案1】：

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

【讨论】：

感谢friendfeed的链接，这是一篇非常有趣且内容丰富的文章。考虑到成本、维护、我的技能等，我认为面向文档的 dbms 解决方案的开发和维护可能有点棘手，并且客户没有足够的时间/金钱来投资类似这样的解决方案。我相信这是这个问题的正确答案。

【解决方案2】：

我认为document-oriented dbms 是一个很好的建议，请参阅CouchDB/PHP 或MongoDb/PHP。我可能更喜欢图形数据库，其中RDF 浮现在脑海中。我在 PHP 中找到了两个实现，我自己没有尝试过：Easy RDF 和 RAP。

【讨论】：

感谢您的链接。我简要地浏览了它们，现在将适当地研究它们。我很想能够使用 RDF 方法，我会看看它是多么容易学习/实现。

【解决方案3】：

第二个问题..

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

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

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

ps：当我获得足够的学分时，将为您的答案投票！需要两个大声笑

【讨论】：