下面是一个虚构的简化用例;但现实世界的用例模仿了这种多对多关系。
说有工单 - ＆gt;谁有病人。工作单内的患者实体有患者的SSN，姓名，地址，年龄，体重，疾病等。
今天工作单id = 1，患者社会安全号码= 111-11-1111，姓名= John Doe进入系统。 John Doe的病=发烧。
2个月后工作单id = 2，患者社会安全号码= 111-11-1111同一患者姓名= John Doe进入系统。这次John Doe的病=背部疼痛
现在请忽略审计跟踪要求，以免我们因原始问题而脱轨。
现在工作单1可以与其他工作单相关.3。基本上工作单＆lt; - ＆GT;病人是多对多的关系。同样在数据库工作单中，患者是完全相同的数据结构，具有不同的属性和值。真实世界的用例有更多细节，但与此问题无关。
在关系数据库工单中＆lt; - ＆GT;患者关系通过联接表维护。
设计弹性搜索索引文档结构;以下就是我的想法;
拥有一种类型的单一索引＆＃34;患者＆＃34;，
用于患者数据：
{
"patient_ssn" : "111-11-1111",
"patient_fname" : "John",
"patient_lname" : "Doe",
"related_workorders" [ 2345,8979]
}
＆＃34; workorder＆＃34;
的第二种类型{
"wo_id" : 2345,
....
}
现在查询找到患者SSN为111-11-1111的所有工单。因此，将有两个查询：首先查找患者数据：然后查找来自patient.related_workorders的所有值的所有工单数据; 。所以在这种情况下;最终输出将作为父母的工作顺序（包含所有数据）并且患者有它的孩子。
两个查询正在使用提及here的应用程序端连接。在这种情况下，单个患者记录将经常更新。在这种特殊情况下使用应用程序端连接有什么缺点吗？