As our main data repository, we will use a mapping structure to index all enrolled players using their address. If you remember, in the previous chapter, Peer-to-Peer Auctions in Ethereum we learned that a mapping is similar to a big key-value database with all possible key values filled with zeros.

In the tontine.sol file, add the following code:

pragma solidity ^0.4.24;

contract Cplayer{
    struct player{
        string name;
        uint PhoneNumber;
        address Paddress;
        uint id;
    }
    mapping(address => player) players;
}

The code is pretty self-explanatory: we declare a new type called player, which is a structure (struct) that represents a user’s details.

We also declare a players mapping to store the users' details. In the mapping definition (key ≥ value), the key (which acts like a unique ID) can be almost any type, except for a mapping, a dynamically sized array, a contract, an enum, or a struct. The corresponding value can actually be any type, including a mapping.

It’s magic that the data storage is fully managed by a single line of code. In our case, declaring a mapping in the code is enough to store players. We don’t have to create a database or table or install a database driver.

To give you an idea, the previous Solidity code is similar to creating a table in SQL:

CREATE TABLE players (`address` varchar(32) NOT NULL,  PRIMARY KEY  (`address`) …);

Generally, in a standard RDBMS, you define a unique key as an incremental integer, whereas for a mapping, the uniqueness is ensured by the collision-resistance property of sha256 used to manage the keys, therefore two different keys can’t have the same hash.