如果其中一个关系数据库范例是面向元组的，那么我们在这里有最大的限制。
如果可以设计面向列的数据库，那将大大提高性能。 向量操作将开箱即用，索引，散列用于简单符号列查找，后台链接列表作为引擎。
内存映射：以微秒为单位转储大块以及加载这些磁盘映像 并且仍然使用多个供应商支持的良好理解和标准语言（SQL） 想象一下，由于它的简单性，可以设计多少工具来连接那个东西 它不会更强大（同时和KISS）？
更新
感谢所有贡献者
虽然我发现你的所有答案都非常有用，但问题已被不公正地关闭了。
答案 0 :(得分：4)
所有现代RDBMS都面向行吗？
没有。它们专为特定任务而设计，例如OLTP vs OLAP。即使像MySQL这样的流行应用程序也有列存储引擎（例如：Infobright）。并且DBMS也是从头开始构建为面向列的DB。
以下是您可能感兴趣的内容：C-Store: A Column-oriented DBMS （PDF格式）
LucidDB是一个流行的面向列的数据库，用于数据仓库和BI：
LucidDB是第一个也是唯一一个 开源RDBMS专用 完全用于数据仓库和 商业智能。它基于 架构基石，如列存储，位图索引，哈希 加入/聚合和页面级别 multiversioning。大多数数据库 系统（专有和 开源）重点开始生活 关于交易处理 能力，然后获得分析 作为一个坚持的能力 事后的想法（如果有的话）。相比之下， LucidDB的每个组成部分都是 设计符合要求 灵活，高性能的数据 集成和复杂的查询 处理过程。此外， 内在的全面性 其架构范围意味着 用户简单：没有DBA 必需的。
请在此处查看与您感兴趣的内容相关的功能列表：LucidDB Features
仍然使用得很好理解 标准语言（SQL）即多个 供应商支持。
您可以将SQL与LucidDB一起使用。
答案 1 :(得分：4)
有几个面向列的SQL DBMS，它们已存在多年。 Sybase IQ和Vertica是两个众所周知的示例。这些是列存储，因为它们在内部使用基于列的存储 - 它们仍然使用与任何其他SQL DBMS完全相同的基于SQL表的数据模型。
不幸的是，术语“面向列”或“列存储”最近被一些NOSQL数据库占用，以指代完全不同的概念。比如Bigtable。在此上下文中，面向列意味着不同的数据模型（不是关系或SQL）。这个长达数十年之久的新定义导致了一系列的混乱 - 特别是那些在新一波产品出现之前没有听过这个术语的人。
http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-major-types-of_29.html
答案 2 :(得分：1)
Google的专有数据库已基于列。这是您的搜索和其他Googly事情如此迅速发生的原因之一。请参阅此wiki article，其中还包含指向其他实现的链接和参考。
至于为什么不使用这种类型的数据库？有几个原因，其中之一是它并非所有实现都必需。例如，您在家中运行一些桌面计算机运行一些桌面数据库，而不是运行大规模可伸缩数据存储库的大型机。你可以使用后者，但用它来存储你的数据就像用链锯切黄油一样。
此外，还有其他几种数据库类型，如面向对象和本体。没有任何一种方法适合所有事情，但就目前而言，经过考验的真正的行基于适用于许多人的工作。
答案 3 :(得分：1)
商业上有几种column-oriented databases，例如Vertica。我在一个专门的高插入率，写作主要商店与固定架构。虽然优化的索引很重要，但对我们来说更重要的是在具有稀疏值分布的列上实现了改进的压缩率。
答案 4 :(得分：1)
答案 5 :(得分：0)
如果您查找“nosql”，您会发现一大堆最近的非面向行的数据库，例如couchdb
答案 6 :(得分：0)
“如果可以设计面向列的数据库......”