Rails4：复杂的多对多关系
Rails 4: Complex Many to Many Relationships
我有以下型号..
- 提供商
- 患者
- 诊所
就像一个生态系统，所有模型之间都应该有多对多的关系。能够查询各个方向的数据非常重要
在深入研究 Active Record 关联之后，我发现许多博客警告不要 has_and_belongs_to_many 并使用 has_many :through。唯一的问题是需要 table 来充当 "middle-man"，因为没有更好的词，但我不确定这将如何与 3 个模型一起使用。
另一种选择是 polymorphic 关联，但我不确定如果该方法不适用于这种特定情况，我是否应该花时间了解该方法。
关于如何建立这些关系以获得最大的灵活性和效率，有什么建议吗？
I have the following models
表，如果它们是为关系数据库建模的，否则是文件。
It's very important that I am able to query data from all directions.
明白了。这在关系数据库中简单易行。
Like an eco-system, all models should have many-to-many relationships with one another.
这是不正确的。
如果这三个中的每一个都可以与另外两个相关联，那么您的数据就没有建模。有一些您尚未确定的基本依赖项。例如：我可以想象：
提供者在诊所
诊所为患者提供服务
患者到诊所就诊以获得服务
因此，患者与提供者之间的任何关系都是通过诊所，而不是私下，没有诊所。
首先理顺这些规则和依赖关系，这将导致少于三个关联表。像这样：
回复评论
Any advice on how to create these relationships for maximum flexibility and efficiency?
好吧，E F Codd 博士的 关系模型 被牢固地确立为 模型，组织数据的方法，使其具有（a）完全完整性（对象不能）（b）最大灵活性（c）最大速度。在它问世的 45 年里，没有其他竞争者。这就是我正在使用的模型。支撑该模型的原则是我提出建议时所依赖的原则。
当然，在我 34 年的数据库实施过程中，所有这些都得到了确认和加强。以及数以千计的其他 high-end 实现。
数据独立
I've taken your post with great consideration and the difficulty is that there are many unique nuances with my app that won't allow me to simplify it to mirror the real world.
恰恰相反。事实上，您正在编写一个处理现实世界的 app+db。因此，数据库必须反映您希望参与的真实世界（限于企业范围）。成千上万的建模者成功地做到了这一点（数百万人错误地做到了）。
就您 "nuances" 和应用程序的复杂性而言，您没有将数据建模为数据，结果将是一个复杂的应用程序与错误建模的数据库交互，或者更糟，一个non-database。所有这些 "nuances" 和复杂性实际上都是数据；关于数据的事实；关于数据的规则；以及数据之间的关系。但是您有一个既定的观点，即 "nuances" 和复杂性存在于应用程序中，存在于您的 "models" 中，而不存在于数据中。
所以你的想法是错误的。
数据中的每条规则、约束、控制、细微差别、复杂性都必须在数据中实现。这只是根据 RM 定义的数据。否则你就没有数据独立性，没有数据库（只是一堆用于数据存储的文件），没有完整性，没有关系能力，没有速度。更糟糕的是，您将永远修复应用程序层（对象堆栈）中的 "nuances" 和复杂性。
数据定义
让我从第一原则开始。
- 数据库是事实的集合，包括这些事实之间的关系
假设您理解了这一点，接下来有一个重要的观点。
- 没有不能声明的事实。
这是 RM 所基于的一阶逻辑。因此，没有 "model" 太复杂（具有 "nuances" 或太多 "nuances"）而无法根据 FOL 进行声明。所要求的科学练习是将复杂性降低到 FOL 事实。
在某种程度上，这些事实是关于现实世界的事实，并且它们反映了真相，您的数据库将不受更改的影响（您可以轻松扩展数据库和应用程序）。例如。提供商、服务、专业化是单独的事实。
如果那些 "facts" 是您选择存储的 "facts"（从您的应用程序、对象设计等角度来看是相关的），例如。提供商、服务和专业化作为一个单一的复杂 "fact"，而不是离散的事实，并且 不是 对现实世界的反映，您的数据库和对象 (a) 将很难更改, 和 (b) 将永远不断变化，直到它们被提升，以至于它们 do 反映了现实世界。您必须每个季度 "re-factor" "database"。
保密性
The data is very confidential so I'm reluctant to get to far into the matter.
45 年来，我们一直在处理机密数据 and/or 系统，从未违反保密规定。
太阳底下无新鲜事
我们处理的是结构，不是内容，建议你的结构是这样不合理它既新颖又独特，无法 (i) 讨论或 (ii) 建模。
但最重要的是，如果您无法描述它（以 FOL 术语），您就无法对其建模。如果你不能对其建模，你就不能编写一个应用程序来处理它（你可以尝试，但正如这里所证明的那样，你将陷入那个未解决的位置）。
注意到 OO/ORM 文献教导人们沉迷于数据 内容，以避免处理结构、意义、相关性等等，请注意，我不想知道。而练习不需要知道，内容。仅根据含义、相关性、关系描述数据，我们将对所需结构进行建模。
My question was more about how to create a cycle of many-to-many relationships with 3 models than whether my models "should" have them or not.
我想我明白了。这将增加文章的复杂性，而复杂性已被确定为根本问题。如果你要我造一架没有机翼的飞机，而我告诉你你的方法不正确，你需要机翼，那么告诉我你正在寻找可以告诉你如何制造一架没有机翼的飞机的人是没有意义的，你没看懂。
推理
I would love to hear your reasoning if you believe there should never be a situation like this in any database.
再说一次，你的思路是错误的。并不是说在任何数据库中都不应该有这样的情况，而是 如果 有这样的情况，它会引发一个危险信号（对合格和有经验的建模者）数据尚未规范化，尚未组织成离散的事实。这意味着您需要退后一步，首先处理 "models" 中的复杂性。那么你当前关注的关系就会被简化。
那么，是的，数据库中不会出现这种情况。
我的推理是 Codd 的 RM 及其背后的原则。它已成为许多论文的主题。 （以及许多 non-relational 或 anti-relational，例如支持 OO/ORM "model" 的 "papers"。）
- 具体来说，如果你有一个 n-ary 关系（你正在寻找的 three-way 关系的技术术语），那可以而且应该被解析为 [multiple]二元关系（two-way 关系）。例如。我建议的 TRD。
OO/ORM神话
在“喜欢听你的推理”的背景下，有两个方面，我已经给出了你应该做什么 边，上面。这就是你应该不应该做的或者你的方法被破坏的原因 边。我从哪里开始。
OO/ORM模型是"database"仅仅是一个存储位置，让对象"persistent"成为对象的奴隶，构建单体，对象层class化，复杂，是解决任何问题的方法。
OO/ORM 模型彻底失败。它没有任何科学依据。
(注意到由于教育系统的破坏，这些天 "mathematicians" 和 "theoreticians" 写 "papers" "prove" 完成并说出胡说八道。这是胡说八道，因为它与既定的科学相矛盾。他们不是 class 旧派的数学家和理论家，他们拒绝矛盾；non-science；胡说八道的证明。他们能写出这样的唯一方法荒谬 "proofs"，以保持对其他科学的无知状态，病态否认状态。）
具体来说，他们否认关系模型（虽然提到它是为了让他们的论文具有一定的可信度，但这是一种欺诈）；它的规定（例如数据独立性，FOL）；它的禁令，他们拒绝关系数据模型（UML 不能像 IDEF1X 那样建模数据），因此他们生成 non-relational 文件，这些文件没有关系完整性、功能或速度。
他们采用锤子哲学（即，如果一个人只知道一把锤子，那么每个问题看起来都像一个奈），令人震惊地否认马斯洛在一个多世纪前科学地摧毁了它。这导致他们将更多层、更多复杂性堆积到单体中。反过来当然是，为工作使用正确的工具，这意味着根据数据标准 RM 定义数据，并根据您选择的任何 OO 哲学分别定义对象.
他们试图在对象中做所有事情，在 UML 中建模所有事情（这无论如何都不是标准；也不足够[一个符号加一百万个符号]，它没有分解，它实际上是 free-for-all 每个人都做自己的事）。
存在的模型否认了这样一个事实，即自 1980 年代以来，在软件行业中，我们构建、编写和部署组件。数据库中的数据库组件，对象中的程序组件。不是单一的巴别塔，那是 1970 年代以前的技术。
自 1984 年以来，我们就有了 Client/Server 和 Open Architecture 标准。自 1960 年以来，我们就有了 OLTP 事务标准，并于 1984 年在 C/S 上下文中重申。OO/ORM 人群公然反对这些标准中的每一个，他们构建了单体对象堆栈，没有架构，没有组件，没有交易，没有一切。 （向吟游诗人道歉。）
您可能会考虑每个人（甚至是漫画家）对 OO/ORM 堆栈、单体、non-architecture 的了解，并将其与 开放架构中的组件部署进行比较 图表，如上所示。
此外，他们否认每个实施"model"是一个巨大的失败，他们否认证据事实，并继续补充复杂性和难以管理的对象层的复杂性。由于 non-architecture 而失败的 "model"，其中一部分正是失败的复杂性。
如果他们对现实的病态否认本身并不能作为精神错乱的证据，那么还有更多，更多。十二步者对精神错乱有一个有趣的定义：一遍又一遍地做同样的事情，每次都意识到它会产生相同的结果，但期望下一次会有不同的结果。这并没有阻止他们为复杂模型增加更多的复杂性，也没有阻止他们推销他们 1970 年代之前的技术，如 "modern" "science".
但这并不能阻止他们写更多的书并推销他们失败的作品"model"。
OO/ORM人群孤立存在，病态地否认现实
换句话说，在 2015 年，在 un-architected 整体中实现软件 "does everything"，而不是架构师，这太疯狂了；设计;建造;并在正确的架构位置部署软件组件。
OO/ORM "Model" 作为数据
您一直调用表 "model" 的事实是另一个危险信号。这证实了您在其中的复杂性太多了。数据库由简单的表组成，每个表反映一个离散的事实，而不是模型。就您认为它们 "models" 而言，您拥有（通常由于复杂对象和 class 固定概念的固定概念）对象+数据+复杂性组合，而不是离散数据和离散对象。这就是导致 app+db 失败的确切问题。
所以下一步是 (a) 搁置当前的焦点重新如何关联 un-normalised 复杂 "models"，并 (b) 规范化那些 "models" 这样它们是根据关系数据库定义，因此它们是离散的事实。接下来，(c) 相关的规范化表将是 straight-forward.
In one instance, each model acts as a type of 'User' but in another, they don't.
这正是必须合理化、规范化的 mashed-up 概念的类型，这样它 (a) 绝对清楚 [当它是用户时，当它不是时] (b ) 在数据中定义，在 FOL 术语中，作为离散事实 (c)，这样您就可以自信地针对它编写代码，从中构建对象。相反，如果缺乏这种清晰度，对象层中保留的复杂性，将导致复杂对象失败，更重要的是，数据存储在没有完整性、功能或速度的文件中。
Self-Contradiction
考虑一下。由于您正在寻求关系完整性、力量和速度，因此您不能同时
寻求保留未解决的复杂性，即 well-known 破坏完整性、力量和速度，或
拒绝执行您寻求的主机完整性、功能和速度要求。
在你这边，这是一个巨大的、双重的矛盾。这是一个哲学和推理问题，你必须自己考虑和解决。 OO/ORM 引诱人们相信魔法，如此疯狂 self-contradictions。
Regardless, I was very impressed with your answer and really appreciate the time you took to make the diagram.
谢谢。不客气。
这花了我整整五分钟的时间。因为我很清楚。因为我遵循科学原则和标准。因为自 1970 年以来我们就有了科学和方法论。因为自 1987 年以来我们就有了建模方法论和对关系数据建模的完整符号（自 1993 年以来作为标准，IDEF1X）。关键是，这没什么特别的，可悲的事实是，它并不常见，但应该如此。第二个可悲的事实是，它在 OO/ORM 世界中是未知的。
进一步阅读
您可能对此问题感兴趣并且。答案涵盖了关系数据库的许多方面，您肯定必须处理这些问题，如果不是现在，那么在将来的某个时候。我提请您注意现在的最低阅读是：
- Response to Update 3，第 1、2 和 6 页，
- 特别包括嵌入式 link 到 Predicates
这可能会让你对推理有所了解； RM 提供的数据定义深度； 所有 事实都可以用 FOL 谓词来声明，OO/ORM 人群完全不知道。
您可以选择在您的问题中添加 更新 并询问如何根据 RM 声明一个或另一个 "model" ，作为离散事实，或打开一个新问题（然后 ping 我）。
相反，如果你选择坚持你的立场，即最初的问题，那么我想我已经回答了（但答案提出了你必须解决和解决的问题）。
请认真学习并评论或提问。
我有以下型号..
- 提供商
- 患者
- 诊所
就像一个生态系统，所有模型之间都应该有多对多的关系。能够查询各个方向的数据非常重要
在深入研究 Active Record 关联之后，我发现许多博客警告不要 has_and_belongs_to_many 并使用 has_many :through。唯一的问题是需要 table 来充当 "middle-man"，因为没有更好的词，但我不确定这将如何与 3 个模型一起使用。
另一种选择是 polymorphic 关联，但我不确定如果该方法不适用于这种特定情况，我是否应该花时间了解该方法。
关于如何建立这些关系以获得最大的灵活性和效率，有什么建议吗？
I have the following models
表，如果它们是为关系数据库建模的，否则是文件。
It's very important that I am able to query data from all directions.
明白了。这在关系数据库中简单易行。
Like an eco-system, all models should have many-to-many relationships with one another.
这是不正确的。
如果这三个中的每一个都可以与另外两个相关联，那么您的数据就没有建模。有一些您尚未确定的基本依赖项。例如：我可以想象：
提供者在诊所
提供服务
诊所为患者提供服务
患者到诊所就诊以获得服务
因此，患者与提供者之间的任何关系都是通过诊所，而不是私下，没有诊所。
首先理顺这些规则和依赖关系，这将导致少于三个关联表。像这样：
回复评论
Any advice on how to create these relationships for maximum flexibility and efficiency?
好吧，E F Codd 博士的 关系模型 被牢固地确立为 模型，组织数据的方法，使其具有（a）完全完整性（对象不能）（b）最大灵活性（c）最大速度。在它问世的 45 年里，没有其他竞争者。这就是我正在使用的模型。支撑该模型的原则是我提出建议时所依赖的原则。
当然，在我 34 年的数据库实施过程中，所有这些都得到了确认和加强。以及数以千计的其他 high-end 实现。
数据独立
I've taken your post with great consideration and the difficulty is that there are many unique nuances with my app that won't allow me to simplify it to mirror the real world.
恰恰相反。事实上，您正在编写一个处理现实世界的 app+db。因此，数据库必须反映您希望参与的真实世界（限于企业范围）。成千上万的建模者成功地做到了这一点（数百万人错误地做到了）。
就您 "nuances" 和应用程序的复杂性而言，您没有将数据建模为数据，结果将是一个复杂的应用程序与错误建模的数据库交互，或者更糟，一个non-database。所有这些 "nuances" 和复杂性实际上都是数据；关于数据的事实；关于数据的规则；以及数据之间的关系。但是您有一个既定的观点，即 "nuances" 和复杂性存在于应用程序中，存在于您的 "models" 中，而不存在于数据中。
所以你的想法是错误的。
数据中的每条规则、约束、控制、细微差别、复杂性都必须在数据中实现。这只是根据 RM 定义的数据。否则你就没有数据独立性，没有数据库（只是一堆用于数据存储的文件），没有完整性，没有关系能力，没有速度。更糟糕的是，您将永远修复应用程序层（对象堆栈）中的 "nuances" 和复杂性。
数据定义
让我从第一原则开始。
- 数据库是事实的集合，包括这些事实之间的关系
假设您理解了这一点，接下来有一个重要的观点。
- 没有不能声明的事实。
这是 RM 所基于的一阶逻辑。因此，没有 "model" 太复杂（具有 "nuances" 或太多 "nuances"）而无法根据 FOL 进行声明。所要求的科学练习是将复杂性降低到 FOL 事实。
在某种程度上，这些事实是关于现实世界的事实，并且它们反映了真相，您的数据库将不受更改的影响（您可以轻松扩展数据库和应用程序）。例如。提供商、服务、专业化是单独的事实。
如果那些 "facts" 是您选择存储的 "facts"（从您的应用程序、对象设计等角度来看是相关的），例如。提供商、服务和专业化作为一个单一的复杂 "fact"，而不是离散的事实，并且 不是 对现实世界的反映，您的数据库和对象 (a) 将很难更改, 和 (b) 将永远不断变化，直到它们被提升，以至于它们 do 反映了现实世界。您必须每个季度 "re-factor" "database"。
保密性
The data is very confidential so I'm reluctant to get to far into the matter.
45 年来，我们一直在处理机密数据 and/or 系统，从未违反保密规定。
太阳底下无新鲜事
我们处理的是结构，不是内容，建议你的结构是这样不合理它既新颖又独特，无法 (i) 讨论或 (ii) 建模。
但最重要的是，如果您无法描述它（以 FOL 术语），您就无法对其建模。如果你不能对其建模，你就不能编写一个应用程序来处理它（你可以尝试，但正如这里所证明的那样，你将陷入那个未解决的位置）。
注意到 OO/ORM 文献教导人们沉迷于数据 内容，以避免处理结构、意义、相关性等等，请注意，我不想知道。而练习不需要知道，内容。仅根据含义、相关性、关系描述数据，我们将对所需结构进行建模。
My question was more about how to create a cycle of many-to-many relationships with 3 models than whether my models "should" have them or not.
我想我明白了。这将增加文章的复杂性，而复杂性已被确定为根本问题。如果你要我造一架没有机翼的飞机，而我告诉你你的方法不正确，你需要机翼，那么告诉我你正在寻找可以告诉你如何制造一架没有机翼的飞机的人是没有意义的，你没看懂。
推理
I would love to hear your reasoning if you believe there should never be a situation like this in any database.
再说一次，你的思路是错误的。并不是说在任何数据库中都不应该有这样的情况，而是 如果 有这样的情况，它会引发一个危险信号（对合格和有经验的建模者）数据尚未规范化，尚未组织成离散的事实。这意味着您需要退后一步，首先处理 "models" 中的复杂性。那么你当前关注的关系就会被简化。
那么，是的，数据库中不会出现这种情况。
我的推理是 Codd 的 RM 及其背后的原则。它已成为许多论文的主题。 （以及许多 non-relational 或 anti-relational，例如支持 OO/ORM "model" 的 "papers"。）
- 具体来说，如果你有一个 n-ary 关系（你正在寻找的 three-way 关系的技术术语），那可以而且应该被解析为 [multiple]二元关系（two-way 关系）。例如。我建议的 TRD。
OO/ORM神话
在“喜欢听你的推理”的背景下，有两个方面，我已经给出了你应该做什么 边，上面。这就是你应该不应该做的或者你的方法被破坏的原因 边。我从哪里开始。
OO/ORM模型是"database"仅仅是一个存储位置，让对象"persistent"成为对象的奴隶，构建单体，对象层class化，复杂，是解决任何问题的方法。
OO/ORM 模型彻底失败。它没有任何科学依据。
(注意到由于教育系统的破坏，这些天 "mathematicians" 和 "theoreticians" 写 "papers" "prove" 完成并说出胡说八道。这是胡说八道，因为它与既定的科学相矛盾。他们不是 class 旧派的数学家和理论家，他们拒绝矛盾；non-science；胡说八道的证明。他们能写出这样的唯一方法荒谬 "proofs"，以保持对其他科学的无知状态，病态否认状态。）
具体来说，他们否认关系模型（虽然提到它是为了让他们的论文具有一定的可信度，但这是一种欺诈）；它的规定（例如数据独立性，FOL）；它的禁令，他们拒绝关系数据模型（UML 不能像 IDEF1X 那样建模数据），因此他们生成 non-relational 文件，这些文件没有关系完整性、功能或速度。
他们采用锤子哲学（即，如果一个人只知道一把锤子，那么每个问题看起来都像一个奈），令人震惊地否认马斯洛在一个多世纪前科学地摧毁了它。这导致他们将更多层、更多复杂性堆积到单体中。反过来当然是，为工作使用正确的工具，这意味着根据数据标准 RM 定义数据，并根据您选择的任何 OO 哲学分别定义对象.
他们试图在对象中做所有事情，在 UML 中建模所有事情（这无论如何都不是标准；也不足够[一个符号加一百万个符号]，它没有分解，它实际上是 free-for-all 每个人都做自己的事）。
存在的模型否认了这样一个事实，即自 1980 年代以来，在软件行业中，我们构建、编写和部署组件。数据库中的数据库组件，对象中的程序组件。不是单一的巴别塔，那是 1970 年代以前的技术。
自 1984 年以来，我们就有了 Client/Server 和 Open Architecture 标准。自 1960 年以来，我们就有了 OLTP 事务标准，并于 1984 年在 C/S 上下文中重申。OO/ORM 人群公然反对这些标准中的每一个，他们构建了单体对象堆栈，没有架构，没有组件，没有交易，没有一切。 （向吟游诗人道歉。）
您可能会考虑每个人（甚至是漫画家）对 OO/ORM 堆栈、单体、non-architecture 的了解，并将其与 开放架构中的组件部署进行比较 图表，如上所示。
此外，他们否认每个实施"model"是一个巨大的失败，他们否认证据事实，并继续补充复杂性和难以管理的对象层的复杂性。由于 non-architecture 而失败的 "model"，其中一部分正是失败的复杂性。
如果他们对现实的病态否认本身并不能作为精神错乱的证据，那么还有更多，更多。十二步者对精神错乱有一个有趣的定义：一遍又一遍地做同样的事情，每次都意识到它会产生相同的结果，但期望下一次会有不同的结果。这并没有阻止他们为复杂模型增加更多的复杂性，也没有阻止他们推销他们 1970 年代之前的技术，如 "modern" "science".
但这并不能阻止他们写更多的书并推销他们失败的作品"model"。
OO/ORM人群孤立存在，病态地否认现实
换句话说，在 2015 年，在 un-architected 整体中实现软件 "does everything"，而不是架构师，这太疯狂了；设计;建造;并在正确的架构位置部署软件组件。
OO/ORM "Model" 作为数据
您一直调用表 "model" 的事实是另一个危险信号。这证实了您在其中的复杂性太多了。数据库由简单的表组成，每个表反映一个离散的事实，而不是模型。就您认为它们 "models" 而言，您拥有（通常由于复杂对象和 class 固定概念的固定概念）对象+数据+复杂性组合，而不是离散数据和离散对象。这就是导致 app+db 失败的确切问题。
所以下一步是 (a) 搁置当前的焦点重新如何关联 un-normalised 复杂 "models"，并 (b) 规范化那些 "models" 这样它们是根据关系数据库定义，因此它们是离散的事实。接下来，(c) 相关的规范化表将是 straight-forward.
In one instance, each model acts as a type of 'User' but in another, they don't.
这正是必须合理化、规范化的 mashed-up 概念的类型，这样它 (a) 绝对清楚 [当它是用户时，当它不是时] (b ) 在数据中定义，在 FOL 术语中，作为离散事实 (c)，这样您就可以自信地针对它编写代码，从中构建对象。相反，如果缺乏这种清晰度，对象层中保留的复杂性，将导致复杂对象失败，更重要的是，数据存储在没有完整性、功能或速度的文件中。
Self-Contradiction
考虑一下。由于您正在寻求关系完整性、力量和速度，因此您不能同时
寻求保留未解决的复杂性，即 well-known 破坏完整性、力量和速度，或
拒绝执行您寻求的主机完整性、功能和速度要求。
在你这边，这是一个巨大的、双重的矛盾。这是一个哲学和推理问题，你必须自己考虑和解决。 OO/ORM 引诱人们相信魔法，如此疯狂 self-contradictions。
Regardless, I was very impressed with your answer and really appreciate the time you took to make the diagram.
谢谢。不客气。
这花了我整整五分钟的时间。因为我很清楚。因为我遵循科学原则和标准。因为自 1970 年以来我们就有了科学和方法论。因为自 1987 年以来我们就有了建模方法论和对关系数据建模的完整符号（自 1993 年以来作为标准，IDEF1X）。关键是，这没什么特别的，可悲的事实是，它并不常见，但应该如此。第二个可悲的事实是，它在 OO/ORM 世界中是未知的。
进一步阅读
您可能对此问题感兴趣并且
您可以选择在您的问题中添加 更新 并询问如何根据 RM 声明一个或另一个 "model" ，作为离散事实，或打开一个新问题（然后 ping 我）。
相反，如果你选择坚持你的立场，即最初的问题，那么我想我已经回答了（但答案提出了你必须解决和解决的问题）。
请认真学习并评论或提问。