Re: The right tool for the job...
> The interesting thing that seems to be
> coming out of the various comments is a
> view of something like "start with
> MySQL, and if it outgrows that, go to
> Oracle/Sybase/blah". This is an
> interesting challenge for the PostgreSQL
> people; how to make it clear to
> everybody that "there is a middle way".
> And it's PostgreSQL, not Postgress.
Apologies to those offended by Postgress vs PostGreSQL. IMHO .db, .dbm,
and db3 were not as easy to deal with as MySQL was, particularly with PHP
and web applications. When tying to tie a couple of ISPs who's ideas
about admining systems are vastly different at the time of acquisition, an
application was needed in a hurry, and using 'MySQL-Apache-PHP' a solution
was there and available in a week. LDAP would have taken longer, and I
was a contractor, I did was they asked me to do.
The vast majority of admins/developers are self teaching. The community
learning curve may need to go through the MySQL step, before they move to
something else. I watched something similar in the PC world in the 80's.
Odd little special applications using flat file databases, then PC-FILE,
then RBase/dBase, etc. Eventually, they moved to Oracle, and it's
growing pains. As the people who developed their applications grew in
knowledge, so did their need for more sophisticated tools. True database
weenies of the time were busy on the Mainframe loading DB2 databases
snickering at Oracle, and outright laughing at dBase.
Circa 1994 I remember a FAQ on 'free' databases available for UNIX. It
contained a list of features and limits of many different databases for
UNIX. A updated version of that document may have been a better place to
spend energy rather than complaining as to which databse is more widely
accepted, bemoaning the fact, and pondering the reasons it is the way it
is. Complaining and pontificating are less effective at educating than
comprehensive information is. MySQL has a niche it has etched out for
it's self. Is it the best tool? No. Is PostGreSQL? No (that may be
difficult to accept for some). Reading several of your replys to others
you seem to have a strong aversion to anything MySQL. What ever MySQL has
done to step on your tail, there is not much I can do about it, nor any of
the other users of MySQL. Sorry you don't like MySQL, but MySQL
serves a need otherwise it would be so much discarded code littering
the information super highway.
In some ways MySQL-Apache-PHP-PHPMyAdmin reminds me of PC-FILE for DOS in
the mid 1980's. Quick, dirty, not quite fully relational, but it
works for most and get's the job done.
As to why can't open source deliver a 'Enterprise' level data base server?
Probably because it's not high on the importance factor of most
developers. It requires more complicated engineering from the start. It
has always been the realm of the 'heavy hitters' (ie Oracle, Sybase, IBM
et all). It's a long way to go from PostGreSQL to DB2. Even running
PostGreSQL as native code on OS/390 it would be a long journey filled with
DB2 bigots slandering PostGreSQL at every line of code.
-- 73s SK DE Chris
The right tool for the job...
I have just read your article on Open source databases. Though I agree
with some of what you say, I do take a few exceptions to some of your
comments though, of which a few stand out.
You seem to forget other databases such as SAP, SyBase, ADABAS D, DB2 and
others. Each of these are competition for Oracle, and in some cases cover
the same turf Postgress covers.
As to your comment about "Will it be around in 1/2/3/30 years?" Can I get
a more realistic 8 years? Given most software projects by the time year 6
rolls around, the original developer is either a) forgotten history in
that company, or b) [S]He is looking to re-implement it on another
database that has some other super feature [S]He *MUST* have.
Not many software companies that have lasted 30 years. The closest
database company (in my brief memory search) I can come up with is
'Metafile'. It's about 20 years old. I think the company that makes
metafile is still in Rochester Minnesota. With the exception of DB2 it is
the only database I am aware of that has been available since the mid
1980's that hasn't been taken over, bought, sold or abandoned.
As to why MySQL might be so popular:
MySQL had the tools and the 'right size' available at the right time
(early to mid 1997). PHP3 had an arguably better interface than perl
(with the module version for apache). MySQL was significantly better
than MSQL 1.x, and generally better than MSQL 2.x; What clinched
MySQL for me was the more 'open' license than MSQL 2.x.
Having spent time working/developing with MySQL (and Oracle, Sybase
and Informix in UNIX Admin roles) and almost no time with Postgress, I
have little background to speak, however my impression is that
Postgress takes more administrative overhead than MySQL does, so I
stick with MySQL and this impression may be the reason why Postgress
is not as popular as MySQL is.
You spend more than passing time on MySQLs short comings. Some of
these issues you speak of have been addressed in recent editions of
MySQL. Since MySQL doesn't have transactions, foreign keys, sub
selects, et all, then a move to Oracle or Sybase would have been my
choice. If a developer starts with a small light weight RDBMS on a
project and then he bumps his head up against an issue as his project
grows what is his choice? Reimplement on Postgress and continue again
until he runs into a Postgress issue, or break down and buy Oracle and
reimplement. If it were me, I would pick Oracle. At least I can
bitch as a sales droid about the 'vapoware' they sold.
The issue may not be that MySQL is/was first, but that it is a 'baby'
step to learning SQL and the issues associated with growing a
web/database application. MySQL to me appears to be a little less
complicated to deal with. When faced with learning a new language (ie
PHP) and a new way to access data (SQL statements), managing a
database engine and apache modules, taking things in manageable hunks
wins over the better technology just because it's a 'learning
Take your pick. Your guess is as good as mine.
I saw some comments about the scalability of MySQL vs Postgress. Again,
what is the task? I could easily say that Postgress is totally inadequate
for the task of managing a 5TB database of case law for legal searches,
especially since I was a contractor at a very popular legal publishing
company which uses ADABSE D with gobs of PL/1 on IBM big iron.
I would like to see a MySQL type database be included in all UNIXes
(perhaps as a standard), especially if system interfaces were written so
that I could avoid things like /etc/aliases in sendmail having to be read
from flat files and then written in to hash tables. Overkill to use
Postgress, but just right for MySQL. I have used PHP as a cgi-bin program
to query a MySQL database to build a flat 'aliases' file to be read by
sendamil and converted to a hash table. Roundabout way but a whole lot
better than giving out 'root' to a dozen tech support guys who all want
to be to BOFH next week (NIS+ wasn't permitted because of security issues).
What it all boils down to is right sized tools for the task. Some people
may have only run into tasks that you need multi joins, transaction
processing, sub selects, etc which makes Postgress the wonder tool. Some
of us may have only needed to manage loosely knit tables together where a
database like MySQL works fine. I don't need DB2 to manage my
/etc/mail/aliases, /etc/mail/virtusertable, and /etc/mail/relay.networks