| |||||||||||||
Monty on MySQL 5.1Monty on MySQL 5.1Posted Dec 2, 2008 13:47 UTC (Tue) by flewellyn (subscriber, #5047)In reply to: Monty on MySQL 5.1 by pboddie Parent article: Monty on MySQL 5.1
I'm using PostgreSQL 8.x as a 'better' version of MySQL 5.0 Ouch. :-) That was mean. Apt, but mean. I have to wonder, though, if one of MySQL's problems is the plethora of storage engines it can use. I can see how some might consider this an advantage, mind you. Flexibility! Configurability! Adjust the storage engine to your needs! And it's so pluggable and hackable! But, this approach, while it works for some things, is a really bad idea with something as fundamental to a DBMS as the storage engine. It badly breaks the abstraction of the DBMS over the underlying storage. It requires database administrators to make decisions about the kind of access patterns and data models a table will have in advance, when this may not be known. And some of the tradeoffs that the various storage engines make are really unacceptable, such as not supporting transactions for MyISAM or Falcon. PostgreSQL, on the other hand, has one storage engine. It works very well, gives great performance, it's still quite configurable, at no point does it sacrifice ACID compliance in the name of speed (that's determined by transaction isolation levels or locking, like a DBMS should), and most importantly for something so fundamental, it's invisible. There's no good reason for a database admin to have to worry about storage engines. I'm reminded of the CPU scheduler issue in Linux, where Linus (rightly, I think) insisted on having one good scheduler, that does the right thing in almost all cases, and is tuneable for the cases where its performance is suboptimal, as opposed to having a variety of soso schedulers which work well only in narrow cases and require more advance planning to use. MySQL might be better off if they had just decided to make one storage engine that was really good, rather than going down the deceptively cool but wrong "plug in what you like" path for something so critical to a DBMS.
(Log in to post comments)
Monty on MySQL 5.1 Posted Dec 2, 2008 22:48 UTC (Tue) by epa (subscriber, #39769) [Link] Amen to that. Far better to have one storage engine that just works than a wide choice of engines all broken in different interesting ways. This is an example of what Linux Hater called the fallacy of choice.
Monty on MySQL 5.1 Posted Dec 3, 2008 2:51 UTC (Wed) by flewellyn (subscriber, #5047) [Link]
Eh, I think Linux Hater is overstating it, and his choice of LAMP as an example of a "get it right" stack is ironic, given that it's the M in LAMP that we're criticizing here.
I think having lots of choices works fine in many contexts. It's just that, in this case, a DBMS's storage engine is something that needs to work well in many cases, and having choices is harmful to that goal.
PostgreSQL offers many choices, in other contexts: you can add your own types and operators, extension packages, and even procedural language handlers, so that you can write database functions in the language of your choice. The difference here is that the choices are built on top of a solid foundation in which the basics "just work".
|
|||||||||||||