什么时候不应该使用关系数据库?

除了google / bigtable场景,什么时候不应该使用关系数据库? 为什么不,你应该使用什么? (你学会了“艰难的路”吗?)

7 Solutions collect form web for “什么时候不应该使用关系数据库?”

根据我的经验,当这些条件中的任何一个为真时,您都不应该使用关系数据库:

  • 您的数据被构build为任意深度的层次结构或graphics(networking)
  • 典型的访问模式强调读写,或者
  • 不需要即席查询。

深层次结构和graphics不能很好地转换为关系表。 即使在诸如Oracle的CONNECT BY类的专有扩展的帮助下,使用SQL来追查树木也是非常痛苦的。

关系数据库为简单的读访问增加了很多开销。 事务和参照完整性是强大的,但对于某些应用程序来说是过度的。 所以对于大多数应用程序来说,一个文件隐喻就足够了。

最后,如果没有预料到的意外的查询,就不需要使用全面的查询语言的关系数据库。 如果没有人问我们“在销售人员组成的东海岸销售多less5%的蓝色小部件?”这样的问题,那么先生可以不用DB了。

关系数据库范式对数据的使用做了一些假设。

  • 一个关系由一组无序的行组成。
  • 关系中的所有行都具有相同的一组列。
  • 每列在所有行上都有固定的名称和数据types和语义含义。
  • 关系中的行由主键列中的唯一值标识。
  • 等等

这些假设支持简单和结构,但要以一定的灵活性为代价。 并不是所有的数据pipe理任务都适合这种结构。 例如,具有复杂属性或可变属性的实体不会。 如果您在关系数据库解决scheme不支持的领域需要灵活性,则需要使用其他types的解决scheme。

还有其他解决scheme用于pipe理具有不同要求的数据。 例如,语义Web技术允许每个实体定义自己的属性,并通过将元数据作为属性(如数据)进行自我描述。 这比关系型数据库所强加的结构更为灵活,但是这种灵活性带来了成本。

总体而言,您应该为每项工作使用正确的工具。

另见我对“ 下一代数据库 ” 的其他答案。

我build议你访问高可扩展性博客 ,它几乎每天讨论这个话题,并且有很多关于select分布式哈希等的项目的文章。

快速(但非常不完整的答案)是不是所有的数据都能高效地转换成表格。 例如,如果你的数据本质上是一个大的字典,那么可能有更快的select,那就是简单的旧的RDBMS。 话虽如此,它主要是一个性能问题,如果一个项目的性能不是一个大问题,而且例如稳定性,一致性和可靠性,那么当我研究这些技术的时候我并没有太多的意义RDBMS是一个更加成熟和发达的scheme,支持所有语言和平台,并提供了大量可供select的解决scheme。

有三个主要的数据模型(CJDate,EFCodd),我在这里添加一个平面文件:

  • 平面文件(结构不尽相同 – 从“愚蠢”的平面文本到符合语法的文件,再加上聪明的工具,聪明的事情,思考编译器和他们能做什么,狭窄的应用程序在build模新事物)
  • 层次结构 (树,嵌套集 – 例如:XML和其他标记语言,registry,组织结构图等等;任何东西都可以build模,但是完整性规则不容易expression,检索很难自动优化,一些检索是快速的,一些是非常慢 )
  • networking (networking,图表 – 例子:导航数据库,超链接,语义networking,几乎任何东西都可以build模,但自动优化检索是一个问题)
  • 关系 (一阶谓词逻辑 – 例子:关系数据库,自动优化检索)

分层和networking都可以用关系来表示,关系可以用另外两种来表示。

关系被认为是“更好”的原因不仅在于数据检索语言的声明性和标准化,还在于数据定义语言,包括强大的声明性数据完整性,以稳定 ,可扩展的多用户pipe理系统为后盾。

好处是以成本为代价的,大多数项目发现对于存储长期数据的系统(多应用程序)来说是一个很好的比例,在可预见的将来,这些数据将可用。

如果你不是build立一个系统,而是一个单一的应用程序,也许是一个用户,你可以肯定的是,你不会想要多个应用程序使用你的数据,也不需要多个用户,任何时候,你可能会发现更快的方法。

另外如果你不知道你想要存储什么样的数据以及如何build模,那么关系模型的优势就被浪费了。

或者,如果你根本不关心你的数据的完整性(这可以很好)。

所有的数据结构都是针对某种特定的用途进行优化的,只有在正确build模的情况下才能用关系来试图以语义无偏见的方式来表示“现实”。 对关系数据库有不好的经验的人通常不会意识到他们的经验在其他types的数据模型下会变得更糟。 可怕的实现是可能的,特别是在关系数据库中,build立复杂模型相对容易,最终可能会有相当大的怪物。 当我尝试在xml中想象相同的怪物时,我总是感觉好些。

关系模型(IMO)的好例子之一就是您会发现涉及SQL的问题的复杂性与简短性的比例。

十五年前,我正在研究一个信用风险系统(基本上是一个大树行走系统)。 我们在HPUX&solaris上使用Sybase,而执行力却让我们失望。 我们直接从Sybase的顾问那里聘请了他们说不能做的事情。 然后,我们切换到一个面向对象的数据库(在这种情况下是对象存储),性能提高了大约100倍(代码大概也是100倍)

但是这种情况是非常罕见的 – 关系数据库是一个很好的首选。

当你的模式变化很多时,你将会遇到关系型数据库的困难。 这是XML数据库或键值对数据库工作得最好的地方。 或者您可以使用IBM DB2,同时具有由单个数据库引擎pipe理的关系数据和XML数据。

大约7-8年前,我曾经在一个超出我们最初期望的网站上工作,这让我们在性能方面遇到了麻烦。 由于我们在基于networking的项目方面都比较缺乏经验,这使我们对通常的数据库分离到单独的服务器,负载平衡等方面做了很大的努力。

有一天我想到了一些非常简单的事情。 由于网站是基于用户,他们的configuration文件被存储在数据库表中通常的方式有人会这样做 – 用户ID,大量的信息variables和类似的东西 – 这将显示为用户configuration文件页面,其他用户可以查找。 我已经把所有的数据刷新成一个简单的html文件,已经准备好了一个用户configuration文件页面,并获得了显着的提升 – 基本上是一个caching。 我甚至做了一个系统,当用户编辑他们的个人资料信息,它将parsing原始的HTML文件,把它编辑,然后刷出HTML回文件系统 – 得到更多的提升。

我做了一些与用户发送给对方的消息相似的东西。 基本上,只要我能让一个系统完全绕过一个数据库,避免一个INSERT或UPDATE,我就可以得到很大的提升。 这听起来可能是常识,但这是一个启发性的时刻。 这不是避免关系设置本身,而是完全避免数据库 – KISS。

  • 数据库中的2个字段的SQL不同
  • 如何创build一个MySQL分层recursion查询
  • SQL查询将列数据拆分成行
  • SQL Server Management Studio - 添加外键混淆?
  • Rails的范围是不是空的,不是空的/空的?
  • 我得到错误“DELETE语句与参考约束冲突”
  • 在MySQL中获取表列名称?
  • SQLite3不支持外键约束吗?
  • 什么是SQL(语言)的好替代品?
  • 将数据从SQL Server Express导出为CSV(需要引用和转义)
  • 在存储过程参数列表中使用expression式的结果(例如函数调用)?