Jac*_*ope 12 universe relational-database multivalue-database
我刚开始一份新工作,我将不得不用多值数据库(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,并且可以快速转出业务规则.
小智 5
正如 Dave 所建议的那样，当您知道要检索的记录的关键字时，MV 数据库确实设计得最好。有些人将它们称为基于记录的数据库系统，而不是 SQL，后者是基于集合的数据库系统。
这实际上取决于您要尝试做什么、需要如何组织数据以及您有哪些其他可用工具。我大部分时间都在做MV（主要是Revelation产品），我们定期处理10,000,000+的记录集，速度很好。
MV 数据库的优势在于数据是流动的。我们发现我们的大多数客户将其用于法律、医疗和金融产品等应用；关系复杂并且可以随着时间的推移迅速而剧烈变化的应用程序。
您可能想要查看 no SQL 运动，它共享许多相同的概念，即使 MV 和 no SQL 实际上不是一回事。
MV 的主要缺点在于它的结构，而不是它的工具。您通常会发现，由于开发人员基础较小，因此可用的工具包和帮助较小。您可能还会发现大多数产品提供的嵌入式基本语言缺乏您习惯的对象样式编码。有时甚至 JavaScript 作为一种语言似乎具有更多的功能。
话虽如此，由于 MV 数据库主要是巨型字符串，因此语言的字符串处理非常出色。它们非常适合直接操作 HTML 和 XML 字符串。
我想我有一个大问题，你有具体的问题吗？我不会开战说这就像从 Windows 迁移到 Linux 或 Mac，甚至从 Debian 迁移到 Red Hat，但是结构和系统不同，因此它们具有不同的概念、优势、局限性和目的. 如果您尝试处理像 SQL 这样的 MV 数据库（您可以这样做），您会发现它不是最合适的。设计不当的 MV 数据库可能会让人感到沮丧。精心设计的 MV 数据库可以是一件美丽的事情。