我刚开始一份新工作，我将不得不用多值数据库（UniVerse）做大量的工作。我所拥有的小数据库经验是关系数据库（SqlServer），我正在寻找一些关于MVD与关系数据库的优缺点的无偏见信息。
办公室里的每个人都来自关系数据库背景（并且讨厌UniVerse）或者已经在这里待了很多年并且喜欢它。
我刚开始一份新工作，我将不得不用多值数据库（UniVerse）做大量的工作。我所拥有的小数据库经验是关系数据库（SqlServer），我正在寻找一些关于MVD与关系数据库的优缺点的无偏见信息。
办公室里的每个人都来自关系数据库背景（并且讨厌UniVerse）或者已经在这里待了很多年并且喜欢它。
首先，免责声明。我和UniData（UniVerse的姐妹DB）偶尔合作 博客就可以了所以我不能声称完全不偏不倚;不过，我会试试。
以下是您的一些考虑因素：
SQL DB和Multivalue DB之间的一个很大区别是MVDB不遵守 1NF。这有利有弊。它可能（并且通常是）被滥用，但有时它可能非常有用。最大的好处是，它意味着您并不总是需要一个可以更快地进行某些查询的连接表。
与常规SQL DB相比，它以完全新颖的方式存储元数据。每个文件/表都没有具体的架构。相反，它有一个或多个“字典”文件，它们由记录组成，告诉您如何解释数据。这使您不仅可以存储多个数据解释（原始/大写/小写，组合字段等），还允许您执行等效的枚举和连接。有可能 如果做得对，那就非常强大。
遗憾的是，虽然这个概念有很大潜力，但缺乏DBMS的工具集。开发受到驱动，但是一小部分业务案例似乎是由现有的和老化的软件系统的“保持开启”的心态驱动的。虽然它有集成工具（例如.NET连接器，SQL查询的ODBC接口等），但它们确实存在问题。例如，UniObjects .NET界面缺乏任何安全性（基本上全部或全部）。
它不仅仅是一个DBMS，而且本质上是一个完整的应用程序平台。尽管UniBasic并不像基于.NET的语言那样强大，但它确实胜过了T-SQL，并且可以快速转出业务规则。
首先，免责声明。我和UniData（UniVerse的姐妹DB）偶尔合作 博客就可以了所以我不能声称完全不偏不倚;不过，我会试试。
以下是您的一些考虑因素：
SQL DB和Multivalue DB之间的一个很大区别是MVDB不遵守 1NF。这有利有弊。它可能（并且通常是）被滥用，但有时它可能非常有用。最大的好处是，它意味着您并不总是需要一个可以更快地进行某些查询的连接表。
与常规SQL DB相比，它以完全新颖的方式存储元数据。每个文件/表都没有具体的架构。相反，它有一个或多个“字典”文件，它们由记录组成，告诉您如何解释数据。这使您不仅可以存储多个数据解释（原始/大写/小写，组合字段等），还允许您执行等效的枚举和连接。有可能 如果做得对，那就非常强大。
遗憾的是，虽然这个概念有很大潜力，但缺乏DBMS的工具集。开发受到驱动，但是一小部分业务案例似乎是由现有的和老化的软件系统的“保持开启”的心态驱动的。虽然它有集成工具（例如.NET连接器，SQL查询的ODBC接口等），但它们确实存在问题。例如，UniObjects .NET界面缺乏任何安全性（基本上全部或全部）。
它不仅仅是一个DBMS，而且本质上是一个完整的应用程序平台。尽管UniBasic并不像基于.NET的语言那样强大，但它确实胜过了T-SQL，并且可以快速转出业务规则。
正如Dave建议的那样，当您知道要检索的记录的密钥时，MV数据库的设计最佳。有些人将它们称为基于记录的数据库系统，而不是SQL，它是基于集合的数据库系统。
这实际上取决于您要做什么，如何构建数据以及您可以使用的其他工具。我大部分时间都在MV（Revelation产品，大部分时间）工作，我们定期处理10,000,000+的记录集，速度很快。
MV数据库强度是数据流动的时候。我们发现大多数客户将其用于法律，医疗和金融产品等应用;关系复杂且可能随着时间的推移而迅速且剧烈变化的应用程序。
您可能希望查看无SQL运动，它共享许多相同的概念，即使MV和没有SQL真的不是同一个东西。
MV的主要缺点在于它的结构，而不是它的工具。您通常会发现，由于开发人员基础较小，因此可用的工具包和帮助较小。您可能还会发现大多数产品为您提供的嵌入式基本语言缺少您习惯使用的对象样式编码。有时甚至JavaScript似乎都有更多的功能作为一种语言。
话虽如此，由于MV数据库主要是巨型字符串，因此语言的字符串处理非常好。它们非常适合直接操作HTML和XML字符串。
我想我有一个大问题，那你有具体问题吗？我不会打开一场战争，说它就像从Windows迁移到Linux或Mac，甚至从Debian迁移到Red Hat，但结构和系统是不同的，因此它们有不同的概念，优势，局限和目的。如果你尝试处理像SQL这样的MV数据库（你可以），你会发现它不是最合适的。设计糟糕的MV数据库可能是一种挫败感。精心设计的MV数据库可以是美丽的东西。
众所周知，MV数据库可以从相对低功耗的服务器中挤出出色的性能。
他们使用链接哈希文件系统，将大多数文件访问操作减少到数学运算，并在记录密钥已知时读取单个磁盘。在正确配置的系统中，只要记录密钥已知，从具有1,000,000,000条记录的文件中读取的时间不会超过具有1,000条记录的文件。
记录密钥需要是唯一的，并且在可以通过算法或编程方式确定记录密钥的应用程序中，数据库访问所涉及的开销可以是最小的。但是，当然，这通常涉及以可能不被视为“关系”的方式访问数据库。
这样没有任何利弊 - 他们只是简单地使用不同的方法来存储价值。 UniVerse使用分隔符来分隔值（IIRC使用char（254）和char（253）来分割字段中的多个值，并使用char（255）来分隔数据文件中的实际记录。我可能是错的虽然 - 自从我上次使用它已经超过10年了）。有些人喜欢这种存储数据的方法，就像有些人更喜欢老式汽车而非模型，或者有些人更喜欢使用马车而不是现代汽车。 （当然这只是我的意见）。
在字段中存储多个值意味着您没有SQLServer将使用的额外表，您实际上具有一定程度的非规范化。如果使用原生与UniVerse一起使用的技术（我们曾经使用称为CueBIC的窗口系统），使用这些多值都很容易，但是当从另一种语言（如C ++或VB）连接到数据库时它就是一个PITA - 然后你必须阅读记录并自己分离出值。这意味着搜索这些多值也很困难。
但话说回来，也许事情已经发生了变化，因为我上次使用它，也许有人编写了一个很好的驱动程序，因此您可以轻松地从.Net平台与UniVerse进行交互。我希望他们有你的缘故。
缩放到文件中的大量项目（记录）效果很好。缩放到记录中的大量值或子值会产生性能问题。应用程序设计需要对限制值和子值列表敏感，低于几个1000的阈值。
字符串处理非常好。和整数处理一样。 MV Basic语言是松散类型的，所以不要期望编译器有太多的强制执行。也就是说，由于MV Basic源项与任何其他数据一样，编译器只是数据库环境中的另一个动词，因此编写代码生成器和预编译器是一件轻而易举的事。这是在应用程序下构建工具层的良好环境。