摘要：允许智能合约定义自己的私有数据库表。有了多级索引，智能合约就具备了操作类似数据库模块的功能。因此虽然只有一列，但是的灵活性丝毫不亚于传统的数据表。
摘要上一章我们学习了开发智能合约之前需要知道的必要概念：
什么是webAssembly以及它在智能合约上下游中的位置；
什么是ABI以及怎样使用eosiocpp工具产生ABI和wasm、wast
hello智能合约的简单入门：部署和调用
如果说智能合约开发是一个锁着门的图书馆，那么之前的学习就是钥匙。现在我们终于可以拿着钥匙打开大门，走进去一探究竟。
说到智能合约开发，大家首先想到的肯定是写代码、像solidity开发一样教语法。EOS的智能合约是用C++写的，基本语法大家可以去买本C++的书；这一篇主要介绍EOS智能合约的数据存储，为大家扫清智能合约开发道路上的最后一道障碍。
什么是RAM之前我们在学习如何在主网创建账户时，曾经接触到RAM的概念。我们不能像操作以太坊那样，凭空生成一个地址作为自己的账户，而是要先有一个账户，再去创建另一个账户。其中就涉及到一个关于RAM很关键的知识点：创建账户需要消耗RAM。
当时我们只是很模糊地知道，RAM大概是内存的意思。
RAM is used to store data in an in-memory database. DApps will use this to store state information so it is quickly available to their app.
RAM是EOS主网中的内存，用于存储用户在EOS中使用频率高的数据（账户余额、合约状态等）。
BM对EOS的期望是成为区块链世界中的【操作系统】，因此可以把计算机的一些概念对标到EOS中，其中计算机中的运行内存，在EOS中就可以看做是RAM；而硬盘就可以对标EOS区块链数据库。
所以高访问量的决策类数据，例如账户余额、智能合约的当前状态等就会被存储在RAM中，并且这部分数据将长期占用RAM；而低访问的费决策性存证数据，例如交易数据，就会存储在EOS系统的硬盘中，也就是区块链中。当存储账号状态的空间不足，即RAM不足时，转账或部署合约等相关操作就无法执行。
什么是EOS数据库之前我们曾经介绍过transaction和action，action是智能合约执行的基本单元，transaction可以认为是一个或几个action组成的原子性操作。action在被称为action上下文的环境中执行，action上下文提供了执行action所需的一些条件，其中一个就是action的工作内存，这是action保存工作状态的地方。在处理一个action之前，eosio会先为它清理一次内存，因此当变量在一个action中被赋值后，另一个action的上下文是拿不到这个值的。那么在action之间传递状态的唯一方法就是把它持久存储到EOS数据库中，如下图：
这个持久化存储就是数据库存储数据。EOS允许智能合约定义自己的私有数据库表。比如上图，Apply Context的内容都是一次性的，一次action执行完成,对象就释放了，只有存储到EOSIO database的才被保存。
什么是multi_index接着上面介绍的数据库往下说， 这个私有数据表是通过multi_index来访问和交互的。EOS的multi_index类似boost的multi_index，即多索引容器。有了多级索引，智能合约就具备了操作类似数据库模块的功能。
multi_index是一个非常方便的、可以和数据库交互的容器。从字面意思来看，multi_index就是一个可以使用多索引的数据表。
如下图：
每一个multi_index容器都可以理解成传统数据库中的一张表，但是行和列稍有不同。和传统的多列的表不同的是，multi_index只有一列。这一列中的每一行都表示一个对象，通常这个对象是struct或者是class类型的，有多个成员变量。因此虽然只有一列，但是multi_index的灵活性丝毫不亚于传统的数据表。
举个例子，比如下面的这个struct：
// @abi table proposal i64
struct Proposal {
uint64_t id;
account_name owner = 0;
string description;
std::vector votes;
uint64_t primary_key() const { return id; }
EOSLIB_SERIALIZE( Proposal, (id)(owner)(description)(votes))
};
typedef eosio::multi_index proposals;
首先看第一行：
// @abi table proposal i64
在部署合约之前，我们都会用eosiocpp来生成ABI，EOS智能合约编译器可以读取struct结构体和public方法之前的注。在注释中我们可以传入两种类型：action和table，ABI就会根据我们的声明，自动在生成的ABI中添加相应的方法或者表定义。
第二个proposal就是表名，而第三个i64就是表的主键的类型。在这里主键就是id。
account_name注意到第二个成员变量owner:
account_name owner = 0;
这里的account_name是EOS自己定义的类型，也就是之前我们曾经创建过的账户名。可以理解成以太坊中的address类型。
vector
