normalization != bad performance (was: Relational-to-OOP Tax)
in [OOP]
|
From: Thomas Gagne on 27 Feb 2007 08:03 Jerry Coffin wrote: > <snip> > > The relational model is a bit like the ISO 7-layer model for networks. > Each makes a great reference model and in theory, each should work > perfectly well. OTOH, real implementations of either are few and far > between. The few that do make the attempt all share one characteristic: > stunningly awful performance. > Sorry, can't let that one go. <http://gagne.homedns.org/~tgagne/articles/myth.html> Of course, I've not designed a database past 3NF. I have found opportunities to denormalize but have decided it is better to have both normalized and denormalized than just the latter. When you have both then the latter becomes derived data which can wholly be recreated if the need arises. -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
From: frebe on 27 Feb 2007 08:22 > I have found > opportunities to denormalize but have decided it is better to have both > normalized and denormalized than just the latter. When you have both > then the latter becomes derived data which can wholly be recreated if > the need arises. Another benefit is that doing this, no existing SQL statements are broken. If you find it necessary to denormalize some tables, you still keep the original normalized tables. Addning tables will never break any existing code. /Fredrik
From: Jerry Coffin on 27 Feb 2007 09:50 In article <CpydnTUKeJGdsXnYnZ2dnUVZ_uygnZ2d(a)wideopenwest.com>, tgagne(a)wide-open-west.com says... > Jerry Coffin wrote: > > <snip> > > > > The relational model is a bit like the ISO 7-layer model for networks. > > Each makes a great reference model and in theory, each should work > > perfectly well. OTOH, real implementations of either are few and far > > between. The few that do make the attempt all share one characteristic: > > stunningly awful performance. > > > Sorry, can't let that one go. > > <http://gagne.homedns.org/~tgagne/articles/myth.html> > > Of course, I've not designed a database past 3NF. I have found > opportunities to denormalize but have decided it is better to have both > normalized and denormalized than just the latter. When you have both > then the latter becomes derived data which can wholly be recreated if > the need arises. You seem to have misunderstood what I said -- I wasn't talking about normalized vs. denormalized data. I was talking about how closely database management systems attempt to follow the relational model. A typical SQL DBMS requires _drastically_ faster hardware than a hierarchical database to provide even roughly equivalent response time -- to the point that a SQL DBMS running on current hardware is about the same speed (or slighthly slower) than a hierarchical database was around 25 years ago, running on hardware that was current at the time. As far as normalization goes: back then, normalization was a way of life -- normalization reduces redundancy, and given the cost of storage at the time, redundancy was _expensive_ (even ignoring inflation, one month's rent on a 1.8 GB disk drive in 1982 would buy enough disks for quite a large RAID today). -- Later, Jerry. The universe is a figment of its own imagination.
From: Daniel Parker on 27 Feb 2007 10:28 On Feb 27, 9:50 am, Jerry Coffin <jcof...(a)taeus.com> wrote: > > A typical SQL DBMS requires _drastically_ faster hardware than a > hierarchical database to provide even roughly equivalent response time > -- to the point that a SQL DBMS running on current hardware is about the > same speed (or slighthly slower) than a hierarchical database was around > 25 years ago, running on hardware that was current at the time. > Which makes it all the more impressive that the RDBMS essentially wiped out the hierarchical and network databases as living, growing entities around the mid 1980's, when network speeds and CPU speeds were much slower :-) And pre-empted OO databases, so that they never even became a contender. Wouldn't you agree? Can you think why that might have been the case? Even though, at the time, they were unquestionably slower? But I don't believe that your statement is true. I haven't had the pleasure of working much with CODASYL or IMS databases, but my limited exposure doesn't suggest that it's true, in general. In terms of my own experience, I think I can safely say that accessing Btrieve indexed records through C++ applications on latter eighties era hardware is definitely slower than doing something comparable with MS SQL Server on a modern PC network, by a lot, actually. Are you even referring to data management systems that support transactioning and service multiple concurrent requests for data over a wire? Is there any evidence that you can point to that would suggest you are not just making this up out of whole cloth? Regards, Daniel
From: Jerry Coffin on 28 Feb 2007 01:34 In article <1172590106.600924.157810(a)p10g2000cwp.googlegroups.com>, danielaparker(a)gmail.com says... [ ... ] > Which makes it all the more impressive that the RDBMS essentially > wiped out the hierarchical and network databases as living, growing > entities around the mid 1980's, when network speeds and CPU speeds > were much slower :-) It's not really all that impressive when you consider how much/most of it happened. For example, IBM was one of the biggest vendors at the time. At that time, most software (and hardware) was not bought, but rented -- when IBM decided you were going to switch, the old software simply ceased to be available. As to why they'd do this: at the time, most software was sold by hardware vendors, who benefited tremendously by selling the least efficient software people would buy. Don't get me wrong: for some purposes, relational databases have real advantages -- but for most people, most of the time, the advantages are minimal and the disadvantages substantial. > And pre-empted OO databases, so that they never > even became a contender. Wouldn't you agree? Can you think why that > might have been the case? Even though, at the time, they were > unquestionably slower? See above. > But I don't believe that your statement is true. I haven't had the > pleasure of working much with CODASYL or IMS databases, but my limited > exposure doesn't suggest that it's true, in general. Then your exposure is very limited indeed. > In terms of my > own experience, I think I can safely say that accessing Btrieve > indexed records through C++ applications on latter eighties era > hardware is definitely slower than doing something comparable with MS > SQL Server on a modern PC network, by a lot, actually. That's not quite the comparison I was making. I've had a _tiny_ bit of exposure to Btrieve, but not enough to comment on it with any great intelligence. > Are you even referring to data management systems that support > transactioning and service multiple concurrent requests for data over > a wire? Yes, of course. Keep in mind that at the time (at least on the machines I'm talking about) the idea of _anything_ being single-user was entirely foreign. These were mainframes that occupied a large room, used several tons of air conditioning equipment, and generally had about three or four full-time computer operators. There may have been times that all of that was devoted to a single user, but it had to be a rarity if it happened at all. > Is there any evidence that you can point to that would > suggest you are not just making this up out of whole cloth? Sure -- quite a bit of it. Look at just about any journal that covered databases on mainframes from the late '70s or early '80s or so. Here are a couple of more recent papers: http://nms.csail.mit.edu/~stavros/pubs/osfa.pdf M. Stonebraker and U. Cetintemel. ?One Size Fits All: An Idea Whose Time has Come and Gone?. In Proceedings of the International Conference on Data Engineering (ICDE), 2005. In the hierarchical area, there are quite a few benchmarks, but they generally don't compare themselves to RDBMSs -- the more common comparison is to the raw bandwidth of the disks, or other known bottleneck. Also note that the difference between a hierarchical databse and a file system tends to be more one of viewpoint than anything else; as such, it's likely many of these, at least in places, more or less equate the two. http://www.hdfgroup.org/HDF5/RD100-2002/HDF5_Performance.pdf http://hdfeos.org/workshops/ws06/presentations/Pourmal/HDF5_IO_Perf.pdf http://conferences.esa.int/pde2006/presentations/pde2006_fagot_step-tas- and-hdf5.ppt http://www-unix.mcs.anl.gov/hpio/papers/parallel-netcdf.pdf -- Later, Jerry. The universe is a figment of its own imagination.
|
Next
|
Last
Pages: 1 2 Prev: Scenario Frequency Battle (was: Relational-to-OOP Tax) Next: Question About Builder Object |