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.