Hi Steven, Just got back from vacation and this thread jumped out at me and maybe I jumped in a bit early. Now that I've read more of the discussion....
I'm not a historian also but my experience with hierarchical is that they were limiting in what you could model with them. This wasn't a problem with network dbs. The problems you've pointed out with hierarchical I've not found with network db. But then my experiences with them are limited and fairly old. I'll focus on the tooling thing 'cos I think that it's the most important mention in your response. I worked with OO databases for a number of years, first as a user and then as an employee of GemStone. When I first ran into them the project rejected them because of the schema migration problem (object versioning). It appears that RDBMS gives you a huge win with schema migration even though it suffers from the same problem. One of the big differences is, the data model has been abstracted away from the code (anti-OO). This allows DBA's to be draconian in allowing changes to the db schema without affecting app developers too seriously most of the time. Investment in RDB tooling is such that schema migrations are less painful. OODB didn't have the time to get these tools into the market place and they seriously needed them as restricting schema in OO is a serious restriction to place on the developers. Obviously Hierarchical and Network technologies suffered from the same lack of funding as investment in relational sucked up all the capital. The other comment that struck a cord was one in the initial email suggesting that in order to make a DB scale one had to front it with a big cache. This was suggested to be an indication of a problem. I'm not sure that I agree that it's an indication of a problem to the point where we need to throw the baby out with the bath water. After all, caching is used every where you'd like to short-circuit a call path. Think CPU cache short-circuiting a call to memory. What it does suggest is that we need to seriously think about how we are using the technology and recognizing that the A in ACID equates to a big fat lock that using current practices results in *every* thread in your system.. in your cluster... in your server farm pass through it. If we want to increase concurrency in our systems, adding a big fat lock that every thread must pass through doesn't seem like a wise thing to do. However, just as RAM is still useful, so it relational persistence technology. We just need to learn how to use it to build the types of systems we are building today, not the ones that we built yesterday. Regards, Kirk Steven Herod wrote: > 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 -~----------~----~----~----~------~----~------~--~---
