在大型但有限的表组中优化JOIN的架构

如何解决在大型但有限的表组中优化JOIN的架构

|| 我在这里有一定的灵活性，因此在锁定之前，我正在寻求一些建议。我也有几种方法可以解决此问题，但我正在寻找有关最有效方法的建议。由于我的数据类型的细节有些晦涩，因此我将使用更易于理解的对象隐喻。 现在，我有两个主表，以及大量但数量有限的附加表。以下业务逻辑适用。 每个特定的动物表都有一个分配给它的唯一文件，例如猪的“鼻子直径”或猫的“晶须”。还有另一个领域 动物表具有标记动物“角色”的字段。 关在笼子里的可能有多只动物。 通过FK约束将动物链接到笼子。通过FK约束将特定的动物表链接到动物表。 笼子 动物 猫 狗 猪等 被问到的主要问题是，笼子里有什么？我还需要能够尽快搜索所有笼子，并获得属于“美味”角色的动物的所有信息。有时候，猪会“好吃”，有时它可能是猫。根据“美味”动物的类型，我需要显示其特定信息。 什么是查找此信息的最有效的架构设计或SQL语句？ 我第一次尝试使用Only Cages，然后是一堆\“ SpecificAnimal \”表。这似乎是一个坏主意，因为我必须跨10个以上的表进行联接才能弄清楚笼中的内容。 然后，我将常用属性移到动物表中，这使我可以轻松地查看笼子里有哪些动物，尽管这仍然需要在特定表中进行搜索以获取所有数据。 我打算将特定的属性存储到某种形式的CSV字符串中（但我还没有那么急切） 我当然可以进行EAV，但是由于动物的数量确实有限，所以这似乎效率很低。 我要担心吗？我应该只是硬着头皮接受10张桌子的Joins吗？只是担心性能。...可以推荐的任何想法或设计模式。遭受信息超载和感冒的困扰。请帮助。     

解决方法

        很难回答“什么是最佳方案”问题，因为它们总是涉及折衷。这部分意味着要准确地权衡一种设计与另一种设计之间的关系，您必须进行测量（例如速度测量），以根据您的决定。 （这可能不是您要找的答案）。 就其价值而言，十个联接并不是一个庞大的数目，根据系统中动物和笼子的数量，您可能永远不会注意到速度问题。此外，如果确实存在一个“主查询”，则可以使用实例化视图至少使该查询快速回答。 最后，给出一些总体建议：选择一个干净的数据模型，直到您有大量数字来指示您对设计“糊涂”为止。