On Fri, 13 Aug 2004, Paul Bagyenda wrote:
> But I think that two completely different discussions are going on
> here.
Maybe. Just that when someone claims PostgreSQL is better than MySQL and
vice versa, I get the same "funny feeling" I get when someone says Linux
is better than FreeBSD and vice versa.
> Yes MySQL is fast and easy to use. And PostgreSQL has more advanced
> features, is getting faster, etc. For those applications that need
> the more 'advanced' features (transactions, stored procedures,
> rules, etc), you'd better be running (or developing) on the right
> database!
Even better - one could rather use a database abstraction interface which
decides whether the underlying database engine has all those fancy
features you'd like to use or not. In this way, you won't have to worry
much about the underlying database engine :-). I guess this, too, has its
limitations though - some features can just not be "silently ignored" by
the abstraction interface if the engine doesn't have them, I guess -
meaning a recompile or something of the sort :(.
> What these articles about corporation X or Y adopting MySQL never
> tell you is where MySQL is being used and where it isn't. There is
> a large body of applications for which a simple SQL DB (MySQL)
> will do, and a smaller number where it simply will not. But for the
> latter, those advanced features are very, very important.
Actually http://www.innodb.com/userstories.php shows some really large
users that use advanced features such as transactions, row-level locking,
foreign constraints etc... Later in this post I'll say something about
what InnoDB really is.
> That is, the worry always is that the less informed take the wrong
> path (thanks to the type of articles mentioned), and then have to go
> through the pain and cost working around the problems created.
> Because entirely wrong comparisons are being made. There will be a
> market for both databases.
There will always be the problem of the "clueless" and if they take the
wrong path based on what "they hear" its always unfortunate. But look on
the bright side - how would one ever learn that a thing like "row-level
locking" exists if they didn't first run into trouble - I'm talking about
someone who wasn't priviledged enough to major in RDBMS. Personally I've
learnt alot of stuff but just reading docs and experimenting and reading
docs once again when things go wrong.
But for one thing, I'm sure that if a party chooses which RDBMS to use
based on heresay then for sure they don't know how to use the 'advanced'
features and even using Oracle would not help in that case.
> [...](Though I doubt MySQL will be able to add more advanced
> features now, without serious pissing off their fan base by breaking
> things.)
One of the beauties of the MySQL design is the table handler. In simple
terms this means that theoretically you can have a database consisting of
Oracle tables, MySQL tables, PostgreSQL tables, InnoDB tables etc... All
governed by the MySQL engine. Note carefully, though, that these are just
*table types* - not necessarily the database engine logic. For example,
the InnoDB MySQL table type imitates Oracle-style tablespaces.
This is the very feature (the table handler) that made it amazingly simple
to add transactional support, foreign constraints and row-level locking
without breaking anything -- by simply creating a table type that does
this. So people that need transactional support use MySQL + InnoDB. Right
now the most stable table type supporting transactions is InnoDB
http://www.innodb.com. Some user stories about this may be found here
http://www.innodb.com/userstories.php.
I was kinda impressed by the use of the table handler architecture - it
made the addition of some advanced features nearly magical. I'm just
waiting to see how far this goes, and how far they can go with this before
they really need to rebuild things. MySQL is definately better than it
was two years or so ago and it does have some pretty impressive "advanced
features"
In short, the onus is always on the user to make well-informed
*independent* decisions based on *factual* information and their specific
needs.
Gerald.
Some useful links:
-----------------
Books on InnoDB: http://www.innodb.com/books.php
InnoDB Manual: http://www.innodb.com/ibman.php
---------------------------------------------
This service is hosted on the Infocom network
http://www.infocom.co.ug
