PostGIS in Action
About the Authors
Consulting
Sunday, December 11. 2011The Relational Model is very much alivePrinter FriendlyRecommended Books: SQL and Relational Theory: How to write accurate SQL code SQL Pocket guide
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I totally agree!
People tend to present their experience as the only way to go, as the absolute truth. I think that if all the people complaining at the article had to store some real data with some huge size and complexity will had not commented at all.
I personally think that NoSQL is to solve only a limited domain of problems. Like for example www sites with clear, simple data structure (I'm not talking about volume) - social www belong to that group too in my opinion.
In data-centric systems, with huge data volumes, requirements regarding data analysis/mining/reporting, with many very high maintenance SLA-requirements SQL and RDBMS prooved to be extremally powerful. And one more thing - SQL has been worked-out for 40 years by really smart scientists - what about NoSQL ?
I don't think the misunderstand was just about what you meant by "pure", but also what you meant by "dead". If by "dead" you mean that none of the database software out there is strictly a pure relational database engine, then sure.
However, you yourself pointed out that many people (developers) think of and use the "non-pure" relational database software as though it is pure, so in practice, there are many databases (even if not database engines) that ARE pure relational databases. From that perspective, relational databases are thriving, not dead.
I was one of those who objected, and let the authors' have the last word; I shut up. Subsequently, I formulated a clearer response, but let it go. Then this new posting showed up. So I'll offer up the alternate articulation.
First, I disagree with Date with regard to "complex" datatypes, both logically and practically. He wrote the 8th clearly in an attempt to sidle his way into "alternate" DB zealots' minds, and when legacy storage was still all there was. I feel he failed both his existing adherents and failed to get the NoSql (not yet so named at the time of writing) folks into the RM camp. He also suggested that we drop ACID; really, he did. I fully support the notion of User Defined Scalar types. Nothing wrong with that at all. Read Pascal. He makes a succinct case that the RM supports complex types as just high NF schemas. And he's right. That's the objection. Folks take the seemingly easy way out by stuffing bytes into a column. The RM is the only math proven *data model*. All the others are post hoc justifications for stuffing bytes. And all were based on slow random access datastores. "What else can we do, random discs are tooooo slow". So they sacrificed data structure and integrity and flexibility and sharing and all the rest to implement *one* optimized data path. Fine for siloed applications. Not so fine for logic or shared data (recall the title of Codd's papers). The only justification for "complex" types is physical locality in storage. The same excuse for IMS and xml and Pick. And with hierarchical stores, you get *one and only one* optimal query path; some others become impossible. That was the Achilles' heel Codd saw. Changing the name from IMS to xml doesn't change that simple fact. With SSD as primary store, NF arguments no longer hold any water. SSD completely change the rules. Get used to it. As to search type datastores, let the Koder Kiddies have a good time. Such data isn't transactional, and wouldn't benefit much from the RM, unless it were highly duplicated (could be). |
Entry's LinksQuicksearchCalendar
Categories
SubscribeBlog Administration |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
