Guess you've never heard of MVCC? On Mon, Jul 20, 2009 at 1:05 AM, kirk<kirk.pepperd...@gmail.com> 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 <kirk.pepperd...@gmail.com> 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
