4 ms·

Shrug. Oracle suffers from problems that you don't get on your z/OS running IMS on top of VSAM files (which by the way is hierarchical, not relational - which i

Shrug. Oracle suffers from problems that you don't get on your z/OS running IMS on top of VSAM files (which by the way is hierarchical, not relational - which is what your big ole bank will be using). Talking about the relational model and "sound mathematical underpinnings" is fine, but I've seen dozens.. hundreds?.. of production relational databases and they've all been monsters. Most have been partially or significantly denormalized for good/bad reasons. All have their own warts, usually significant. If people end up normalizing their MongoDB as the author suggests - Well I'd expect that. It's pretty rare to get your DB model right first time. Any thought that you can is probably tinged with madness. If you can have a good stab at it and iterate you're ahead. Plus if you've ever worked with a TPS (or TM/2PC) you'll know they're a nightmare. Any volume systems I've worked on dispensed with them and use a reconcile/compensate mechanism. MongoDB has gone down a replica/sharded model that focuses on Map/Reduce. How successful this is, well that's a different argument - but comparing it to an old-school big-iron mentality is a waste of time.

jacques_chester 13y ago
I think the main revelation in databases was the division of the world into OLTP and OLAP. So you keep your normalised schema for production and have a methodologically denormalised schema for reporting. Mind you, computer science courses generally don't teach OLAP -- stuff like dimensional modelling. My university didn't when I was there, though they've rolled it into a larger "Data Mining" course alongside MapReduce and friends.
- jwilliams 13y ago
  Agree. & this makes sense from an architectural perspective, since the demands of each domain are different. I was arguing from practical terms and my own experience. Even in established, DB-heavy, "we have hundreds of DBAs" organisations, you can't have a porcelain schema. It evolves over time, breaks, get optimised and de-optimised. The Oracle shops I've worked in don't have one schema, they'll have dozens. Usually because they can't shoehorn emerging requirements into the databases they have. Or because of project timelines. Or they need to be performance tuned in some special way, which in the case of Oracle could be considered a dark art. These orgs may have just one big data warehouse, but that becomes a dumping ground. It's possible to do your dimensional modelling (I worked on star schemas in the past, but that's about it) -- but it's a big ball of mud to try and weave together. Even then your OLAP is under-stress because it's got a lot of ground to cover. Usually they start out as marketing engines, but get co-opted into all sorts of things. The most common and troublesome is regulatory reporting. Once your data warehouse gets used for something like regulatory reporting you're a bit stuck as nobody wants to touch it. Then, because point to point integrations between the databases is brittle and cost-prohibitive -- they break the golden rule and take data out of the OLAP and put it back into the OLTP. I won't name names, but this is commonplace. SalesForce is one of the biggest Oracle DB users (I read biggest at one stage, but can't find the reference). Even then the SalesForce data model is so denormalised you could call it one big table[1]. I use MongoDB day-to-day and it's fit for purpose for what I do. That said, I'm not a rabid fan and an alternative/hybrid approach is always on the horizon. What I don't buy is the "the DB world has already solved all these problems", particularly when things like "relational integrity" and "two phase commit" get thrown in the mix - truth is there is plenty to be solved. [1] http://www.dbms2.com/2011/09/15/database-architecture-salesforce-com-force-com-and-database/ http://www.dbms2.com/2011/09/15/database-architecture-salesf...
  - jacques_chester 13y ago
    Does using a document store solve any of these problems, though?
    - jwilliams 13y ago
      In some limited ways. I don't think the technology and lines of approach are fully mature yet. I don't know any MongoDB users that I think would be better off on Oracle - especially for the reasons cited in the article. My own view is the critical pieces will converge. If I could have PostgreSQL with a greatly simplified replication/parallelisation solution I'd be a happy man. Equally if MongoDB could do a COUNT query in even double the time of psql. Or compress their keys. Or have fine-grained locking... (All of which I'm sure they will get to, just when). Maybe that's MongoDB 5, PostgreSQL 14, Rethink 3 - I've got no idea and I'm sure I'll look at them all. However, I'm not the guy rocking up to a MongoDB conference and coming away with the conclusion "Oracle had that in 1988".
      - gaius 13y ago
        Once you start adding all those features in, the performance you gained by not doing them evaporates. That is the lesson of MySQL. My argument is not that MongoDB users would be better off on Oracle. It's that Oracle users would not necessarily be better off on MongoDB, since Oracle actually does many things that the makers of MongoDB claim it can't. If MongoDB had been made by MS, everyone would call that "FUD"...
        jwilliams 13y ago
        So we stop trying? The contribution of MySQL to the world of databases is significant. If your intent is to rebut FUD, then statements like "But just remember that these kids think they’re solving problems that IBM (et al) solved quite literally before they were born in some cases" don't contribute. You're just meeting rhetoric with rhetoric.
        13y ago

jacques_chester 13y ago

I think the main revelation in databases was the division of the world into OLTP and OLAP. So you keep your normalised schema for production and have a methodologically denormalised schema for reporting. Mind you, computer science courses generally don't teach OLAP -- stuff like dimensional modelling. My university didn't when I was there, though they've rolled it into a larger "Data Mining" course alongside MapReduce and friends.

jwilliams 13y ago
Agree. & this makes sense from an architectural perspective, since the demands of each domain are different. I was arguing from practical terms and my own experience. Even in established, DB-heavy, "we have hundreds of DBAs" organisations, you can't have a porcelain schema. It evolves over time, breaks, get optimised and de-optimised. The Oracle shops I've worked in don't have one schema, they'll have dozens. Usually because they can't shoehorn emerging requirements into the databases they have. Or because of project timelines. Or they need to be performance tuned in some special way, which in the case of Oracle could be considered a dark art. These orgs may have just one big data warehouse, but that becomes a dumping ground. It's possible to do your dimensional modelling (I worked on star schemas in the past, but that's about it) -- but it's a big ball of mud to try and weave together. Even then your OLAP is under-stress because it's got a lot of ground to cover. Usually they start out as marketing engines, but get co-opted into all sorts of things. The most common and troublesome is regulatory reporting. Once your data warehouse gets used for something like regulatory reporting you're a bit stuck as nobody wants to touch it. Then, because point to point integrations between the databases is brittle and cost-prohibitive -- they break the golden rule and take data out of the OLAP and put it back into the OLTP. I won't name names, but this is commonplace. SalesForce is one of the biggest Oracle DB users (I read biggest at one stage, but can't find the reference). Even then the SalesForce data model is so denormalised you could call it one big table[1]. I use MongoDB day-to-day and it's fit for purpose for what I do. That said, I'm not a rabid fan and an alternative/hybrid approach is always on the horizon. What I don't buy is the "the DB world has already solved all these problems", particularly when things like "relational integrity" and "two phase commit" get thrown in the mix - truth is there is plenty to be solved. [1] http://www.dbms2.com/2011/09/15/database-architecture-salesforce-com-force-com-and-database/ http://www.dbms2.com/2011/09/15/database-architecture-salesf...
- jacques_chester 13y ago
  Does using a document store solve any of these problems, though?
  - jwilliams 13y ago
    In some limited ways. I don't think the technology and lines of approach are fully mature yet. I don't know any MongoDB users that I think would be better off on Oracle - especially for the reasons cited in the article. My own view is the critical pieces will converge. If I could have PostgreSQL with a greatly simplified replication/parallelisation solution I'd be a happy man. Equally if MongoDB could do a COUNT query in even double the time of psql. Or compress their keys. Or have fine-grained locking... (All of which I'm sure they will get to, just when). Maybe that's MongoDB 5, PostgreSQL 14, Rethink 3 - I've got no idea and I'm sure I'll look at them all. However, I'm not the guy rocking up to a MongoDB conference and coming away with the conclusion "Oracle had that in 1988".
    - gaius 13y ago
      Once you start adding all those features in, the performance you gained by not doing them evaporates. That is the lesson of MySQL. My argument is not that MongoDB users would be better off on Oracle. It's that Oracle users would not necessarily be better off on MongoDB, since Oracle actually does many things that the makers of MongoDB claim it can't. If MongoDB had been made by MS, everyone would call that "FUD"...
      - jwilliams 13y ago
        So we stop trying? The contribution of MySQL to the world of databases is significant. If your intent is to rebut FUD, then statements like "But just remember that these kids think they’re solving problems that IBM (et al) solved quite literally before they were born in some cases" don't contribute. You're just meeting rhetoric with rhetoric.
        13y ago