Entspricht ein Vertrag „irgendwie“ einer Tabelle oder einer Zeile in einer traditionellen Datenbank?

Der Analogie folgend, dass eine Blockchain eine Art Datenbank ist, versuche ich zu verstehen, wie meine Daten strukturiert und auf der Blockchain gespeichert werden sollen.

Ich habe über das Schreiben von Verträgen in Solidität gelesen und sehe, dass Verträge komplexe Datentypen wie Mappings, Arrays und Struts usw. enthalten können.

Soll ich Tabellendaten vom Datenbanktyp in einem dieser Verträge innerhalb eines Vertrags speichern, oder sollte ich viele Verträge desselben Typs erstellen und in jedem eine Reihe von Daten speichern?

Vielleicht hilft ein Beispiel zu erklären, sagen wir, ich möchte Beziehungen zwischen Benutzerkonten speichern, würde ich einen "Tabellenvertrag" wie folgt erstellen:

pragma solidity ^0.4.0;

/// @title Company roles.
contract CompanyRole {

    mapping(address => address) public directors;
}

oder ein 'Row'-Vertrag:

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
}

Es wäre hilfreich, die Vor- und Nachteile beider oder anderer Ansätze zu kennen, einschließlich der Auswirkungen auf die Kosten.

Grundsätzlich ist meine Frage, wo sollen Tabellendaten gespeichert werden?

Antworten (1)

Solidity gibt uns Strukturen, Arrays, Zuordnungen und Ereignisprotokolle, aber nichts, was Datenbanktabellen sehr ähnlich ist. Wir müssen funktionsvollständige Implementierungen auf einem niedrigeren Niveau entwickeln, als wir es vielleicht gewohnt sind.

Es gibt keine richtige Antwort für jede Situation. Ich kann einige Anwendungsfälle beschreiben.

Ein Zeilenvertrag würde jede Instanz als kleine objektähnliche Entität mit Zugriffsmethoden erstellen. Dies ist wahrscheinlich das Benzin-teuerste. Diese Art von Fabrikmuster hat Anwendungsfälle; immer dann, wenn es einen Grund gibt, viele Kopien eines Basisvertrags zu erstellen, z. B. eine Token-Factory. In der Praxis stelle ich fest, dass ich normalerweise eine Liste der erstellten Verträge führen möchte.

Ein Tabellenvertrag, der Arrays verwendet, ermöglicht die Iteration über Strukturen, wenn die Schlüssel nicht bekannt sind, bietet jedoch keinen wahlfreien Zugriff, wenn die Schlüssel bekannt sind.

Ein Tabellenvertrag, der Zuordnungen verwendet, ermöglicht den wahlfreien Zugriff auf Strukturen, wenn die Schlüssel bekannt sind, kann Schlüssel jedoch nicht auflisten, wenn sie nicht bekannt sind, oder sie zählen.

Ereignisemitter können Clients über Zustandsänderungen informieren. Diese können durchsuchbare Indizes enthalten und für Clients informativ sein. Löst manchmal das Problem, dass der Client keine offensichtliche Möglichkeit hat, die gültigen Schlüssel zu kennen.

Ich habe festgestellt, dass es ziemlich üblich ist, alles zu brauchen. Wahlfreier Zugriff, wenn die Schlüssel bekannt sind, aber auch eine Möglichkeit, die Schlüssel zu durchsuchen, wenn sie nicht bekannt sind. Um dies zu erreichen, können Sie eine Zuordnung zu Strukturen in Kombination mit einem Array von Schlüsseln haben.

Geben Sie hier die Bildbeschreibung ein

Eine ziemlich detaillierte Erklärung mit Beispielcode: https://medium.com/@robhitchens/solidity-crud-part-1-824ffa69509a#.jh7gw1ekm

Update: Einige einfache Speichermuster hier: Blog: Simple Storage Patterns in Solidity

Vielen Dank. Der Solidity-CRUD-Link sieht sehr hilfreich aus, ich werde ihn im Detail lesen
Ich hoffe es hilft. Bezieht sich schamlos auf positiv/beantwortet, falls die Antwort nützlich ist. :-)
Entspricht ein Vertrag „irgendwie“ einer Tabelle oder einer Zeile in einer traditionellen Datenbank?
AntwortenHierDatenschutz-Bestimmungen1y, 0v