4 ms·
This seems oversimplified to me. When I think "database" I think of ACID properties. You can have SQL without ACID, and you can have ACID properties without SQL
by mblakele 17y ago
This seems oversimplified to me. When I think "database" I think of ACID properties. You can have SQL without ACID, and you can have ACID properties without SQL.
- evgen 17y agoThe problem with this simplification os the problem-space is that ACID properties cannot be maintained (see CAP) when you start moving to a distributed model. The "no SQL" group is just using it as a catchy hook upon which to hang their hat, it is not SQL per se but the traditional RDBMS that is reaching its limits, but it was hard to make a memorable name that included "RDBMS" :)
- gaius 17y agoACID properties cannot be maintained (see CAP) when you start moving to a distributed model. You need to pop back to the 1960s and tell IBM that before they wrote TPF.
- mblakele 17y agoI think SQL has its limits too, for example in hierarchical use cases. While it is possible to write extremely complicated CONNECT BY clauses in SQL, I would prefer XPath and XQuery for that job.
- neilc 17y agoThe problem with this simplification os the problem-space is that ACID properties cannot be maintained (see CAP) when you start moving to a distributed model. That assumes you need the system to remain available in the presence of partitions. How often is that really true?
- petern 17y agoFully agree. look at graph databases like Neo4j, which has ACID semantics but no SQL interface. Then, IMHO SQL is not only geared towards a special RDBMS type of underlying database but even against a special problem domain that is not always applicable, leading to query languages like SparQL.