[Creeping OT] RE: [ale] $1B for MySQL !!!

[Michael B. Trausch]

On Fri, 2008-01-18 at 09:00 -0500, Jeff Lightner wrote:
> Isn't MySQL GPL?  If so it can't "go away" can it?  Someone else can
> use the OSS stuff and continue on even if there is a commercial
> version can't they?
> 
> FYI:  I found out over the summer from a friend who does development
> at the Weather Channel that not all their stuff is on MySQL - I think
> it is just the web related stuff.   It sounded like the teams that do
> that and the rest of the systems don't really interact much.

That is a seemingly common arrangement.  I think that it is done that
way a lot because it is easy (so I have heard---I have not tried this
myself) to use MySQL to directly pull data from other database systems
and then have Web applications interact purely with MySQL.

While MySQL is "easier" to get started with than many other database
technologies, including PostgreSQL, I think that the real power of it
will come with MySQL 6.0.  I have heard a lot of good things about the
up-and-coming Falcon storage engine.  However, as they add storage
engines to MySQL, there is additional complexity.  Part of the charm of
PostgreSQL is that there is only one type of table available, it has all
of the features that PostgreSQL database server software itself
supports, and once it is configured can be left running and managing the
database with just a little bit in the way of maintenance.

I have also enjoyed PostgreSQL's additional features that it has over
MySQL.  I have used PostgreSQL in a number of projects so far, and then
I returned to work on a MySQL project and kept kicking myself because I
wanted to use features that PostgreSQL had which MySQL did not.  :)

And I would like to revise (at least partially) something that I said
earlier:  I don't know that database abstraction systems are really all
that and a bag of change, but keeping database code in a specific area
of the application is really the smart way to handle it.  One of my
current projects is really hard to work with simply because the entire
code base is peppered with database accesses left and right, without any
sort of centralization.  That is the really painful part, even when not
moving from one database engine to the next.  At least if the database
code is central, it is easier to maintain as well as to make conversions
when the application needs to be migrated from one database platform to
the next.  It would make sense to abstract it partially in this manner,
but I am not a huge fan of cookie-cutter abstraction mechanisms since
they seem to take a lowest-common-denominator approach and do not do
complete abstraction.

The perfect database abstraction layer itself would probably actually be
a database engine, anyway.  It would have to take its own version of SQL
and be able to translate that SQL into database-engine-specific SQL and
it would take a large performance hit.

	--- Mike

-- 
Michael B. Trausch                                   mike at trausch.us
home: 404-592-5746, 1                                 www.trausch.us
cell: 678-522-7934                       im: mike at trausch.us, jabber
Ubuntu Unofficial Backports Project:    http://backports.trausch.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part