Slashdot Mirror
Why MySQL Grew So Fast
jpkunst writes "Andy Oram, who attended the MySQL Users Conference which was held April 16-18 in Orlando, Florida, attempts to explain MySQL's popularity in his weblog at oreillynet.com. (More weblogs about the 2004 MySQL Users Conference can be found at the The 2004 MySQL User's Conference & Expo Blog Collection.)"
1. MySQL can be installed without cost.
2. MySQL is easy to install and learn.
"You spoony bard!" -Tellah
Too bad indeed.. if it weren't for poor products that get widely adopted fast, graet products would never be adopted. For instance, the reason why the world wide web took off was because Microsoft created a HORRIFIC web browser, but since now all computers had a web broswer, everyone had access.
MySQL was in it's own, a huge part of the dot com boom, and therefore a huge part of the history, and therefore, the future, of the internet. Hate it, love it, it's a great product with a great niche, and for now, it'll continue along that path.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Like Access 2003 it the cream of the crop? I use Access at work and I would gladly change over to MySQL. Better yet, what would you recommend?
Open Source: Every now and then, you get what you don't pay for.
MySQL gets a lot of heat from the DBAs here (and probably with reason), but it's kind of like bashing MS Access -- it's useful enough for most small businesses.
Put identity in the browser.
They do not recognize "Postgres", or even know how to pronounce it. It sounds vaguely French and therefore un-American.
Yep, it is that simple.
2 reasons. LAMP and the fact that not everyone can afford or require for their tasks Oracle
The war with islam is a war on the beast
The war on terror is a war for peace
Oracle, of course.
Love,
Larry Ellison
Because PostgreSQL takes longer to type :-)
Slashdot users complain that MySQL doesn't have the full feature set of some RDBMSes... but they miss the point. The reason MySQL has been succesfull precisely because it's been very good at delivering the features that a particular set of people need. To these users, additional features are a liability, not a feature.
This reminds me a lot of DBase III. (Bear with me here...)
DBase III wasn't a very good database program, but in its heyday millions of people used it and it got the job done for them. Even relatively inexperienced users could make use of it and write simple programs to manipulated their data. Even though it sucked, it was the right tool for a lot of jobs at the time.
Compared to DBase III, both MySQL and PostgreSQL are excellent. I wish I'd had either one a decade ago when I started work doing clipper programming for a dog track related publishing company.
For the dog track application I would have preferred Postgres; the rollback support would be pretty compelling for an application like the one we were doing. Rosebud is a sled, and Verbal is a huge liar. Darth Vader is Luke's father, and the Sixth Sense guy is actually dead. The planet of the apes is Earth, and Rocky loses. For something where I was just kicking around a database (Which I've also done a lot of) MySQL would be perfect. MySQL would be ideal in something like the RHS Orchid Registry, for instance.
If application bigotry keeps you from choosing the right tool for a job, you will be a less valuable resource to those who employ you. Not too many people seem to "Get" this. People are often surprised that I will, on occasion, suggest that Microsoft products are the best tool for what they're trying to do. Usually those people asked me expecting a "Windows sucks use Linux" spiel, but if I think their situation warrants it (Inexperienced user, just wants to browse the web, word process and send E-Mail or wants to play games at all) I'll tell them to use Windows.
In a nutshell, MySql is free. Is it great? Hell no, but it's free. The only deep understanding of human nature or the DB marketplace one needs to comprehend here is that given the choice between something great and expensive vs. something mediocre and free, the overwhelming majority will go for free.
MySql has always had huge problems preventing it from being accepted in the real "enterprise" marketplace, but most of us aren't in that market. Most of us need to yank a bit of data and cram it into a web page moderately quickly and as cheaply as possible. MySql does this quite well.
What doesn't MySql do well? For starters, it's much slower than Oracle, MS-Sql, and even Foxpro. It has no row locking, no transaction support, and minimal cross-platform compatibility. But, it's free and it works more or less ok on Linux.
Perhaps the real truth that Oracle fears is that eventually DBAs will come to realize that 99.9% of their storage needs aren't so "mission critical" as they would like to believe. I mean really, how many people out there can truely justify the cost of a full featured, robust database like MS-Sql? 10%? 5%?
For the rest of us, a free - albeit slightly dodgy - solution will work fine.
Not.
MySQL has always been fast. That is probably why most people use it.
MySQL has also been easy to manage (e.g. move database files from one subdirectory to another and the tables have also moved). That kind of simplicity brings tears to the eyes of an Oracle admin. There are a few options you can tune and teak, but by and large it just works out of the box (er, RPMs).
And of course the reason it has been so popular is that it has been so popular. If you get my circular drift. People use it because there is a lot of documentation about it. Perl and PHP pretty much always have the MySQL libraries so it can be used on web sites, etc.
Speacking of those subqueries, what's up with the delay getting 4.1 out from alpha to beta/gamma/production. I want to start using it. And 4.1 has been out in alpha for over a year now. Not to mention new development is already proceeding with the 5.0 release.
- Run the latest and greatest alpha MySQL database on your own VPS
Not everyone is a database elitist. Not everyone has to worry about transactions nor store procedures. Triggers are neat, but not always necessary. (Insert obligatory VHS/Beta comment here.)
What is great about MySQL is that it gives the average Joe or Ho with a machine a chance to build a database backed application of some sorts. Its cool. Its free. Its fun.
Now for all of those who have based their fragile nerd self esteem on their DB experience or knowledge need to turn off their computers and go down to the local bar and talk to the local people about local people's reality. Ya MySQL is not DB2 nor Oracle, but it is still pretty cool. And the fact that Monty has written the greater portion of it is pretty cool too.
Naysayers need to get laid!
MySQL still doesn't support triggers, and I like advantages of having support for varchars larger than 255 characters. Postgresql also supports the more standard method of an auto-number unique ID field of the sequence (and argueably more flexible). I _really_ like the flexibility of authentication that postgresql offers, though I haven't looked at MySQLs authentication as exensively.
MySQL has grown up a lot though. Given how primitive and featureless it used to be it's gotten much better where the differences between the two have become smaller.
AccountKiller
MySQL, even now, is actually rather sparse as database engines go: it lacks stored procedures, triggers, constraints, etc., in short many of the things that a serious DBA considers necessary in a database engine.
But the mission it was originally created for is a mission that's a very common one: a simple, network-enabled data store with a SQL interface. That it lacked transactional capabilities didn't really matter: it was good enough for what many people needed.
So its popularity exploded. In the free software world, there weren't any other contenders at the time that were sufficiently reliable or fast to do the job. PostgreSQL back then just wasn't fast enough, and tended to eat data. Not that MySQL was perfect in that regard, mind you, but at least MySQL gave you the tools to recover your data quickly in the event of a hiccup. PostgreSQL didn't -- it required you to do a full restore from backups, whereas MySQL let you use 'isamchk' to get you up and running quickly. That made a big difference to a lot of people.
Today the story is very different. PostgreSQL is at least as fast, if not faster, than MySQL in many situations, especially under load, and has essentially all the features needed to make it a "real" database: transactions, stored procedures, triggers, views, constraints, etc. About all it lacks now is built-in replication (there exist third-party solutions), nested transactions, and point-in-time recovery (a.k.a. archive logs), things which MySQL is not likely to get anytime soon.
Nevertheless, despite the fact that PostgreSQL is very much a superior solution in just about every respect, MySQL is more popular and thus has better third-party support. And it's thanks to the fact that it was in the right place, at the right time, with a "good enough" feature set.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Didn't help PostgreSQL or Firebird did it?
Being free is one thing, being fast, elegant, easy to use and administrate, having a pretty clean security record, AND being free, those traits are something to write home about.
Yes, we know, we know, MySQL isn't 99.99999% standards compatible. Well that's something to work toward, but at the time, it was quite usable for anyone who needed to use it, therefore it was used. If the internet needed transactions for things as simple as serving dynamic pages, then MySQL probably wouldn't have prospered, but it did have what the developers needed, when they needed it.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
As a programmer who values practicality above theoretical purity, I don't really understand how something as incredibly useful as MySQL can be so "poor".
All I know is that I've built three highly successful, high volume websites off of MySQL over the past five years and there's no way I could have done it as cheaply or quickly otherwise.
Poor product indeed.
Cheers.
The statement "move database files from one subdirectory to another and the tables have also moved" is a tautology. The tables are in the files, so of course they move.
"That kind of simplicity brings tears to the eyes of an Oracle admin." No, it doesn't. I'm an Oracle DBA, and I'm not crying because MySQL lets you move datafiles - so does Oracle. Typing "alter database rename datafile..." isn't exactly rocket science.
Oracle also works "out of the box", especially when it's used for the sort of applications that can make do with MySQL. Granted, big motherfucker DBs might need some basic memory tweaking, but small sites can generally get by with the default parameters.
MySQL is popular because it's free, and it meets the needs of certain users. That's all there is to it. It isn't better, and it isn't worse.
Access and mysql aren't even competing. It's like saying, "Why would I use openoffice when I can use notepad?"
Access is a minimal driver-loaded (no deamon) RAD tool, for when you need a quick and dirty forms and business logic driven app for a few people.
People use it as a simple DB, but people also use MSword as a note-taking app. To replace access, you'd need mysql + a gui DB design tool (I know they're out there, just can't think of one off the cuff) + one of:
-apache + php (no gui designer though!)
-java (swing or swt with a gui designer)
-VB
-VC++ (although now you're getting heavier...)
Plus a server of some sort to run the mysql on.
Access is generally crap, and I hate using it, but it's great for a small office of 10 people to do small amounts of ordertracking/whatever type of small app they want pieced together quickly and cheaply, without UPKEEP of a server.
Poor design probably is less important than wide adoption when it comes to growth. But that is circular. Growth and wide adoption are really the same thing, right? At a minimum, wide adoption is a result of growth. They are tied together.
So, taking a step back, what elements drive growth? That's the question. Google taught us that popularity matters.
Taking a different step back, I would argue that usability has driven growth. Namely, ease of use. A quote from the article supports this:
"But MySQL's very simplicity made it so small and fast that it quickly won over small users who wouldn't even understand what they were missing and how to use the fancy features offered by "real" database engines."
My final comment about "poor design" is this. Assuming the design is poor, does it really matter? If it solves problems, and if people use it, and it is a Good Enough solution, and if the price is right, poor design is largely unimportant, right?
How to Download YouTube Videos
I understand it's supposed to be better because it supports more ACID compliant features (and has for a long enough time to consider them stable). I just can't seem to get the hang of PG though. I far prefer the mysql command utility (and mysqladmin) over psql, I just find it easier to use. I also don't like the way PG handles users. I find it easier to add and modify users in MySQL and set their privileges with it's table method than PG which is more configuration based. I could figure everything out, but I've been too swamped lately to learn the in's and out's of PG. That's why I continue to use MySQL, because it fits my needs. Not PG's fault, but it's one of several reasons people still use MySQL.
-----
How can you have any pudding if you don't eat your meat?
Maybe for you. For me, it was dead easy to set-up, quick to learn and the @#$! thing WORKED out of the box! I can't say the same about Posgress.
At anyrate, the better way to look at MySQL is the kind, gentle introduction to SQL until your needs drive you to a grown up database. For my dev team, we just needed a backend for our existing Bug database without paying exhorbitant charges to IT Support to use MS SQL. MySQL so fits the bill.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
When Microsoft realized that they had backed the wrong horse, they had to come up with their own Internet strategy in a hurry, or be left behind. That is why early versions of IE were such hack jobs. And for some years, other browsers still did more to raise awareness of the Web. But once the Web was established, nobody bothered to install other browsers -- why bother, when Windows came with one? Between that and Netscape's declining interest in browser development...
As for MySQL: when the Web exploded, web developers needed data engines that didn't cost a lot and were easy to understand. The excluded all serious SQL servers. I'm not sure why nobody picked up on simple ISAM systems like Berkeley DB -- perhaps they all had licensing issues. Anyway, MySQL was something they could use for free, it was easy to understand, and it was powerful enough for most web applications. You can't do the complicated operations that separate a true RDBMS from a simple dataset library -- but most web developers didn't have the skill to use these operations anyway.
Remember when Reasoning, Inc audited the code? They found that it had 0.09 errors per 1,000 lines of code while proprietary competitors had 0.56 errors per 1,000 lines. That's more than 6 times as many errors in the proprietary databases. http://searchenterpriselinux.techtarget.com/origin alContent/0,289142,sid39_gci941817,00.html
Quality product. That is why it is popular. Perhaps you should research your argument before posting a flame next time.
bash: rtfm: command not found
It was the simplest database at the time that was marketed well. Minisql was not marketed at all, and of course wasnt really opensource.
People need to use SQL and need something simple and fast. Postgresql is not optimised for simple web applications out of the box.
sqlite I think came much later, but would have fit the bill and IMHO would have taken Mysqls place early on. I know I was looking for something like sqlite making my simple website and mysql seemed to complex.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Over the years I have been a user on PostgreSQL, MySQL, Oracle, and MSSQL, and an admin on PostgreSQL and MySQL.
Having said that, I prefer MySQL and PostgreSQL to both Oracle and MSSQL, in most situations. However, given my experience with MySQL and PostgreSQL, I am glad that I have returned to PostgreSQL.
Why PostgreSQL? Simple. I am able to use referential integrity, triggers, and foreign keys in my databases. I can use subqueries, and more. There are certain databases where the data integrity is the important part. Having the database enforce that integrity is cheap insurance. Having transaction support, including rollbacks, are great for operations that affect multiple tables. I also like the way Postgres strives for SQL compliance.
MySQL is improving. Everytime I check they are getting more and more support of things I consider critical. Especially in the last 9 months to a year. But not yet enough for me.
I was involved in a fairly large scale production system that used MySQL as its heart. Unfortunately, at the time, PostgreSQL just did not have the performance that was needed. And, the main DBA was a mysql zealot. With MySQL, we seemed to constantly have to figure out creative work arounds for what MySQL lacked. Table level locking was a headache. No referential integrity and lack of transactions were a nightmare.
I still see MySQL as the better solution when you need to serve text files via SQL really really fast. But, when you need to provide a specific level of accountability and traceability, PostgreSQL is still my choice.
. 62,400 repetitions make one truth -- Brave New World, Aldous Huxley
"On the other side of me, at that lunch, sat a database administrator whose facility is planning a migration from Oracle to MySQL"
Whatever moron made that decision needs to be outsourced to India. Thats sort of like trading in a shiny BMW for a freakin go-cart.
Sure, MySQL has gotten better, has always been speedy and is great for down and dirty webservices. But the bottom line is still the same: It's not a **real** database. Transactions? Stored Procedures? Triggers? Schemas? Groups? Views? Uhhhh Hello!!!
Granted, MySQL is popular; just about every cheapo hosting service has installed it and offers it up as part of their base level $20.00 a month hosting pack.
Being a seasoned webdeveloping gun for hire I deal with online data services all the time. Time and time again I use postgreSQL.
Sure, the client always brings up the MySQL question, but when I show them what can be done with postgreSQL and what can't with MySQL it becomes glaringly obvious that MySQL is __NOT__ the tool to use if you have any real service to offer or data to mine.
For all you MySQL advocating web developers out there:
If you put all the SQL functionality where it should be -- in the database -- and not the middleware you'd never even think of MySQL as a real alternative, because MySQL doesn't support that.
I think it does have a lot to do with the name.
MySQL, maybe it is My-Ess-Que-Ell or maybe it is My-Sequel, but Postgresql? Postgr-ehz-Que-Ell? Postgreh-Sequel, Postgray-Que-Ell? (Does sound vaguely French.) Ugh! (Nothing against French.) Hate the name, but love the program. Although it seemed that there were more people choosing MySQL over Postgresql when I started evaluating the two, there were two key features that led me to choose Postgres(whatever) over MySQL
1) Views (How can you have a/an SQL database and not support views!)
2) Free license for corporate use
So, if I chose to work with MySQL I would have to give up using views. Also, if I wanted to use it at work, I would have to convince the boss to buy a license. On the other hand if I worked with Postgres(whatever), I got views, and did not have to persuade the boss to part with any money. So it was 2 minuses in the MySQL column, versus 2 pluses in the Postgres column and the Ayes have it. After MySQL changed their license, inertia kept me going forward with Postgres (and MySQL's lack of views and triggers).
Now that MySQL has a GPL version, it is less of an issue, but at first, it was free for non-profit use only (or so I understood), while Postgres was free for any use. It surprised me that so many would choose the non-free / less free license.
I for one cannot understand how anybody can do *any* serious database work without views and subqueries (the latest MySQL alphas/betas have support for subqueries). The whole relational theory is (almost) broken without these.
To me that's mindboggling. Without that I'd rather use berkeley DB or flat files to load and store my data. How do you do row-level security without views, what about column security. Or just different views for different users. These are just a few example that require *a lot* of coding without database support (not to speak about performance). Heck, do people even understand what views (or triggers, etc) are?
People say it's easy to move databases around my MySQL. Yeah, sure, as long as you stay with the ISAM tables, which do not support ACID. InnoDB tables support ACID but cannot simply be copied around.
It makes me shudder to think about all the future DBAs that accept the low standards MySQL is setting.
Perhaps it was random MySQL data corruption at work. ;-)
(Disclaimer: I like MySQL.)
Which is why Windows 95 came with a lot of MSN software and libraries (then based on proprietary protocols) and no TCP/IP stack at all.
That, buddy, is double-plus untrue. The second part anyway.
From what I see so far, there isn't much equivalent to any of this so far. You create a database, and your server config determines where ig goes and (I think) the format/type used for the physical files.
To put it bluntly, you're going to use the default filetype for everything in MySQL. There's some nods to the idea of having ram-based tables and the like, but if you're really serious about that stuff then MySQL is the wrong tool to be using.
One of the biggest knocks against MySQL is that its favorite file type is basically a flat file with just a bit of an index to it. More or less, that's true. MySQL isn't meant for somebody who cares about where exactly on the hard drive the data is going, just that it's being saved and will respond when called upon with a SELECT query.
Think of yourself as a database user rather than a database admin. This thing has most of the "administrative" stuff hardcoded. You don't start until it's time to define tables and indexes...
You are what most people consider to be a ignorant, propaganda-influenced bloke (or average consumer) if you're willing to:
A. Believe that 33.5% is a significant number, of any type. See the book, how to lie with statistics.
B. Believe any propaganda released by Microsoft, or any other released "benchmarks" when they haven't released exactly how they've done the testing.
C. Believe that an MCSE is enough to make me consider you an industry professional. I can read and memorized books too.
Things got interesting when I loaded all 2 million rows of data (one per file) into the poor POS Access DB. It took over 8 hours (I left it running and went home; it was still running when I got back. Lo and behold, it accepted every row. Trouble started when I discovered that trying to save a query or report would send the machine into la-la land. So, I had to dump the DB for every tweak of the report. After a week of messing around (time "well spent," as using Oracle/MS-SQL would have saved at least 4 days of waiting for row population), I finally got everything working, and turned in the report (something like a 500 page PDF).
Naturally, they wanted to change the criteria and group by something else. "Sorry, but today's my last day," I grinned. "And it takes at least one full day to make any changes, assuming you got it right the first time."
Suck. Ers.
Yeah, right.
You're right, not everybody has to worry about those issues, but maybe they should. However, the problem is not so much with MySQL itself (it's a good, fast, lightweight storage system for simple and small amounts of data). It's with the perception that MySQL is every bit as good as a more robust engine (Oracle, MSSQL, DB2, take your pick) for any application. That is definitely not the case. As well, knowing MySQL does not make you uniquely qualified to decide that it's better than one of the other choices for a system that needs that level of robustness. The biggest problem is that people who only know MySQL choose MySQL because that's all they know, even when it's completely unsuited to the task.
Add to that the arrogance of the MySQL developers ("These aren't the stored procedures you're looking for ..."), and the zealotry of the user base, and it's easy to see why those of us who do know a thing or two are bitter about MySQL. I laugh anytime someone tells me that they can enforce data integrity from their application layer instead of using foreign keys (usually while trying to clean up their mess of a data set so the data itself can be trusted). I find it hysterical when I'm told that stored procedures are a complete waste of time (typically while fixing someone else's SQL injection problems because they insisted on writing dynamic SQL queries from their code).
I'm all for making databases and db technology more available to the Average Joe, but MySQL is not the way to do it. If you need free, there are many better alternatives to MySQL (especially if you only need free for training purposes, because then the big three are available to you as well).
Comment removed based on user account deletion
A view is just a query which you can run again sometime?
You really need to learn RDBMS theory.
I do find it interesting that Linux users like to lord over Windows users how "sophisticated" they are, but when it comes to MySQL, they use the "well it does what I need" excuse, ignoring the gaping technical issues with the product.
1. Bovine growth hormones in its milk
2. Possible steroid abuse
The problem is, most people would disagree. Why? It's not because many hate the DB....and many do. It's because MySQL teachs many non-standard and down right bad habits. If you want a system to learn SQL or relational theory, MySQL isn't right for the task. Why? Because very little of the learned knowledge will apply to any other system. If, after all, the intent is to learn a generalized body of knowledge, then by definition, you can't use MySQL.
If, on the other hand, your objective is to learn MySQL, then by all means, learn by using MySQL. MySQL is well known for teaching people enough to be very dangerous but never enough to produce clean, fast, effecient SQL code for other RDMBS. In other words, learning on MySQL will probably teach you how to make the least effective queries for other platforms.
I like the idea of MySQL. It's great. But it's not ready for the big time. Not nearly.
:
:
Yes there are work arounds for the missing features. These work arounds are usually - do it in the application code. Yes I can do it in the application code, but that takes away many of the benefits of using a RDBMS in the first place.
To give you a quick idea. Our clients have complex MS SQL Server db's that hold a lot of data, all somehow related to each other. A few quick queries on my dev db gives the following results
1061 tables
1742 stored procs
1281 triggers
The database gets accessed in a lot of different ways. This includes, but is not limited to
C++ via ODBC
C++ via ADO
Delphi via ODBC
Delphi via ADO
JSP Pages
ASP Pages
Java Servlets
Perl Scripts
Access
If something new technology comes along we can use it on our db. Why? Because the database is kept consistent through the use of triggers, stored procs and key constraints. If you have mutliple ways to access a database, you do not want your bussiness rules to sit in application code, you want it on the db.
siener's youtube channel
"MySQL uses table locking (instead of row locking or column locking) on all table types, except BDB tables, to achieve a very high lock speed. For large tables, table locking is MUCH better than row locking for most applications"
I completely agree with you here. I believe that once the native Win32 port of PostgreSQL finally becomes available, it will start to make some serious inroads.
The cygwin port is good for playing and development purposes, but it is not ready for production purposes. If someone is using it in production, good luck and more power to them. While I consider my self to be very pro-PostgreSQL, I wouldn't use the Win32 cygwin port in a production environment for anything.
For what it's worth, the native Win32 port is being actively worked on. Hopefully it will be available in the next major release. It may slip to the second release out. Nonetheless, it is actively being tested, developed, and worked on.
The article rambles a bit, but it does hit the nail on the head when it comes to what drove the rapid increase in popularity of MySQL -- that it was small, fast, and easy to learn, mainly due to the fact that it did not include features that were, for many users, extraneous.
When I first went looking for a database to drive my website, my more knowledgeable friends and professional acquaintences all hawked postgresql. Since it was the default db that shipped with Red Hat, I figured I'd try it. I liked how robust it was, but I had a hell of a time finding support for it in the applications I wanted to run. I eventually switched to MySQL (which I had already used for various other projects) because it still remains easier to use, and because PostgreSQL is way more than I need.
The simple fact of the matter is that most users don't need ACID compliance, or transactions, or what have you. They need a storage system with sql interface, and that's it. Users who need more from a database would pass up MySQL for something better suited to their needs... but those users are in the minority. Everyone else's needs are simple -- MySQL sacrificed the less essential features for speed, simplicity, and ease of use. As a result, it was more attractive to people who were adequately served by its feature set.
And as MySQL has progressed, it has added in many of those features that higher-level databases like PostgreSQL offer, allowing us the option of using those features in the future.
The dual license is, in my view, a great business model. It provides the revenue stream open source projects need without sacrificing the freedom for those users who embrace the open source concept. As I understand it, it's free for use, and free to distribute under the terms of the GPL... but you have to pay if you want to use it in a non-GPL product. To me that's genius -- it forces a licensee to play by the same rules he sets, which seems only fair. I wouldn't be surprised to see more projects adopting similar models, nor would I mind.
who says that MySQL is better than Oracle? i've never read or seen that anywhere. it is two different products in two different classes. they can't be compared.
it's all about the right tool for the right job.
coding up the next Ebay? use Oracle.
wanna keep track of your DVD collection? use MySQL.
i've used Oracle and Postgres, and i've setup triggers and stored procedures and hard relationships.. sure it's useful,
but it's rare when i'm doing a project that's out of scope of MySQL (and i can do all the trigger, stored procedure stuff within the application code, big deal).
MySQL also allows you to do rapid development of small to medium sized projects. what if one of my projects gets so big that i need to scale it up? well, if i am so unfortunate to have one of my projects go big time, then i'm sure i'll get big dollars and redesign the project for the big leagues.
here's another example:
i was working for a small company that finally recieved it's funding (15 mil for 10 employees). well, the company started hiring corporate types left and right.
well, these corporate folks had little to do except dress nice and figure out how to spend our funding.
i was called into the CTO's office. he sat me down and explained to me that he wanted to setup a database to store employee information (address, phone number, normal stuff). at that point we had about 25 employees. i was like, no problem i'll setup a MySQL database with a PHP front end and have it done this afternoon.
he told me to do nothing and wait for the Oracle people that were coming the next day to discuss licensing.
my jaw hit the floor.
but this is exactly the problem. people don't realize which tool they should use for what job.
One thing that MySQL isn't is a bloated whale of an application. Oracle is feature rich and under heavy load, when administered correctly, is blazing fast. But that also makes it a system resource pig.
Part of the reason why every SQL feature in the world isn't implemented is because it sometimes pays to make an application lean. I tend to believe the authors/maintainers have a lean-mean philosophy, and sometimes prefer to let the users implement their own creative solutions instead of providing every bell, whistle and horn.
As a hypothetical example, one can easily implement an auto_increment feature outside of MySQL using a combination of a simple table declaration and some create PHP or Perl programming. Not that you'd want to, but some creativity can make up for non-implemented features.
In simple terms, MySQL is the equivalent of a cheetah. It's fast and lean, and accomplishes it's task with agility and grace.
MySQL is also easy to learn and easy to implement, especially if you are using the Apache/MySQL/PHP or Perl combination. Even better, this entire scheme will run using only 128-megabytes of RAM (thereby making my 5-year old AMD 500MHz still usable!). Try that with Oracle... can you say swap partition hell???
It doesn't seem like anyone is honest enough to spill the beans on this one. Postgres isn't available for windows without using Cygwin. The truth is that most beginers are looking for an executable download... with an installer. If you tell them that they have to compile or install something else first, they freak out.
The truth is that people are learning on their home systems which are more often than not windows systems. On top of this, most hosting companies only support what is most popular, hence MySQL.
Once Postgres is available on windows as an executable download with an installer, watch its popularity soar.
"I'm a loner Dottie, a rebel."
- Pee Wee Herman
MySQLs popularity is due to it being percieved as an extension of the textfile solution and it's open and closing problems rather than what database savy would call a database.
If you want to drop data somewhere and pick it up later - which is usually the case in 99% of the time - MySQL is perfectly sufficient.
Real usecases of databases however acutally require a solid integration of data and code and transparent runtime access to it. In terms of true object orientednes the 'real' DBs are just as much a compromise as MySQL is and require tall stacks of code to compensate for hardware constraints and data obscurety.
Object relational DB's that offer absolute transparence of data and application space at runtime are the true thing. But those, appart from a few exeptions, aren't quite there yet.
Zope/ZopeDB comes to mind as an example of what DBs should be like. Compared to Zope, MaxDB, Postgres or even Oracle are not much more than MySQL. It's all dependent on the perspective.
We suffer more in our imagination than in reality. - Seneca
I have a very similar story. Small company, big spending, decent business plan, very poorly implemented.
I went to talk to the guy in charge because he got in his head to buy Oracle. I was trying to convinve him to use MySQL because of cost. He thought Oracle was the only way a company could operate.
Here's what actually happened:
(1) We settled on Sybase
(2) Took forever to get plans worked out and the software in place (it would have taken a matter of hours for me to get MySQL in place...)
(3) We never moved off our "temporary development" system that was a flat text file[1]
(4) Investors realized nothing was making it to market and too much was being spent, and company went under.
[1] The flat text file -- 100's of MB -- was being read several times each time the front page of the company website was loaded. And no, nobody ever got sybase in place behind it. After all, details like that don't impress investors.
Disclaimer: I now use postgresql. At the time ('99) postgresql still had some rough edges, but now it's the best database out there for everything that I use an RDBMS for.
Social scientists are inspired by theories; scientists are humbled by facts.
Now the feature set is stable, it can always be re-implemented in a more "beautiful" style. Well, since the mysql_*, pg_*, sybase_* and so on functions use very similar syntax, try using sed.
But I think the question we should be asking is, why would you want your code to support a different database anyway? MySQL is free software, so it'll always be available and supported. Ditching some of the bells and whistles and relying on the scripting language (perl, PHP or python) to do some of the donkey work made it bloody fast {e.g. the primitive % and _ wildcards work so much quicker than full-blown regular expression matching, that it's quicker to pull out more records than you need, have the wrapper script do the regular expression matching and just throw away the ones it doesn't need; more of the queries you are going to do are going to be right than wrong, so let the script provide any 'rollback' functionality you may need}, and -- barring a power failure -- it doesn't corrupt its own tables either.
You obviously think that constraining a programme so it only performs one function is a bad thing -- I guess your ultimate piece of software is one that doesn't care what kind of hardware it is running on or what function it is being asked to perform. But such high ideals are too far removed from reality for most ordinary people to take seriously.
Most programmes don't need to have so much changeability, because they are designed to do a specific task. You can add your fancy object oriented classes and methods, abstraction layers and sundry filibustering tricks all you like; but nothing will change the fact that, at the end of the day, sooner or later, you can't avoid the inevitable fact of having to get your hands dirty and actually manipulate some data. It does mean that a programme meant for handling order forms with a Postgres backend is going to need a lot changed to make it do cooking recipes with a MySQL backend, but if your audience prefers to see a pony doing one trick well rather than a full repertoire of tricks badly, who's disappointed?
Je fume. Tu fumes. Nous fûmes!
(1) We settled on Sybase.
(4) Investors realized nothing was making it to market and too much was being spent, and company went under.
Heh... you could've just combined steps 1 and 4, and skipped 2 and 3 altogether, and the story still would've made perfect sense.
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
I can give you the reason why MySQL is so popular: practitioners are ignorant of data management fundamentals (perennial links: Unskilled and Unaware of it and Database Debunkings).
If you don't understand or know the necessity of things like constraints and tying business logic close to the data then you don't care that MySQL can't do them. It's obvious that MySQL developers do not have a clear understanding of the relational model, either.
And how is this elitist? Is it elitist to require that engineers who build bridges know the physics behind bridge building? Would you go to a doctor that didn't know the science of human physiology? Why do we not expect the same level of competence from people who build databases?
As computer professionals we need to hold ourselves to the same standards that we require other professionals. I'm not suggesting, or even think it's a good idea, to license developers but we need to get out of the mindset that it's acceptable to eschew formal ideas (predicate logic/set theory and the Relational Model) for ad hoc junk science (XML, UML, virtually every SQL DBMS product, etc.) all in the nebulous name of 'performance'.
Thanks,
--
Matt