Alex Turner wrote: > Guess you've never heard of MVCC? > I have. but putting it into practice is a wee bit difficult. You typically end up with a big "point in time" abstraction mess.
Regards, Kirk > On Mon, Jul 20, 2009 at 1:05 AM, kirk<[email protected]> wrote: > >> 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 -~----------~----~----~----~------~----~------~--~---
