Is a contract 'kinda' equivalent to a table or a row in a traditional database?

Question

Following the analogy that a blockchain is a kind of database, I'm trying to understand how my data should be structured and stored on the blockchain.

I've read about writing contracts in solidity and I see that contracts can contain complex data types such as mappings, arrays and struts, etc.

Should I store database type table data, inside one of these inside a contract, or should I create many contracts of the same type and store a row of data in each?

Perhaps an example will help explain, say I want to store relationships between user accounts, would I create a 'table' contract as follows:

pragma solidity ^0.4.0;

/// @title Company roles.
contract CompanyRole {

    mapping(address => address) public directors;
}

or a 'row' contract:

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
}

It would be helpful to know the pros and cons of both approaches, or others, including cost implications.

Basically my question is where should table data be stored?

Answer 1

Solidity gives us structs, arrays, mappings and event logs but nothing that closely resembles database tables. We have to devise feature-complete implementations at a lower level than we might be accustomed to.

There's no right answer for every situation. I can describe some use cases.

A row contract would create each instance as a little object-like entity with accessor methods. This is probably the most gas-expensive. This sort of factory pattern has use-cases; whenever there's a reason to create many copies of a base contract, such as a token factory. In practice, I find that I usually want to keep a list of the contracts created.

A table contract using arrays allows iteration over structs when the keys are not known but fails to provide random access when the keys are known.

A table contract using mappings allows random access to structs when the keys are known but fails to enumerate keys when they're not known, or count them.

Event emitters can inform clients about state changes. These can include searchable indexes, and can be informative to clients. Sometimes solves the problem of client not having an obvious way to know the valid keys.

I've found it to be quite common to need it all. Random access when the keys are known, but also a way to browse the keys when they're not known. To accomplish that, you can have a mapping to structs in combination with an array of keys.

A fairly detailed explanation with example code: https://medium.com/@robhitchens/solidity-crud-part-1-824ffa69509a#.jh7gw1ekm

Update: Some simple storage patterns here: Blog: Simple Storage Patterns in Solidity