我有一个父母的对象模型 - ＆gt;儿童关系：
关系是一个组合，一个父母可以有多个孩子，一个孩子总是一个父母，没有父母就不能生活。要保留这些数据，我们将其序列化为JSON并使用NoSQL文档数据库（MongoDB）来存储它：
{
"id": 123456,
"Attr1": "I'm a parent",
"children": [
{
"Attr1": "I'm a child"
},
{
"Attr1": "I'm another child"
}
]
}
现在我们正在尝试将此模型映射到OData EDM。我们将父对象映射为实体类型。因为孩子不能独自生活，而是父母的一部分，我们不希望他们作为实体类型，而更像是一个复杂的类型。
使用OData 2 时，我很难，因为OData 2似乎不知道原始或复杂类型的集合。一旦你需要将一个＆＃34;映射到很多＆＃34;关系，似乎有必要将关系的许多＆＃34; -side本身定义为实体类型。但是，当我将模型中的子项定义为实体类型时，OData2需要能够在服务根级别上解决这些子项。 所以以下对象的规范URL httX：//主机/ serviceroot /父（1）/儿童（2） 真的是这样的： httX：//主机/ serviceroot /儿童（1,2）
参见OData2的文档：
＆＃34;对于符合本节中寻址约定的OData服务，通过向服务根URI添加单个路径段来形成标识单个条目的绝对URI的规范形式。路径段由与Entry关联的Collection的名称组成，后跟标识Collection内条目的键谓词。例如，URI httX：//services.odata.org/OData/OData.svc/Categories（1）/ Products（1）和 httX：//services.odata.org/ OData / OData.svc / Products（1）表示相同的条目，但条目的规范URI是 httX：//services.odata.org/OData/OData.svc/Products（1） ＆＃34;
http://www.odata.org/documentation/odata-version-2-0/uri-conventions/
对我来说，OData 2似乎适合关系数据库，当对象与＆＃34;连接到多个＆＃34;关系，它们被映射到不同的表，并且每个对象都有自己的主键。在这种情况下，很容易在服务根级别上解决子对象（ httX：// host / serviceroot / Child（48346954）（其中48346954是数据库主键））因为您可以获取该对象直接用SQL表示。
但是，OData2似乎不适合可以将嵌套对象graps存储为文档（例如JSON）的文档数据库。子对象不需要是独立的文档，而是嵌套在父文档中。将此映射到OData然后解决具体子项时，您需要首先找到嵌入此子项的文档，然后从该对象图遍历到子项。无法直接获取嵌入式子项。
您怎么看？在说明OData 2不适合面向文档的数据库时我是对的吗？
使用OData 4 时，事情会发生一些变化，因为OData 4知道复杂类型的集合。所以我可以将我的孩子塑造成复杂的类型。那么我就有很多人了。父类与其子元素的关系作为父类的属性，类型为＃34;复杂集合＆＃34;。这是建模依赖和嵌套子对象的推荐方法吗？
OData 4更适合将文档从面向文档的数据库映射到REST接口吗？有人试过吗？或者是否有更多我目前看不到的陷阱，这使得OData 4在我的情况下不是一个好的选择？