Ios 数据实体库存系统-一个“项目”怎么可能有一个未定义的实体“所有者”？

上下文

具体地说，我使用核心数据管理一个新的对象图，从一个非sql类型的持久数据存储转换而来

在面向对象的设计中，类/对象可以实现任意数量的接口或协议

我的实体

简化后，前三个实体如下所示：

store
items - array

person
items - array

cart (or suitcase, etc)
items - array

每个移动的人至少有两个库存容器：他们自己，比如他们的衣服或口袋里的东西，以及他们带来的容器/手推车/手提箱。从技术上讲，该系统还支持一个人携带多个集装箱旅行，但至少有一个，因此至少有两个普通库存集装箱

在旧的凌乱的无sql持久存储中，没有数据规范化，每个项目都有其名称和特定于项目的数据在每个拥有的实例中复制

现在，我计划再有两个实体：

item
name - string
itemcode - string

itemheld
itemcode - relationship (string/foreign key)
owner -  CANNOT FIGURE THIS OUT
quantity - number

多对多关系ItemHold具有每个实例的特定属性，包括数量

理想的解决方案，我无法决定如何实施

如果可能的话，我希望避免在person、store、cart之上使用抽象实体itemholder或owner，而将父实体留给更多特定于store/person/container的父代码，我更希望使用类似itemholder的接口或协议

这可能吗？还是必须使用抽象父实体

有更好的办法吗

解决方案的想法：

注意-我已经考虑了几天，并计划和重新规划了结构，我想我刚刚提出了一个选项：一个项目持有者具体实体，它与任何可能的持有者类型都有一对一的关系，但一开始看起来很糟糕，包括更新的项目持有者：

itemholder
ownerperson - object or null
ownercontainer - object or null
ownerstore - objector null

itemheld
itemcode - relationship (string/foreign key)
owner -  itemholder
quantity - number

---

这是最好的解决方案吗？

您或者需要在person/store/cart上面设置一个超类“holder”，这样您的ItemHold所有者就可以成为一个关系，或者您需要创建3种不同类型的ItemHold，每种类型都具有不同的所有者关系。@Paulw11这些都是好主意。进一步的思考使我接受并倾向于你两个建议中的前者。使用holder作为超类是有意义的，并且该holder超类位于任何更抽象的person/store/cart基类之上。早些时候，我觉得使用两个级别的抽象基类太过分了，但现在不是了。凉的