什么时候不应该使用关系数据库？ [英] When shouldn't you use a relational database?

问题描述

除了google / bigtable方案之外，什么时候不应该使用关系数据库？为什么不呢？您应该使用什么呢？ （您学习过艰难的方式吗？）

解决方案

根据我的经验，您不应在任何时候使用关系数据库这些条件之一是正确的：

• 您的数据被构造为任意深度的层次结构或图形（网络），


• 典型的访问模式着重于阅读而不是书写，或者


• 对即席查询没有要求。

深层次结构和图形不能很好地转换为关系表。即使借助Oracle的 CONNECT BY 之类的专有扩展，使用SQL追逐树也是一个巨大的痛苦。

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

最后，如果有关系数据库，则无需使用具有完善查询语言的关系数据库没有意外的查询。如果没有人问在销售员分组的东海岸我们卖多少个5％折扣的蓝色小部件？之类的问题，那么永远不会有，先生，您可以免费居住。 p>

Apart from the google/bigtable scenario, when shouldn't you use a relational database? Why not, and what should you use? (did you learn 'the hard way'?)

解决方案

In my experience, you shouldn't use a relational database when any one of these criteria are true:

• your data is structured as a hierarchy or a graph (network) of arbitrary depth,
• the typical access pattern emphasizes reading over writing, or
• there’s no requirement for ad-hoc queries.

Deep hierarchies and graphs do not translate well to relational tables. Even with the assistance of proprietary extensions like Oracle's CONNECT BY, chasing down trees is a mighty pain using SQL.

Relational databases add a lot of overhead for simple read access. Transactional and referential integrity are powerful, but overkill for some applications. So for read-mostly applications, a file metaphor is good enough.

Finally, you simply don’t need a relational database with its full-blown query language if there are no unexpected queries anticipated. If there are no suits asking questions like "how many 5%-discounted blue widgets did we sell in on the east coast grouped by salesperson?", and there never will be, then you, sir, can live free of DB.

这篇关于什么时候不应该使用关系数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！