上周我问了一个问题：KSQL: append multiple child records to parent record
但是，在我对问题的解释中，我确实简化了事情，并且发现我对现实世界中设置的复杂性有些担心。为了快速重申，我正在使用的数据类型是付款和付款涉及的各方：
payments:
| id | currency | amount | payment_date |
|------------------------------------------|
| pmt01 | USD | 20000 | 2018-11-20 |
payment_parties:
| id | payment_id | party_type | party_ident | party_account |
|-----------------------------------------------------------------|
| prt01 | pmt01 | sender | XXYYZZ23 | (null) |
| prt02 | pmt01 | intermediary | AADDEE98 | 123456789 |
| prt03 | pmt01 | receiver | FFGGHH56 | 987654321 |
每个表都有自己的主题，到目前为止，我采用的方法是根据payment_parties分支party_type流，并将每个流依次加入{ {1}}流。
之所以对复杂性有些担心，是因为上面的示例数据不完整。实际上，每笔付款最多可以有10个与之相关的不同方。这意味着payments流分支了10次，然后又相继联接了10次。
仅为了实现payment_parties的拆分以及将它们各自连接到payment_parties流，我最终总共要至少20条流（每个分支一个，一个分支（对于每次加入），不计算主题的源流和重新生成密钥的流。
现在，基于此，我有几个问题：
我应该担心这样的设置的性能吗？直观上来说，这感觉像是一个相对较简单的问题的相当复杂的设置。
我知道（当前）在KSQL中，无法根据所选数据创建STRUCT。 是否有任何合理的方法来模拟结构？还是可以期望在以后的KSQL版本中看到此功能？
或者，可以使用Kafka流创建Structs吗？这不会减少流的数量，但是在我看来，最终输出会更加合理。
当然，我很乐意提供任何可能缺少的信息或回答其他问题。