我们可以看到，数据从一个3行×4数据列的矩阵(表HR)转变成了一个12行×2数据列的矩阵(表VR)。横向表的记录条数与列数的乘积似乎和纵向表的行数相等。例如：3×4=12。不过，这种假设并不一定是正确的，稍后会在文中讨论这个问题

纵向数据存储的利与弊
　　传统横向方式存储数据可以带有预先设定的结构和列，所以有很多优点，但也有缺点。假设我们设计的应用程序带有一个窗体显示区，而这个显示区是完全动态化的，且没有固定的字段号码或名称。用户可以即时创建一个新的字段，并赋予该字段名称和值。要怎样才能在数据库中长期存储这样的窗体呢?

　　又假设我们需要根据业务要求来创建一些窗体，各个窗体具有一些符合特定业务需求的不同的字段。我们要把各个窗体的数据都存储在一个横向结构表中，该表中给每一个字段分配一个特定的列，而每个窗体就是该横向表的一行。经过一段时间以后，由于业务需求需要对某个窗体添加一个新的字段。为了将新字段添加到窗体中，就必须改变用户界面和持久层逻辑，而且实际存储的表还需要为此添加额外的列，这样该应用程序还需要重新进行测试和调配。在一个开发人员没有权限直接访问数据库的环境中，数据库管理员团队也要参与到表的实际修改操作当中。如果只需要修改一次也就罢了，但是如果过一段时间后又需要添加另外一个字段呢?

　　要解决上面提到的两种情况，就需要使用纵向数据存储方式，并在应用层和用户界面上采用一种不同的动态逻辑。因为数据能够以“键/值”配对的形式存储在只有两列的表中，并通过单一的ID的形式将数据通通绑定在一个逻辑窗体中，而且对于能够在一个窗体中设置多少字段并没有限制。而后，纵向表中的每个逻辑行的字段数就可以不一样了。由此可见，纵向数据存储结构的最大好处就是灵活性，不过也有很多弊端。

　　首先，虽然弹性是有了，但失去了对数据的控制权，也就是说很难维持数据的规范化。举个例子，如果我们在一个纵向表中存储了一个共同基金的信息，根据分析师的名字和联系方式都能够对这些信息做出修改;而通常情况下，这种类型的信息都是存储在不同的表种，并通过外键ID连接到基金表的。而且，在纵向表中，字段的数据类型设置也会出现问题。因为在“值”这一列，只能设置成一种数据类型(例如，设置成varchar)，而所有的值都必须是这种类型的值，或者你也可以在保存和检索操作中不停来回转换数据类型。此外，在纵向表中不可能存储类似于BLOB和CLOB这种特殊类型的数据。

　　纵向表还有一个缺点就是数据的一致性问题。将所有的列名都输入到一个“键”列中，使用户(或应用程序)能够很轻易就把相同的数据存储成不同的“键”和“值”。例如，用户可以创建一个新字段，命名为“公司”，赋予其值为“甲骨文”;而其他用户可能将字段名改为“企业”，而值为“甲骨文”，事实上两个用户的数据是相同的