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!
For myself and many other college students, MySQL was a great system to play with SQL and experiment on. It's easy to setup on most systems, and it's also fairly easy to use (not to mention free). Don't get me wrong- I've used other systems that are much better than MySQL, but without MySQL to get my hands dirty, I'm not sure I would have bothered with anything else.
I'm mainly interested in the SAP and mySQL connection because I simply didn't know about it until I read this. I know it is a bit offtopic, but I recently attended ASUG 2004 (America SAP User Group) and I posted news about it to my site. Perhaps you'll be interested.
JavaScript, DOM, and Page Reloads
Usability Interview with David Clark of TandemSeven
More Observations on ASUG 2004
ASUG 2004 and RFID
How to Download YouTube Videos
One word: PostgreSQL. Also free, but makes mySQL look like a toy.
You forgot to add an important qualifier here - for a certain set of circumstances. MySQL is one of those products that is suitable for database content that isn't changing much - it's very fast reading from the database. The numbers change quite a bit when you're doing heavier work on the database, which is where Oracle & MS-SQL (or even PostGreSQL) come into their own.
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.
In fact PHP is a highly customizable, fast-rendering and highly scalable platform. It's not PHP maintainers' problem if their tool is badly used all over the place.
I think you should keep your faulty beliefs for yourself young man, and give due respect to these very fine men.
- Bernard Wolkacz
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?
Use Access 2003 as your frontend to MySQL
-Docvert converts MSWord to OpenDocument, clean HTML
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
Another reason is that so many (web) programs incorporated it, like vBulletin. it was free to use and easy to learn, and it was painless to deply on virtually any platform.
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
What I posted wasn't a troll, it was the truth. Just because something pisses you off, doesn't mean it is a troll.
"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.
One of the reasons why MySQL wins on PGSql is it Win32 support. We may not all like windows, but a lot of people use it, MySQL has addressed this market, PGSql still dosen't
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.
Hmmm... a $72 million a year toy? That's what the most recent company I work for had in revenues last year. Entirely built upon MySQL. I'm sure that's small change from your point of view, right?
Sorry, but practical trumps theoretical every time.
Cheers.
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.
Really? That's odd... I've been using it on high volume sites for about 5 years now and I've never had one data corruption problem. Does my anecdotal experience cancel out yours?
(Once did have an index become corrupt, but a "repair table" command fixed it).
From what I can tell, most people who trash MySQL do so on theoretical grounds. In practice it is amazingly useful. That's all any product needs to be.
Cheers.
But no-one used that "HORRIFIC" web browser, except to download Netscape. At least util NN4, when Netscape shot themselves in the foot (and took off most of their leg in the same shot). After that (well, until recently) Internet Explorer was a better browser - far from "HORRIFIC".
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.
.. the day it returned a date column with the value '2309-46-39'.
(that, retarded access control system and the random data corruption..)
No, I did not read the f***ing article!
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).
>> ...and if the price is right, poor design is largely unimportant, right?
;-).
...and these are just a few of the things I am talking about. Yes, if you don't know about them, then of course they don't matter. I developed with MySQL for at least 2 years, blissfully unaware of these things. Then, I found out the capabilities of a real DBMS, and I was able in some cases to reduce my application code by 80-90%. That results in not only a better designed system, but in a *cheaper* system, since writing and debugging is much less trouble, and your liability for data corruption is far less.
... not recommended ;-).
I suppose that's something you'll enjoy saying to your clients when they realize their data is corrupted because an application bug circumvented your data model
OK, sorry... that was a cheap shot.
But really, the question is largely one of awareness. Most developers are simply unaware of the logical capabilities of the relational model, so they assume that the things they would do with a "full" SQL system are almost the same as what they would do with MySQL. If that is the case, then of course there is less reason to use MySQL. (there are also those developers who ARE aware of those capabilities but are too much in love with writing extra code, so they prefer to dismiss them)
But, once you realize that with the proper SQL system...
1) You no longer need to worry about validating every little piece of data you insert. The design of the [table/view/procedure + constraints] IS the validation, if done properly.
2) When you need to change or add business logic, you can do it in just one place, and rest assured that no code elsewhere in the system, whether written by you or someone else, can circumvent this.
3) If for some reason another development team needs to access this data, you don't have to lose sleep wondering if they are screwing up your data or worse.
4) The *types* in your DBMS actually mean something. (MySQL is so bad at type enforcement that it is almost typeless)
Taking this in the larger context of your post, MySQL can be compared to fast food, such as McDonalds. It's cheap, it's everywhere, and sometimes it hits the spot, but a steady diet of it is
Comment removed based on user account deletion
I think that MySQL had a lot of help from mSQL.
I don't remember the details of the licenses, or exactly what happened, so some of what I say here might be wrong. But wasn't mSQL sort of dominant in this space (people writing simple web/db apps on linux) until they did something ugly with their license?
And wasn't MySQL's API sort of similar to mSQL's, making it easier for projects like PHP to pick up MySQL?
- don't know enough about databases to understand why they should be using a different tool
- members of the 'I have a hammer, therefore this problem is a nail' sect
- people making money from the first two groups
Finding someone using it and can give good technical reasons *why* they are using it is a rare find. Feel free to substitute Access, Visual Basic, Perl, C, Java, C# or C++, Windows or Bose for MySQL if you like.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
But Postgres has been a fully functional RDMBS for years, with the features a professional needs.
Both can be obtained for free (though mysql is dual licenced). Maybe mysql has better marketing or offers better support, while becoming the default database for PHP?
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"
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.
What rock have you been living under? Have you ever by chance heard of a program called Excel?!? Most robust DB product on the market as far as I know, and I know a lot.
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???
When someone is examining a couple alternatives, and one works right away and the other requires reading (even merely 5 pages), the reading just won't happen unless the user really cares. You eliminate a large number of users just by raising the bar a very slight amount.
However, I'm a postgres user, and I'm here to say that reading 5 pages of docs is not required to issue your first "create table" command.
In Debian, it's one command to install and it will ask you simple questions, like where to put the data. For those who like a GUI, another command will install pgadmin3. Really, how much easier can it get to install?
To connect for the first time in Debian, just become the user "postgres" and connect to "template1" and it will let you in without a password (after that you can create more databases and users).
Why are these vague accusations about usability never pointed at the distributor (Redhat, etc)? I don't complain about the installation difficulties of KDE because Debian handles that for me. If I were to write a usability report of KDE without using Debian, would it be fair to speak of the myriad dependency problems and long compile times? No, it wouldn't, 'cause the distributor handles that for most people.
And the thing is, MySQL and PostgreSQL, as far as using the database, basically both just provide the ability to execute SQL commands. The difficulty couldn't be over PostgreSQL's syntax for creating a table, I assume. So where is this usability issue appearing? If it's during the install, shouldn't the distribution do a better job of installing it for you?
It's really not fair to point the finger at postgres when the reality is that your distributor just doesn't care enough to make it easy for you, and maybe their default database is MySQL.
And even compiling from source, there aren't many packages anywhere near as complicated as PostgreSQL that compile and install so easily.
Social scientists are inspired by theories; scientists are humbled by facts.
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
The reason MySQL has been so successful is that it is NOT a relational DBMS. It doesn't have any of the features that a "real" database would have. That's the point.
MySQL is a glorified card catalog with a reduced-SQL interface. And for the vast majority of the projects that use it, that really is all it needs.
I say this as someone who has not written in any production SQL environments except for MS Access and MySQL. For small stuff, all I want is a card catalog with joins, and MySQL gives me that easily. I know the projects I've worked on aren't going to scale to a million rows, they're only in the few thousands, or in a few cases only a few hundred. If they start to get to the point that they're handling millions of transactions, then I'll be rewriting the whole thing anyway.
Tell me: WHY would I want to use Oracle or even PostgreSQL for a recipe book or web calendar when MySQL requires less mental overhead for me? I wouldn't. That's like using a Mac truck to drive to the grocery store and back.
When I start writing financial apps or systems that actually require complete integrity checking, good bye MySQL, hello Postgres. But for right now, MySQL is simple, my web host supports MySQL, and it's all these projects are going to need.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
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!
Now _that's_ funny. I've worked with so many organisations who think that Excel is a database, and really don't see why they should change to something else, regardless of whether it's Access, MySQL, PostGre, Oracle, or whatever.
It's only once you've shown them a few things that are easier in anything other than Excel that they begin to understand - and in some ways that's why MySQL is useful, it provides a cheap/free alternative to investing in Oracle etc., and is useful for demonstrating the basics of why a DB is better than a spreadsheet.
I say we take off and nuke it from orbit. It's the only way to be sure...
Get your facts straight.
The world wide web had already taken off, thanks to Mosaic and Netscape. The company making internet explorer was bought by microsoft when they realized they had missed the train due to Bill Gates' declaration of internet as irrelevant. (Remember, "microsoft network"?)
Ceterum censeo Microsoftem esse delendam
Not trying to flame... talking about maturity of experience...
Lots of people didn't care. They just wanted to stick dynamic content on their pages.
Most of them didn't care about things like transactions. They either never heard of them in the first place, or figured they didn't need them.
Most of them didn't care about portability.
A few of them found that MySQL was fast when you don't care about these things, and that it was easier to install. The told others, and it became 'cool'...
I'm not knocking the above, most of them were probably self taught, and have learned a lot since. The MySQL userbase seems to have matured a lot, and as MySQL becomes more like a 'real' DBM, it's users are becoming more like 'real' SQL admins.
The only real competition at the time was postgres, and it was slower, and possibly more difficult to install. Those of us like me who cared about things like transactions took the extra time to make it work, because we wanted what MySQL didn't offer.
Vs lbh pna ernq guvf, ybt bss abj. Tb bhgfvqr. Syl n xvgr.
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
My company is a big MS shop, and shis is exactly why we won't hire anyone with an MCSE. They can spout off all sorts of numbers, percentages, tell you the storage size of every variable in the MS world, but when it comes right down to it, they can't deliver results and work SO SO slow.
You might want to consider upgrading. Most (all?) of these issues have long been resolved. In fact, the latest versions now support auto-vacuuming.
As long as your application is not holding transactions open and never completing them, vacumming should not be a problem at all.
If you are having serious performance issues, I sincerely hope that you've contacted someone on the mailing list to determine if they can be resolved. It's certainly possible that PostgreSQL is not right for the job. More often than not, the situations that you described almost always turn out to be improper performance tuning or unrealistic performance expectations for the available hardware; lumping the blame onto PostgreSQL's shoulders.
It does sound you have some problems there. What did the developers say when you asked for performance tuning assistance?
The Good.
1 MySQL let thousands if not millions of people work with a SQL database server for the first time.
2 It is fast which means it could support a lot of people on a pretty cheap machine.
3 It is easy to setup and learn.
4 It is very good at provideing dynamic web content.
The Bad.
1 It did not support transactions or row level locking. An yes you need them for some applications. It is possible to program around the lack of these features but why?
The Lie
"You could also achieve efficient locking without row-level locks; in fact, supporting row-level locks took so much overhead that the application was almost better without them." ummmm.... No you are wrong. Okay you might notice that he said that applications where "almost" better off without them. That means that they are better off with them.
Don't get me wrong MySQL is a great product and does what 90 percent of the people that want to do. I wish them all the best.
My other pet peeve right now is the over use of MySQL in free programs. Does a cd catalog really need a SQL database server? Or an address book? Come on folks lets us BerklyDB or even a flat file for goodness sakes. Sometimes a SQL datase server is just over kill.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Download DB2, Oracle or SqlServer. I'm not 100% srue about SqlServer but DB2 and Oracle allow you to download their software for free (with much better documentation) if you only use it for self-education.
"Thanks to the remote control I have the attention span of a gerbil."
Read the article again as to why MySQL has had enormous acceptance. It really is a good read. The article's intention was not to say the MySQL is the answer to any and all RDBMS questions. Point being - MySQL works because it's light-weight and fast enough to support even large websites. For the vast majority of general web scripts and even small applications, MySQL does the job - and does so quite nicely.
If you, in particular, need row-locking capability - look elsewhere. The beauty of open-source is that you have a choice, whether to use or go without. So as far as your "bad" point - MySQL would not be the answer would it?
To address your peeve, the nice thing about MySQL is that it provides a structured, easy-to-interface method to store a large amount of data for a variety of applications. Sure, you could use a flat-file or BerkleyDB - but then you constrict yourself to how you can access that database.
MySQL (not to say it's the only one) allow you to connect via a variety of interfaces, a local socket or across a network (standard or encrypted). Having a networked database allows for all kinds of uses for applications that may or may not want to store its data on the computer they are running upon.
Ayup
mainly to hide the underlying structure from users. Also, i've seen alot of very complex and long sql in views that you really wouldn't want to put into your application. As the grandparent said, it can also be used for security purposes, something which you don't want to code into your application either. Why? Because sometimes you can't guarantee users are going to enter the database via the application. Views can also be used for version control. Views are view usefull, are they required? Probably not but they sure do make life alot easier. The grandparent may not have stated his case well but there are many valid reasons as to why you'd want to use a DBMS that has views.
"Thanks to the remote control I have the attention span of a gerbil."
Its the administrators. I hate to say it but alot of people who run/support databases aren't DBA's! They were either thrown into supporting it, or had an interest but its not their 'job'.
I've been a DBA for 8 years or so now and I encounter this problem all the time. Once I had a dev. group's call a meeting with us to find out what services we offered. The developers obviously didn't want to be there and were very vocal that they didn't need our services.
My first question was how did they backup their database? (They were running Oracle..)
Their response, "Oh, we let the filesystem backup catch it."
I responded, "Do you shutdown your database first?"
Them: "No"
Me: "You need us."
Save yourself the hassle, if you have a database that is critical to your business, hire someone that knows the internals. Whether its mysql, postgresql, db2, oracle, mssql, your going to save yourself alot of headaches.
Yeah, I know, DBA's are cool and its fun pretending but seriously, save this stuff for the experts.
I'm of the opinion that alot of database applications could run just as effectively off of flat files because most apps don't use the advanced features of RDBMS's. Thats why mysql is popular if you ask me.
"Thanks to the remote control I have the attention span of a gerbil."
Project requirements change. That is a fact. Your project may not be 99.9% selects anymore. Inserts and updates may become more important. Maybe you want to add a lot more concurrent database clients? In those situations, MySQL turns into a dog compared to other options. When one engine (or operating system) doesn't cut the mustard anymore, it's a question of whether the transition costs are tripled or not.
Then there's the case where you are not the end user, and the client already has a database they are happy with and/or have trained personnel to maintain it. In this case, MySQL is more expensive for them.
Most MySQL advocates say that they don't need stored procedures, views, triggers, etc. in the projects they do. Fair enough. But what happens when you come across a project that does need one of these? Oops! Sorry. You're married to MySQL.
What's that? Stored procedures aren't portable? Mostly that's correct, but they aren't all fundamentally different. In fact, Oracle's procedural language has more in common with PostgreSQL's default procedural language than MySQL has with the SQL92 and SQL99 standards. And porting stored procedures are a damn sight easier than trying to port the custom MySQL functions people write in C in a MySQL-only API.
MySQL fits your task the best? By all means, use it. But tying yourself inextricably to it? Better get the first-aid ready because sooner or later, you're gonna get bit in the ass for that decision.
I agree. I also agree that you don't need to use every feature and technique at your disposal on every project. But that's what MySQL requires much of the time. Your application layer grows in a couple of places when you don't have CHECK constraints in your database. You know what CHECK constraints are, right? They're one of the things that MySQL happily accepts in the CREATE TABLE query, but silently ignores because it's not implemented.
People say to rely on the app layer to make sure your data is correct and that when MySQL fails silently, it's your fault. If that is so, what happens when a project has more than one developer? Do you know the other's mind? Do they know yours? Gotta rely on good communication, hunh? Wouldn't it be better if the database threw an error during development so that you two were prompted to converse on the subject? Or are you one of those "good teams mind-meld" individuals who discounts that there are different skill sets and expectations on any project.
Just make your app layer better? If that is so, why not have a database backend that actually catches the errors so you can fix your app layer where broken?
Still want things more loose? Here's an idea: don't use foreign keys or check constraints. No matter what database you use, you don't have to use every feature. It's good to know that the features are there if you do need them though. MySQL is a leap of faith that you will never need anything more. There is a big difference between the two camps.
- I don't need to go outside, my CRT tan'll do me just fine.