Эквивалентен ли контракт таблице или строке в традиционной базе данных?

Следуя аналогии с тем, что блокчейн — это своего рода база данных , я пытаюсь понять, как мои данные должны быть структурированы и храниться в блокчейне.

Я читал о написании контрактов в Solidity и вижу, что контракты могут содержать сложные типы данных, такие как сопоставления, массивы, стойки и т. д.

Должен ли я хранить данные таблицы типа базы данных внутри одного из них внутри контракта, или мне следует создать много контрактов одного и того же типа и хранить строку данных в каждом?

Возможно, пример поможет объяснить, скажем, я хочу сохранить отношения между учетными записями пользователей, создам ли я контракт «таблица» следующим образом:

pragma solidity ^0.4.0;

/// @title Company roles.
contract CompanyRole {

    mapping(address => address) public directors;
}

или контракт «строка»:

pragma solidity ^0.4.0;

/// @title Company roles.
contract CompanyRole {

    address person; // company the role is valid for
    address company; // company the role is valid for
    uint type;   // the type of role
}

Было бы полезно знать плюсы и минусы обоих или других подходов, включая финансовые последствия.

В основном мой вопрос заключается в том, где должны храниться данные таблицы?

Ответы (1)

Solidity предоставляет нам структуры, массивы, сопоставления и журналы событий, но ничего похожего на таблицы базы данных. Нам приходится разрабатывать полнофункциональные реализации на более низком уровне, чем мы привыкли.

Нет правильного ответа для каждой ситуации. Могу описать несколько вариантов использования.

Контракт строки будет создавать каждый экземпляр как небольшую объектную сущность с методами доступа. Это, наверное, самый дорогой газ. У такого фабричного шаблона есть варианты использования; всякий раз, когда есть причина создать много копий базового контракта, например, фабрика токенов. На практике я обнаружил, что обычно хочу вести список созданных контрактов.

Контракт таблицы с использованием массивов позволяет выполнять итерацию по структурам, когда ключи неизвестны, но не может обеспечить произвольный доступ, когда ключи известны.

Контракт таблицы, использующий сопоставления, разрешает произвольный доступ к структурам, когда ключи известны, но не может перечислять ключи, когда они неизвестны, или подсчитывать их.

Генераторы событий могут информировать клиентов об изменениях состояния. Они могут включать поисковые индексы и могут быть информативными для клиентов. Иногда решает проблему отсутствия у клиента очевидного способа узнать действительные ключи.

Я обнаружил, что потребность во всем этом довольно распространена. Произвольный доступ, когда ключи известны, а также способ просмотра ключей, когда они неизвестны. Для этого вы можете иметь сопоставление со структурами в сочетании с массивом ключей.

введите описание изображения здесь

Довольно подробное объяснение с примером кода: https://medium.com/@robhitchens/solidity-crud-part-1-824ffa69509a#.jh7gw1ekm

Обновление: несколько простых шаблонов хранения здесь: Блог: Простые шаблоны хранения в Solidity

Большое спасибо. Ссылка на Solidity CRUD выглядит очень полезной, я прочитаю ее подробно
Надеюсь, поможет. Бесстыдно ссылается на голосование/ответ, если ответ полезен. :-)