When shouldn't you use a relational database?

 

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.

    The relational database paradigm makes some assumptions about usage of data.

  • A relation consists of an unordered set of rows.
  • All rows in a relation have the same set of columns.
  • Each column has a fixed name and data type and semantic meaning on all rows.
  • Rows in a relation are identified by unique values in primary key column(s).
  • etc.

    • These assumptions support simplicity and structure, at the cost of some flexibility. Not all data management tasks fit into this kind of structure. Entities with complex attributes or variable attributes do not, for instance. If you need flexibility in areas where a relational database solution doesn't support it, you need to use a different kind of solution.

    There are other solutions for managing data with different requirements. Semantic Web technology, for example, allows each entity to define its own attributes and to be self-describing, by treating metadata as attributes just like data. This is more flexible than the structure imposed by a relational database, but that flexibility comes with a cost of its own.

    Overall, you should use the right tool for each job.

    See also my other answer to "The Next-gen databases."

    I suggest you visit the High Scalability blog, which discusses this topic almost on a daily basis and has many articles about projects that chose distributed hashes, etc. over RDMBS.

    The quick (but very incomplete answer) is that not all data translates well to tables in efficient ways. For example, if your data is essentially one big dictionary, there are probably much faster alternatives that plain old RDBMS. Having said that, it mostly a matter of performance, and if performance isn't a huge concern in a project, and stability, consistency and reliability, for example, are, then I don't see much point in delving into these technologies when RDBMS is a much more mature and well developed scheme, with support in all languages and platforms and a huge set of solutions to choose from.

    链接地址: http://www.djcxy.com/p/93872.html

    上一篇: 什么类型的NoSQL数据库最适合存储分层数据？

    下一篇: 什么时候不应该使用关系数据库？