Скажем, фабрика контрактов используется для порождения нескольких дочерних контрактов, каждый из которых содержит связанные данные. Фактор контракта хранит все адреса производных контрактов вместе с уникальным именем каждого контракта. Существует ли простой и эффективный способ запроса информации по всем дочерним контрактам?
Например, допустим, что дочерние контракты представляют людей; можно ли написать запрос для возврата всех дочерних контрактов с определенным возрастом, именем и местом рождения (где эти свойства являются переменными-членами дочерних контрактов). Фактически это выполнение SQL-запроса по всем дочерним контрактам.
Очевидно, что наивным решением будет перебирать все дочерние контракты из карты внутри фабрики. Это ни в коем случае не идеально. В качестве альтернативы может быть создано автономное решение, в котором таблица ссылок создается вне сети с соответствующими адресами контрактов. Это решение действительно не идеально, так как я хотел бы придерживаться сетевого решения. Это также приводит к дублированию данных в цепочке, что делает блокчейн избыточным.
Проще говоря: есть ли способ построить эффективную структуру запросов для поиска контрактов, если известны адреса контрактов. Это очень похоже на реляционную базу данных, но работающую в сети. IPFS не поможет в этом контексте, поскольку вы фактически застряли с той же проблемой запроса; как эффективно искать во всех записях конкретную подинформацию в записях.
Я думал об аналогичном подходе, когда был новичком в Solidity, т.е. создать фабрику и создать новый контракт для каждой сущности. Это неэффективно и причинит вам боль во многих отношениях.
Со временем я понял, что такие варианты использования не лучше всего решать с помощью публичного блокчейна (я видел нечто подобное в Hyperledger Fabric). Но если вы все еще хотите это сделать, вы можете рассмотреть следующее:
Создайте отдельный контракт «контейнер данных» для хранения всех ваших объектов, которые не затрагиваются при обновлении вашего бизнес-контракта.
По идее, контейнер данных может хранить только ключ/значение, чтобы новые атрибуты не требовали от вас изменения контракта данных в будущем. На этот контракт ссылаются как на db из бизнес-контракта.
В идеале общедоступный блокчейн следует использовать только для подтверждения подлинности некоторых данных/состояния. А остальные такие бизнес-запросы и анализ можно делать с приватным хранилищем, содержащим те же данные.