Am I missing something? Postgresql, MS SQL Server, H2, MySQL/InnoDB, Oracle, and even CouchDB - *ALL* use MVCC to implement transactions.
That's easily over 90% of all transactional db usage in the world. http://en.wikipedia.org/wiki/Multiversion_concurrency_control On Jul 23, 8:39 am, kirk <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
