chris wood wrote:
> At a detailed level (which is NOT the direction I want this thread to=20
> go) I do not agree with your statement that my proposal has no =93hope=20
> of ACID compliance or transactional integrity=94. When the =93slices=94 a=
re=20
> stored back to the cloud, this is the equivalent of a commit and the=20
> integrity thereof is as good as what ever the underlying technology=20
> is. Is the concurrency as good as native Postgres? Of course not. Is=20
> the commit/rollback flexibility as good as native Postgres? Again no.=20
> But what=92s the alternative? Watch cloud computing take off leaving=20
> Postgres with the reputation of =93great database software in=20
> yesterday=92s era of monolithic servers=94?
even something as simple as a SERIAL sequence would be a nightmare in a=20
distributed cloud environment without a complex centralized arbitrer.=20
the same goes for most any other sort of update/query that depends on=20
consistency of data.
How do you reconcile a bank account when the money has been=20
simultaneously withdrawn from several ATMs at different locations at the=20
same time? "Please, sir, give us our money back?" ? I don't think the=20
banks would be happy with that implementation.
If the data is partitioned across the cloud ('one version of the=20
truth'), things like JOINs are very very difficult to implement=20
efficiently. take away JOINs and you might as well be doing simple ISAM=20
like we did back in the 70s before Codd and his Relational Database=20
concepts upon which SQL is based.
no, IMHO, the cloud people are better off inventing their own data=20
models and their own proprietary query languages suited to the=20
architecture. maybe SQL and its concepts of 'one version of the truth'=20
and 'data integrity' are quaint relics of another age, so be it.
