I thought this article was really good at explaining the differences of
relational DBs and Key/Value stores and some other models coming down
the pipe (i.e. the new buzzword "Cloud Computing").
http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php
Well, no, it's not doomed.
It seems that the author is mistaken a -logical- thingy ("relational")
with a -physical- thingy ("performance").
It's the logic that makes the RDBMS so capable, not the performance.
The performance of the first RBDMSses was incredibly bad, yet, they
were still being pushed forward and in the end the hardware and its
implementations caught up to get things to an "acceptable" performance
level. However, this has nothing to do with the logical concept, that is
the RDBMS.
To point out "issues" with the article:
- although many of todays implementations use SQL as the "language"
to get and put data, this has nothing to do with the RDBMS itself.
- As a "feature" of the key/value database it is mentioned that data
integrity logic is contained in the application code! This is something
many were glad to leave behind when the RDBMS came along! This
is not a step forward, it is a step backward.
- APIs have nothing to do with the RDBMS itself, so there's nothing
to "pro" and "con" here.
- "data storage", once more, is NOT a feature of the RDBMS, so
it has nothing to do with "application code structure".
Luckily, some of the drawbacks of the "key/value database" are
mentioned.
Yet, I fail to see how this type of "data storage" could make it into
the mainstream. The database implementation cannot guarantee
it's integrity, so what use is it?
Under "Making a decision", the article says the following as to why
you should choose a non-relation database implementation:
1) Your data is heavily document-oriented, making it a more natural
fit with the key/value data model than the relational data model.
Say what now?
2) Your development environment is heavily object-oriented, and a
key/value database could minimize the need for "plumbing" code.
It should be about the data, not about the coding. There are plenty
of frameworks that can do the "plumbing" for you and you can keep
your working, integrity checking RDBMS...
3) The data store is cheap and integrates easily with your vendor's
web services platform.
I fail to see why "web services" rules out RDBMS?
4) Your foremost concern is on-demand, high-end scalability -- that is,
large-scale, distributed scalability, the kind that can't be achieved
simply
by scaling up.
Why do you actually -store- the data if its not your main concern?
Yes, I can imagine some "fuzzy" data storage, like Google returning
"about 4,343,400 documents" instead of an exact number, but ... Can
you give me more examples?
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!
Database questions? Check the forum:
http://www.databasedevelopmentforum.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
