I'm not a historian, and I acknowledge that a better theory can be ruined by a crappy implementation but what I've noticed over the past 2.5 years hanging around a mainframe hierarchical db is that it takes a COBOL programmer and hours, weeks or months for questions/changes like the ones below to be dealt with:
1. Can I get the structure of the database? 2. Can I get a copy of the data in this table? 3. Can we increase the size of this column by 5 chars? 4. Can we increase the number of addresses we can store? 5. Can we find out what the distinct values of this col are in this table? 6. Can you tell me how many customers we have which own <this product>? Obviously each of these things can be done in seconds in SQL and with freely available inexpensive tooling. We also have issues with data quality. Lack of constraints and foreign keys... it catches up with you after 20 years of data collection :). I'm in the process of reading the Amazon Dynamo paper, very interesting, but it strikes me again that its a very, very specific type of problem, something that isn't appropriate for a vast number of businesses who process data. (Just as a RDBMS isn't appropriate for Amazon). On Jul 20, 7:10 am, kirk <[email protected]> wrote: > Steven Herod wrote: > > I think you might be overlooking how revolutionary SQL/Relational > > storage is compared to what came before it. > > like hierarchical and network databases? > > Seriously, of the 3 types of databases.. network was by far the best but > least understood by decision makers so we're stuck with Relational. > > Regards, > Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
