Corda 科尔达州管理最佳实践

一个战略性问题……当一个州将拥有一对多类型的数据时，我们应该始终在父州对象下创建一个集合，还是为子州创建一个单独的状态对象，并引用父州？示例（雇主1:M员工）或（雇主1:M位置）…。什么时候决定哪种策略？我列出了每种方法的优点和缺点。不知道什么时候使用什么策略。寻找一些反馈

将子对象添加为集合 将子对象添加为单独的状态对象

---

由于状态链接到后端的单个表，因此很难管理子集合。目前，我认为您需要保持集合属性未绑定（即未映射到数据库列并标记为瞬态，以便类仍然可以序列化），然后对可分配给状态集合属性的子记录执行单独的筛选查询。然后，当任何更改被持久化时，它将不会尝试持久化子记录。对子记录的更改应通过其自己的状态事务单独完成。如果Corda有一个支持JPA特性的特性，比如@OneToMany，在表之间进行连接，那就太好了。这将有助于查询，但持续的状态更改仍需要单独处理。可能有一种方法我不知道。

这是一个老问题，但似乎没有一个公认的答案，所以我要试一试

首先，Corda节点不仅仅是应用程序的后端，它还是分散事务处理系统中的一个节点。后者必须是您的关键需求，否则您将不会使用Corda

其次，Corda实现了UTXO（未使用的事务输出）范式，用于通过一系列事务演化分布式状态，其中表示输入状态的对象集合被“使用”（或消耗，变得不可用），并被表示输出状态的另一个对象集合所取代。状态对象本身可能具有复杂的结构，但当它们演化时，它们意味着作为一个整体进行交换。这与以太坊（Ethereum）或Hyperledger不同，后者的全局状态基本上是可以任意更改的大量不相关键值对的集合。UTXO模型允许轻松实现全局状态模型很难实现的特性，例如事务隐私。这里重要的一点是，Corda可以模仿全局状态模型，但它在这方面效率低下，并且失去了大部分好处

因此，状态建模的方式必须基于CorDapp分布式状态的预期演变。因此，要问自己的问题可能如下：

儿童国家是否会“过自己的生活”，即进化 独立于母州？“是”的一个例子是 ，其中标记类型和标记本身是 尽管存在明显的父子关系，但仍存在不同的状态。网络 参与者可以在不控制子状态的情况下交易子状态 母国

是否有必要将信息保留在文档中 一方当事人的父国而非子国，反之亦然 参与交易？“是”的一个例子是 使用Oracle注销子状态对象输出，而无需 向家长展示。你和我有相似之处吗 当甲骨文确定利率时，交易中断

是否会出现网络参与者可能需要 知道（即保存在vault中）子状态，但不知道父状态 国家。“是”的一个例子是分类账外结算 类似于的工作流，其中支付代理 可以在不一定知道细节的情况下解决债务 导致义务产生的协议

如果上述任何问题的答案为“是”，则必须将子项表示为单独的状态，否则最好将它们嵌入父状态

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