一个战略问题......当一个州要拥有一对多类型的数据时，我们是否应该始终在父状态对象下创建一个集合，或者为该子对象创建一个单独的状态对象？示例（雇主1：M员工）或（雇主1：M位置）....何时决定采用哪种策略？我列出了一些PROS＆amp;每个人的缺点。不确定何时使用什么策略。寻找一些反馈
PROS
=====
- Easier to manage from coding standpoint
- Easy access to child data as it will always be available when querying parent from vault
CONS
=====
- As each collection object is going to be represented as separate table in the database, Each time a new state is created child data is also replicated even though there may not be update on child which will cause database to grow unessential
- If we have too many of such collection objects then serialized transaction size could be huge so performance could be worst
PROS
=====
- Child data is not replicated with each time a new parent state is updated
- When there is an update on any of the Child data only that state needs to be communicated other participant
CONS
=====
- More coding needed in order to manage child state object separately
- Child data won't be available when querying parent from vault
- Each state needs to have its own contract so child objects can't be validated on the same parent contract
答案 0 :(得分：1)
由于状态链接到持久化到后端的单个表，因此很难管理子集合。目前，我认为您需要将集合属性保持为未绑定（即未映射到数据库列并标记为瞬态，以便该类仍可序列化），然后对可分配的子记录执行单独的筛选查询到国家的集合财产。然后，如果持续存在任何更改，则不会尝试保留子记录。子记录的更改应通过自己的状态事务单独完成。如果Corda有一个功能可以支持JPA在@OneToMany等表之间进行连接的功能，那就太好了。这将有助于查询，但仍需要单独处理持久状态更改。可能有一种我不知道的方法。
答案 1 :(得分：1)
这是一个古老的问题，但是似乎没有一个可以接受的答案，所以我去。
首先，Corda节点不仅是应用程序的后端，而且是分散式交易处理系统中的一个节点。后者必须是您的关键要求，否则您将不会使用Corda。
其次，Corda实现了UTXO（未花费的交易输出）范式，用于通过一系列交易使分布式状态发展，其中代表输入状态的一组对象被“花费”（或消耗，变得不可用），并由另一组代表输出状态。状态对象本身可能具有复杂的结构，但是当它们演变时，它们意味着要整体交换。这与以太坊或Hyperledger不同，后者的全局状态基本上是不相关的键值对的大量集合，这些键值对可以任意更改。 UTXO模型允许轻松实现使用全局状态模型很难实现的功能，例如交易隐私。这里的重点是，可以使Corda模仿全局状态模型，但是这样做效率低下，并且会失去其大部分优势。
因此，状态建模的方式必须基于CorDapp分布式状态的预期演变。因此，可能要问自己的问题如下：
如果以上任何一个问题的答案为“是”，则必须将子代表示为单独的状态，否则最好将它们嵌入父代状态。