当前位置:  开发笔记 > 编程语言 > 正文

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

如何解决《什么时候不应该使用关系数据库?》经验,为你挑选了6个好方法。

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



1> yukondude..:

根据我的经验,当满足以下任何一个标准时,您不应使用关系数据库:

您的数据被构造为任意深度的层次结构或图形(网络),

典型的访问模式强调阅读而不是写作,或

不需要临时查询.

深层次结构和图形不能很好地转换为关系表.即使在像Oracle这样的专有扩展的帮助下CONNECT BY,追逐树也是使用SQL的巨大痛苦.

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

最后,如果没有预期的意外查询,您根本不需要具有完整查询语言的关系数据库.如果没有西装问过"我们在东海岸按销售人员分组销售了多少5% - 折叠的蓝色小部件?"这样的问题,那么从来没有,那么,先生,您可以免于使用DB.


层次结构没有任何冲突.这正是与1:m关系的JOIN.为什么不应该仅仅因为你强调阅读而不是写作而使用RDBMS?这是99%的网站.同上"没有临时查询".这个答案是完全错误的.这三点都错了.它甚至没有按要求提供任何建议的替代方案.它获得10票加上接受?看起来像是一个设置问题.
le dorfier:1.层次结构是1:m*reflexive*relationship,它们很容易JOIN以找到下一个级别,但不能连接到任意深度.2.的确,大多数只读网站都使用RDBMS,但同样,参照完整性和事务一致性对于只读使用几乎没有用.3.临时查询是关系理论存在的原因 - 回顾你的EF Codd.对不起,不是设置.事实上,我非常相信RDBMS的强大功能,并教授使用它们的课程,但必须掌握任何技术的局限性.
@le dorfier - 仅仅因为"所有其他网站都在做"并不意味着它是最佳的.我打赌99%的99%你提到使用RDBMS因为他们不知道其他任何东西.
即使在关系数据库中,嵌套集也不会很好用吗?http://en.wikipedia.org/wiki/Nested_set_model

2> Bill Karwin..:

关系数据库范例对数据的使用做出了一些假设.

关系由一组无序行组成.

关系中的所有行都具有相同的列集.

每列在所有行上都具有固定的名称和数据类型以及语义含义.

关系中的行由主键列中的唯一值标识.

等等

这些假设支持简单性和结构,但代价是具有一定的灵活性.并非所有数据管理任务都适合这种结构.例如,具有复杂属性或变量属性的实体不会.如果在关系数据库解决方案不支持的领域需要灵活性,则需要使用不同类型的解决方案.

还有其他解决方案来管理具有不同要求的数据.例如,语义Web技术允许每个实体定义自己的属性并自我描述,方法是将元数据视为属性,就像数据一样.这比关系数据库强加的结构更灵活,但这种灵活性需要自己的成本.

总的来说,您应该为每项工作使用正确的工具.

另见我对" 下一代数据库 " 的其他答案.



3> Unreason..:

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

平面文件(结构各不相同 - 从'愚蠢'的平面文本到符合语法的文件,再加上聪明的工具做非常聪明的事情,想想编译器及他们能做什么,缩小应用程序来建模新东西)

层次结构(树,嵌套集 - 示例:xml和其他标记语言,注册表,组织结构图等;任何事物都可以建模,但完整性规则不易表达,检索很难自动优化,有些检索很快,有些是非常慢 )

网络(网络,图形 - 例子:导航数据库,超链接,语义网,几乎任何东西都可以建模,但自动优化检索是一个问题)

关系(一阶谓词逻辑 - 例子:关系数据库,检索的自动优化)

层次结构和网络都可以表示为关系,关系可以表示为另外两个.

关系被认为是"更好"的原因是不仅是数据检索语言而且还有数据定义语言的声明性和标准化,包括强大的声明性数据完整性,备份有稳定,可扩展的多用户管理系统.

好处是有代价的,大多数项目都认为这是一个很好的系统(多应用程序)比率,可以将长期数据存储在可预见的未来可用的系统中.

如果您不是在构建系统,而是单个应用程序(可能是针对单个用户),并且您确信不希望多个应用程序使用您的数据,也不希望多个用户,那么您很快就会找到更快的方法.

此外,如果您不知道要存储哪种数据以及如何对其进行建模,那么就会浪费关系模型的优势.

或者,如果您根本不关心数据的完整性(可能没问题).

所有数据结构都针对某种用途进行了优化,只有正确建模的关系试图以语义无偏的方式表示"现实".对关系数据库有不良经验的人通常没有意识到他们的经验会因其他类型的数据模型而变得更糟.可怕的实现是可能的,特别是在关系数据库中,构建复杂模型相对容易,你最终可能会遇到很多怪物.当我试图想象xml中的同一个怪物时,我总是感觉更好.

关于良好关系模型的一个例子,IMO,是您将发现涉及SQL的问题的复杂性与简短性的比率.



4> Assaf Lavie..:

我建议你访问High Scalability博客,该博客几乎每天都会讨论这个主题,并且有很多关于通过RDMBS选择分布式哈希等项目的文章.

快速(但非常不完整的答案)是,并非所有数据都能以有效的方式很好地转换为表格.例如,如果您的数据本质上是一个大字典,则可能有更快的替代方法,即普通的旧RDBMS.话虽如此,它主要是性能问题,如果性能不是项目中的一个大问题,例如稳定性,一致性和可靠性,那么我在研究这些技术时看不到多少意义. RDBMS是一个更加成熟和完善的方案,支持所有语言和平台,并提供大量可供选择的解决方案.



5> 小智..:

十五年前,我正在研究信用风险系统(基本上是一个大树行走系统).我们在HPUX和solaris上使用Sybase,而性能正在使我们失望.我们直接聘请了Sybase的顾问,他们表示无法完成.然后我们切换到OO数据库(在这种情况下是对象存储)并且性能提高了大约100倍(并且代码也大约100倍更容易编写)

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



6> 小智..:

当架构变化很大时,您将很难使用关系数据库.这是XML数据库或键值对数据库最佳工作的地方.或者您可以使用IBM DB2并同时拥有由单个数据库引擎管理的关系数据和XML数据.

推荐阅读
臭小子
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有