我有一张服务台。每个服务由1个主要类别和1个子类别定义。
例如，
服务= Joe的网络公司， MainCategory =信息技术， SubCategory =网站开发
所提供的每项服务都有一套共同的属性（成本，地点等）
每个服务还将具有一组特定于SubCategory的属性。
因此，在上面的示例中，Joe的Web公司可能具有以下属性：PHP（BOOL）：1，MySql（BOOL）：0，Javasctipt（BOOL）：1等
或者对于演员，他们可能具有以下属性：EyeColour（ENUM）：蓝色，高度（浮动）：5.11
所以，我认为超类型/子类型关系最有效，但我们可以说超过500个表。
我还需要能够在主要类别中搜索服务。为此，我考虑在主服务表中创建一个关键字列，这样我就不需要查找每个子类型的表（某些类别可能有50个子类型/表）。我每晚都会运行一个脚本来填充这个列，文本解释每个服务的子类型的属性（例如，对于Joe，他的关键字列将包含'PHP Javascript'）。
考虑到桌子的数量，这种方法看起来不错还是EAV解决方案更合适？
答案 0 :(得分：0)
我不认为创建500多个表是一种方法。在我看来，你的结构是“无模式”而不是纯粹的关系。我会考虑使用专用的面向文档的dbms（Mongodb，Tokyo Cabinet）或自己推出，使用mysql作为低级数据存储（在这里http://bret.appspot.com/entry/how-friendfeed-uses-mysql看一个很好的例子）。
答案 1 :(得分：0)
我认为document-oriented dbms是一个很好的建议，请参阅CouchDB/PHP或MongoDb / PHP。我可能更喜欢图形数据库，其中会出现RDF。我在PHP中找到了两个实现，没有自己尝试过：Easy RDF和RAP。
答案 2 :(得分：0)
第二个问题..
如果面向文档的dbms解决方案太难以开发/维护，那么它如何寻找替代解决方案？
在子类别上使用属性bundle使我的设计模式更少。如果我将属性包移动到主类别级别该怎么办？无论如何，每个子类别中的许多属性将与其他子类别共享。这样做的缺点是一个完全独特的子类别会将它的属性强加给主猫的每个其他子类别，但是我们可以限制这些属性在唯一子类别上的使用。我可以使用应用程序逻辑来确定子类别可以使用的attrbites等。
基本上这种替代方法将使用传统的关系超类型/子类型模型，但是我会有相当广泛的子类型。
ps：当我获得足够的学分时，会投票给你答案！还需要两个lol