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
Yup, exactly like PHP that is probably the main cause of its popularity
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.
Atleast it's a free product that has been adopted as the 'standard' unlike any poorly written MS product.
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
What? Netscape was *far* ahead of Microsoft in getting a browser out. MS missed that market by a longshot. Not that Netscape didn't suck. :)
As opposed to what? Oracle? ROFL!
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.
Maybe they were far ahead, but now when you sit down at 97% of computers in the world and look for a web browser, what are you going to find? Internet Explorer. By winning the browser war, they earned their place on everyone's desktop, and earned their place as everyone's pit of insults. MySQL, in a way, has suffered the same fate.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
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
Wow. Almost the same post I saw earlier today. Please stop posting the same stuff, replacing only the topic of the paragraph.
You said the reason the web took off was because of IE. It was actually quite popular well before IE was ever forced down our throats.
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!
mod down asap
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.
well let's think of it this way, what would have happened if microsoft never wrote their own broswer, but barred netscape from producing theirs? (yes, microsoft didn't have as much leverage as it has now, but it still could have bought netscape long before AOL did..) simply, competition drives innovation. And usually the competitors both have their weaknesses..
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
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.
It's FREE.
$49 for developer edition. You think that is expensive? Even the enterprise version is only $1200 or so (per CPU)... MUCH cheaper than Oracle
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.
Fair enough, and I'm not saying you're wrong. The web is obviously more popular today because of IE than if it had never existed. However, it was still popular and quickly becoming more so before IE was first released.
Therefore, the popularity of the web cannot be laid squarely on Microsoft shoulders, and I'd say it's not even primarily Microsoft's doing as Microsoft never got into the market until after they realized what they were missing.
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.
It grew so fast 'cause it had a huge memory leak, of course. Fixed in the most recent version of course.
/. to go down all these times. Upgrade already, Mister Taco!
Like we never knew what was causing
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
You probably also answered your own question. The reason why 4.1 is barely getting out of alpha is because 4.0 was their stable tree, and they're now working on their development tree, 5.0. My guess is they just don't have enough people who are willing to still work on 4.1, for 4.1 to be worthwhile. Wait for 5.0 is my advice.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Dear mabu:
Yes.
Love,
Larry Ellison
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
It's a fucking mess, and that's all there is to it.
it has no separation between syntax and libraries - making it a complete nightmare to compile and install if you want to enable as many features as possible.
They should have designed it so that the language interpreter could be compiled, and then you could add extensions without recompiling PHP itself.
PEAR is a step in the right direction, but too many things still rely on built in extensions.
and WAY too many programs use the mysql_* functions directly.
Those things are an abomination to good design.
Why the hell should you have to completely rewrite your code to support a different database in these days?
Here's an 'embedded ask Slashdot' for everyone, as I haven't found such an animal online.
Is anyone aware of a quick guide/tutorial for MySQL that is aimed at Sybase administrators? It would definitely save me some time getting my act together with it...
Thanks...hopefully someone knows of such a beast!
meant to say 'can't figure out how to pronounce MySQL', not 'spell MySQL'. Dangit. I previewed it twice, saw nothing wrong, submitted it, saw the error.
Standing at the very edge of my imagination, I peered into the inky void and realised -- I couldn't think up a new sig.
Because, until fairly recently, it was quite likely that one's data would eventually become corrupt. This is no longer the case, but MySQL still doesn't offer all that PostgreSQL does.
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
I use it on my server. It has no problems that I can detect... Can you give any reasons that it sucks? Hmm? Thought NOT you moronic troll!
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
Slashdot uses MySQL. Personally, I wouldn't class slashdot as a "toy" site.
You do not get the point mister. PHP is a highly customizable, fast-rendering and highly scalable platform. You should give more respect to these fine working American developer teams and help them a bit if you have better ideas than them. They are wise enough to take them under consideration.
-BW
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.
Well let's think of it this way, you could say that same thing about /anything/. What if Coke never made Coca-Cola and at the same time bough Pepsi and stopped them from making Pepsi. The world would lack brown beverages.
Microsoft definitely had an effect, but not because they didn't buy netscape and cancel the browser project and then made IE. They had an effect because they made their browser FREE (forcing Netscape to follow suite), and bundled it with almost every desktop computer sold.
That's excellent! The arrogance of the MySQL developers is astounding. Do you happen to have a link with that documentation for posterity?
(Moderators, feel free to mod me down, but please mod up the anonymous parent. Thanks.)
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.
Windows 95 did come with a TCP/IP stack and a PPP dialer. In fact "get on the internet" was probably the #1 thing that sold Win95.
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.
No, because the world would still enjoy drinking my liquified shit.
Yeah, it would be a real shame if your comment disappeared.
Slash also has a big data caching layer in Perl.
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".
... but you can give them to the birds and bees.
Hey Bernie:
PHP is a complete frigging mess. People use it because it's a free alternative to ASP, and there are many open source retards that write free PHP software.
However, these same retards are trying to use PHP for something it was just not meant to do. It doesn't scale well at all.
ASP is a much better product, but you get what you pay for.
and WAY too many programs use the mysql_* functions directly.
Those things are an abomination to good design.
Why the hell should you have to completely rewrite your code to support a different database in these days?
You make a very valid point. In ASP I would only have to change about 3 lines in the entire script to switch databases! Not so with PHP!
Our critiques are mutually exclusive my very dear sire...
- Bernard Wolkacz, Ing. PhD Wien
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.
So true. MySQL is fast as long as it's not ACID compliant. Want transactions and ACID? MySQL just got slower. Want concurrent DB access for multiple users or multiple sessions? MySQL just got slower. Want to use MySQL for mixed select/insert/update activity? MySQL just got a lot slower. Want to use MySQL for complex queries or many table joins? MySQL just got a lot slower. MySQL has a built in speed advantage because it's so feature poor. Less features means it has less code. As they add more features, I fully expect performance to continue to decline in all areas.
Basically, the only speed advantage that MySQL has over other DB's is when you have an select only environment with little to no concurrent activity. Once you exit that criteria boundry, other DB's suddenly perform as fast or faster. The further over the boundry you get, the better other RDBMS options look. Best of all, the other DB options tend to be feature rich to boot.
The fact that it's simple, easy to install, and cater to people that don't know a DB from a spreadsheet, is all you need to know to understand why MySQL is so popular.
PHP is a highly customizable, fast-rendering and highly scalable platform...
Simple. We need to ask our expert in Open Source pronunciation... Mr. Torvalds?
Actually, one of the things I like about Postgresql is that it can run on Windows (under Cygwin). It's almost as simple as: Run SETUP.EXE. Certainly I would not recommend this for a production environment, but it does work for development. Would you even think about running MS-SQL on Windows 95 / 98 (notice I did not ask if you would think about running Windows 95 / 98 themselves). :-) Yet I was able to run Postgres using Windows 95 under Cygwin to develop a solution on a low end laptop.
(also available as a Windows binary).
Postgres does need to work on this area though. Many people don't realize how easy it is to install Postgres under Windows and the fact that it doesn't allow TCP connections out of the box doesn't help matters either (particularly since this is all you will be able to use under Windows).
Add to that the ODBC drivers that allow MS Access programmers and even MS Excel users to query the database and Postgres really does work with the Windows world.
What they haven't offered (until recently) is a GUI to manage / view the system. But check out PgAdmin at
http://www.pgadmin.org/pgadmin3/download.php
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.
25!
Why?
There have NEVER been that many at one time before.
And there's no GOOD reason for it, as the ol;d stories are, well...old...and they are now of little interest.
So why are they still there?
Is it because somebody wants to maximise the exposure of the last story, the one about Raven Alder, the chick who wears black and can "work Linux real good"...?
.. 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
You are not a very not cool new guy. Go back to AnandTech you silly bint. THATS RIGHT GO BACK TO ATOT.
Comment removed based on user account deletion
Personally, for mission critical stuff I would not trust MySQL or Oracle or PostgreSQL. I would just add another column with a MD5 sum or whatever. Then integrity can be checked in a reliable fashion (by mysqlf).
One thing I will say about IE is that it was the first browser that felt stable enough to use for "real work" -- intranet applications and the like.
Netscape was OK when the web was in its toy stage, but you would never have seen as much commercial adoption with that crashy POS.
Wow, that's really overkill unless lives are at stake. If you're just dealing with millions of dollars (like I am) MySQL has shown to be perfectly acceptable. We just passed multiple financial audits.
Cheers.
I'm not sure about Oracle, but I'd be surprised if this isn't true for it too. That is, PostgreSQL has some type of checksum or hash or something, I forget which, on data pages. So, if you have a corrupt row, it will be caught at the page level.
Doing it your way, on PostgreSQL and probably Oracle too, is adding extra work which is already being done, AFAIK.
IE won but not in a war. What war? IE was preinstalled and the majority of customers didn't care what it was as long as it displayed web pages. Netscape never stood a chance. And sigh... WMP will now repeat the story. In another non-war.
I need money.
Hammer of Truth
You know, I've read this soo many times from MySQL users, talking about PostgreSQL. I'm constantly amazed. There is a readme file while walks you throught it. There is online documentation which walks you through it. There is an online administrators guide and WIKI documentation available which not only walks you though it, but adds insights and additional comments.
Can someone please tell me why so hard about reading 5 pages, or so, of instructions?!?!?
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.
Actually, MySQL (with InnoDB) has this as well. Each page is checksummed and any error brings the DB down. I actually had a bad memory chip once that triggered this problem a few times before we figured it out. That sucked big time... but no data was lost that we can tell.
Cheers.
1. Bovine growth hormones in its milk
2. Possible steroid abuse
= 9J =
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?
Plus, it was fast and everybody chose speed over the true purpose of a database that consist of the ACID test (Atomicity, Consistency, Isolation, and Durability,) which PostgreSQL had.
who gives a fuck
not everyone
oh and mysql isnt acid complient, you forgot that one,
cause a lot of people dont give a shit either.
it works for somethings, not everything.
but i guess postgresql is the save all right?
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"
Thanks. I didn't know that. I'm honestly not surprised as it is simply, just the right thing to do.
IIRC, Postgresql also has checksums (or whatever), elsewhere within various pages and data structures, but the page level is the only I mostly clearly recall.
I agree with the AC post above. I've used PostgreSQL before and I love it. Try reverse engineering (get lost billy) and replacing a [proprietary] MS SQL based app that uses cross-table relationships heavily with a MySQL based app. It was easier with PostgreSQL.
There's nothing theoretical about getting wrong answers (rather than errors) because you left a table name out of LOCK TABLES and started seeing incomplete updates, or used a FOREIGN KEY or CHECK constraint that your configuration silently fails to enforce. In practice most people don't notice because their amateur data models don't contain enough redundancy to tell them when their database is lying to them.
Actually it doesn't make much sense to have two "development" versions. They might just as well scrap 4.1 and put all their effort into getting 5.0 finished ASAP.
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.
Maybe he meant to say that MS did not install a TCP/IP stack by default. ab_iron
Bzzt, wrong. This is getting offtopic, but Windows 95 was in fact the first version of Windows to be shipped with an IP stack from MS. Before then it was Trumpet Winsock or a number of other commercial stacks. You're right about the focus on the original MSN service though. And despite MS's attempts to rewrite history, IE only started shipping with Windows 95 OSR (OEM Second Release) in '96 or '97 (can't remember exactly).
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
Thats not PHPs fault. You can write database independent code in PHP to.
.'_query';
$shrtFunc = $DB->get_ctype()
$res = @$shrtFunc($sql, $DB->get_conn());
This are a couple of lines from the database library I use. As you can see the value returned from $DB->get_ctype() can i our case be either mysql or sybase. And it's very easy to add support for more.
Yes, and fairly often the DB server goes down and you can only view static content. Slashdot isn't exactly the greatest marvel of software engineering in the world.
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?
Your MCSE, MCDST and MS Office certifications are worth as much as the toilet paper roll stack in my closet.
You want to talk professional, how about something that took serious time and energy to accomplish, like a Masters of Science or a PhD? When you accomplish something that difficult, then I give you full bragging rights for your accomplishments.
Claiming to be an industry professional because you have Microsoft certifications is almost laughable, but I won't laugh because I want you to retain some semblance of dignity.
17. Well it's MINE, innit? Says so in the name. _MY_ sql. Ya gotta like that!
Seriously, I think a good name is half the battle with acceptance. If Postgres had called themselves MySQL -- rather than "Huh?" as most people understood them to mean by their Ingres-derived title -- and then produced some half-decent documentation occassionally...
But they didn't.
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!
You are absolutely right. However, what PostgreSQL really needs to become mainstream is a native win32 port with point-n-click installer. This has been scheduled for release 7.5 or 8.0.
For the gui DB design tool (partic with apache + php) the option of choice would be PhpMyAdmin.
I say we take off and nuke it from orbit. It's the only way to be sure...
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
I guess you arrived late in the game. Up until somewhere between version 4 or 5 of internet explore Netscape were generally considered the most stable and better browser of the two. The only reasonable use of internet explorer back then was as a tool for downloading Netscape.
Ceterum censeo Microsoftem esse delendam
That's very interesting, because given the choice I would use notepad. That's what 3 years of HTML, PHP, and MySQL editing will teach you. Simplicity is wonderful.
An industrial strength FREE database. : )
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.
MySQL succeded because it took an 80% approach (a.k.a. "worse is better") whereas PostGres took a 100% approach (a.k.a "the right thing").
If you don't know what these mean read: http://www.dreamsongs.com/WorseIsBetter.html and http://www.jwz.org/doc/worse-is-better.html
a relevant quote: "The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing."
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
One of the reasons I use MySQL is because it's easy to deal with remotely. phpMyAdmin is a robust tool for working with an online database. The phpPgAdmin tool is way behind in features and usability. I have one site on Postgres, but it's a lot harder to work with because of this.
If you can do that then I would guess you don't do many queries, and they aren't very complicated either. Switching databases usually involve checking SQL query and rewriting some of them to fit the new database idiom, because no database seem to agree on how to interpret SQL.
Because Postgres doesnt support native Windows
The day PostgreSQL is even half as well supported as mySQL, maybe I'll switch. My issue when adopting stuff like this is what tools are available for it? I could care less about how poorly designed it is. It works. It's well supported by the community and other software vendors. You people are bit snobs.
This signature has Super Cow Powers
I'll still stick with PostgreSQL, but then I am a Mac user ;-) I look at MySQL like I look at Windows... popular and sort of what I need, but it still falls down on the job.
If we can't fix it, we'll fix it so nobody else can!
Any language that allows includes to be passed both variables and URLs is not good in my book. I've seen many a cross site scripting exploit used against PHP scripts (most of them in free message board systems), and most of the time it results in the attacker executing arbitrary commands as whatever user PHP is running as. Yes, the script itself can verify that its information is correct, or at least exclude the malicious information, but that burden shouldn't rest on the scripter every time he wants to include something, IMO.
I like postgres but the ability to keep it online 24/7 cost us a trip to the oracle camp I am afraid. We ran our manufacturing floor on it but had problems with scalability and keeping it up 24/7. I still to this day have to sit down and run vacuum on all of the databases on sunday night right before first shift starts. We where running a dual zeon box
with about 200 connected users running simple small selects and it would just bring it to it's knee's. I had the developers change the app to always drop the connections and this helped a little bit but I still
had the problems with vacuum. Running vacuum with the user connected just brings the database to a near halt or locks them out all together. Not running vacuum causes the database to come to a near halt in under 6 days
If I had to do it again I would go with mysql. I should not have to babysit a database every week and it should be able to handle more that 200 read connections on a dual zeon 4gb ram box.
Got Code?
INSERT INTO Body (Stomach) VALUES ("Vegetables")
For the sort of simple, single-user applications that MySQL is frequently used for, I don't understand why SQLite isn't used more often.
It's fast, simple, lightweight, and completely free, with no licensing restrictions prohibiting it from being incorporated into commercial products.
Am I missing some reason why it's unsuitable for most people?
In a way. The question is "What is good enough?" and "Solves what problems how well?". For me, the design problems in a lot of commonly used software (MySQL, perl, the pre 2.6 Linux VM, autoconf, the FreeBSD mergemaster tool, the Windows registry, the language SQL, ...) have bitten me, and in some cases keep biting me on a daily and weekly basis.
Of course, each of these have strengths that have made them be major players in their niche in the first place. This include
Note that I do explictly NOT list being a more efficient or better system overall. People are generally reluctant to take any larger investment of time than they have to, even if that increase overall productivity. The gains have to be perceived as large and fairly immediate before taking the time investment.
So - in my evaluation, "poor design" is important. It gives continious costs *and those costs tend to emotionally bind the users to the product with the flaws*. However, poor or good design is not important to whether a system gets adopted or not. , if it isn't so horribly bad that this is immediately obvious.
And to get back on topic: With MySQL, what I really hate is that it make up data in order to make sure inserts pass. This has made much more trouble for me than any of the other issues - the other issues are easy (though a lot of work) to work around and keep in mind, but accepting bad data requires a ton of verification at the DB-interface layer of the application - and this is non-obvious, and have not been implemented in a lot of code I have had to work with :-(
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
> Reasons NOT to Use Foreign Keys constraints:
/.ers will understand. Imagine Bill Gates saying the following about the Windows XP firewall:
> The speed impact is terrible for INSERT and UPDATE statements, and in this case almost all
> FOREIGN KEY constraint checks are useless because you usually insert records in the right
> tables in the right order, anyway.
Just thought I might put this in a context that non RDBMS experienced
"Reasons NOT to monitor outgoing network traffic:
The speed impact is terrible for monitoring outgoing network traffic, and in this case outgoing traffic monitoring is useless since almost all outgoing network traffic is benign in nature anyway."
Now be honest, would you think "what a prophet is this guy, he's absolutely right", or would you look for another firewall?
That is where the lack of respect for mySQL as a RDBMS is coming from. It is no RDBMS, but they try to sell it as one.
As for its worth, sure, mySQL can be a decent package to use... if you are looking for a storage system with fast retrieval possibilities, not if you want a RDBMS (or SQL DBMS for the purists) that safeguards the integrity of your mission critical data.
lol
I work with mysql as an persistence backend for
my (Jboss) application server, which works ok.
The last application I developed makes use
of J2ee transactions, and it turned me nuts to see
that the rollbacks weren't working. It took hours
before I realized that the problem was that I didnt
use transactional safe table-types (my fault so far).
Should mySQL tell something like 'not supported' to the application server on a rollback command
rather than silently ignoring it ? Besides, with
exentsive caching, this can lead to an inkonsistent cache (Jboss rolls back in cache, DBMS didnt...).
Stefan
1. Free
2. Easy
3. Free
4. Simple
5. Free
6. Easy to remember
7. Free
I'm in the hole of the broadband donut.
SQLite is targeted at a totally different audience.
SQLite is tiny SQL engine, easily embedded (and also scripted) from within an application. Its single data file concept is more along the lines of M$ Access.
My immediate reference to playing with SQLite was a direct replacement in Linux of the VB+Access application space.
Its a neat tool, very usable, portable, easy to work with. But not a competitor in any way to MySQL.
http://www.sqlite.org
JoeR
>webserver "Red Hat" >Who do you think we professionals trust more? Professional what? Since you don't even know what Red Hat actually is can we assume your profession is something along the lines of lavatory attendant?
---
We spoke for about a half an hour. I don't recall a thing we said. - Colorblind James Experience
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
Running postgresql in Windows is nearly impossible.
The trolls have already sounded off about MySQL's lack of transactions and the like. Fine. But if you're getting started with SQL and need a database that has thorough documentation and some speed under the hood for that niche of folks, then MySQL is da bomb.
And that's just the point. Database needs have left the castle walls of the big iron, elitist enterprise. Lots and lots of personal and SOHO solutions to meet, and MySQL can be the tool for those people. Get over it.
I repeat: the MySQL documentation is what draws a lot of people in.
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.
Renaming PostgreSQL to YourSQL
Oh come on now!
You're a Oracle DBA so of course Oracle is just as nice as MySQL for "ease of use". But please! Oracle is the worst, most painful, most obfuscated piece of shit software I have ever seen with regards to administration!
It's terminology is obtuse, it's "help" is a joke, it's fragile as shit unless you know exactly what you're doing, and it can crash horribly and not come back up.
Please.
Not everyone wants to have to pay a damn DBA (nothing personal mind you) to run a simple DB-driven app. It's sad watching all the haters moan about how MySQL isn't this, isn't that... all things it's not MEANT to be.
This is why I chose MySQL or PostgreSQL. I needed it to run on Win32 natively without Cygwin. The problem was the install. Using PostgreSQL (which I used in another application) is not a problem. Hell, it's even easier than using MySQL. It's the install on Win32 that was the pain.
But if the installer is in the future, PostgreSQL will rightfully take its place at the head of the Open Source databases. I've used PostgreSQL, and I know how good it is. It has a lot of very nice features (not just the SQL syntax). What it came down to was the ability to install it and get it running quickly.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
MySQL is easy to install. I develop on Windows because I have to support lots of legacy products. MySQL has a windows setup exe. Download, run, it's installed. Simple, easy. It's not ACID compliant, but most people I know still thing MS Access is a Good Thing. Microsoft and McDonalds prove people don't want quality, they just want to get by easily. Ease of use wins most every time.
Windows still has 90% of the market and if it's not easy to install on those computers then how can any software program hope to achieve a large user base?
PostgreSQL does have a "windows proof of concept" that requires a Cygwin installation. It is a pain in the but to get running on Windows. There is a native port in the works, but it's basically replacing Cygwin with MingW.
If I want I can download source and tons of other libraries I can get a work in progress running which failes several of the regression tests. If it's challenging for me to do it though, there is no way I'm going to require clients to do it.
Check out the Windows Status Page
I have been dying for PostgrSQL to come out with a windows port. I've used it before and love it. I would love to port my MSSQL Server apps to it. ACID compliance is a real requirement in some applications, but in general people get by without it because most people don't even understand what it is.
I'm not sure why nobody picked up on simple ISAM systems like Berkeley DB
Very good point. It was only recently when I was figuring out the backend to OpenLDAP that I realized the potential and suitability of what I called "hashing databases" for web content and much simple content. Heck, even MySQL realizes it because they simply put a SQL engine on top of a BDB database.
In retrospect, Perl hackers love hashes and I think they use them in a similar way to BDB.
My guess is that for most computer newbie types database was synonymous with SQL, and we wanted to work with the cool stuff.
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.
Couldn't you have done the work with a FOSS database and then import to Access for presentation? Or use ODBC to use Access as a front end to a FOSS database? Would anyone have noticed?
These days my attitude is "get the job done, and if they want to fire me for it, fine."
I build Postgresql on my Linux 486 years ago. Not one bit of trouble doing installs on lots of computers since. I don't understand the complaints about install troubles.
MySQL however recommends not compiling, but using pre-built binaries because of limitations and compatability problems with compilers and libraries. This is very undesirable from my point of view.
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."
My database is free.
;)
Ahh yes but my database is bigger.
Nope my database is faster.
Yeah but my database works on all platforms.
Replace database with wang and there you have it.
I mean come on guys put them away after all we all know its not the size of your database that matters it's how you use it
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
gee, in java I just use a different connection object that about 99.999% of the code won't change.
PHP is the solution of choice for relaying mysql errors to web users.
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."
1. There is a main company pushing mysql in the news and striking deals with other big companies such as Veritas and SAP. They appear to have a sales force that is very active. I rarely ever see anything w.r.t. postgres in the news. 2. Postgresql doesn't really support windows. I know, you can get it to run under Cygwin but most people don't want to hassle with that. They want native support. Is postgresql a better database? IMHO it wins handsdown but as we know there more factors to whether or not software gets adopted.
"Thanks to the remote control I have the attention span of a gerbil."
Now, I think he meant to simplify, but that's such an oversimplification that it's just wrong (and it's wrong in such a way that, by misunderstanding, he would stand to profit).
Anyone can choose to license MySQL using the GPL, which grants the freedom to earn as much money using or distributing MySQL as you like (so long as the other license provisions are followed).
You only need to pay for a license if you want to do something that the GPL doesn't allow, like "distribute without offering source".
" Pardon my ignorance, but what is it exactly that MySQL is good at that Postgresql isn't at least equal or better at?"
Completely amazing that no one has *adequately* answered you on this question. i see responses of people whining that "you are not everyone" - yeah, not shit, genius. Or, "by god the package that i wanted to use needed mySQL" - nice. Way to *not* answer the question asked, fella. You didn't ask why people *chose* mySQL, rather what it does *better* than postgreSQL.
Once again, Slashdotters have missed the point entirely, correcly answered the question *not* asked and generally been useless except reminding you that you are not everyone...like, maybe you didn't already know that or something.
Seriously people, buck the fuck up and answer this question:
What is it (exactly) that mySQL does that is better, faster, or more stable than postgreSQL?
Leave your little app-requirements and need-it-for-legacy whinings out of it. Answer the question.
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."
Damn, if I hadn't posted to this discussion I would have modded you up. You hit the nail on the head... Alot of people in IT don't understand the big picture... Whether its through sheer ignorance or systems being so complex that you just can't know it all. And i'm afraid, seeing how software development is proceeding, its only going to get worse.
.Net etc, etc. The list grows more each day.
When I was in university people coded in C/C++ but now its Java, JDBC, SOAP, CORBA, XML, STRUTS, EJB's,
"Thanks to the remote control I have the attention span of a gerbil."
>> Windows 95 was in fact the first version of Windows to be shipped with an IP stack from MS
Your correction is incorrect. Windows For Workgroups 3.11 shipped with TCP/IP (no PPP dialer), as did every version of Windows NT.
> I guess you arrived late in the game
Sort of, my first browser was Netscape 0.9. Never used Mosaic much.
> between version 4 or 5 of internet explore
That's what I'm talking about -- circa 1998, when intranet and "b2b" applications started becoming really popular. No version of Netscape matched IE 4.01's stability until 7.x which shipped last year. Lots of people use web apps 8 hours a day for business critical tasks -- never would have happened with crappy NS3 and NS4.
Well, having set up postgres on cygwin rather recently, I can say it's not as simple as all that. If you want it to run as a service, for example, there are quite a few hoops you have to jump through.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
Postgres seriously lacks decent replication. MySQL has kick ass replication.
You are so right.
/etc/init.d/postgresql start
I guess I can see the argument for Windows, but *nix boxes? Is everyone trying to install from source. Obviously this is not the audience we were talking about. Nevermind that by source is not all that difficult either, with a package manager, it's downright embarrasing how easy it is.
Step 1: Install
% su (or sudo with the command)
% apt-get install postgresql-server
- or with apt-rpm -
% apt-rpm install postgresql-server
- or with just any old RPM -
download the RPMs and run
% rpm -Uvh postgresql*?
Step 2: Start the postgresql server.
% service postgresql start
- or -
%
Step 3: Add your username to the postgres group.
Step 4: Become the normal user again.
Step 5: Create a database as that user
$ createdb <dbname>
Step 6: Connect to the database
$ psql <dbname>
Step 7: Start making SQL queries -- standard SQL99-compliant queries at that.
Can a MySQL advocate please explain how it would be easier to install MySQL? Please?
Which brings me to another point that MySQL folks love to make: there's more documentation available for MySQL. Okay, we've established that installation is a non-issue. What about usage? With both, you connect via a client and make queries. MySQL has some weird syntax and tragic quirks, therefore it's a good thing that there's a lot of documentation. PostgreSQL? Sure there are comparatively fewer books with "PostgreSQL" on the cover. But then, since it closely follows the well published SQL92 and SQL99 specs, most books titled with "SQL" should suffice. Take the books that teach to the spec versus books that teach MySQL's dialect and the scales tip in PostgreSQL's favor.
Has anyone else considered that PostgreSQL books simply aren't as necessary as MySQL? Books solely on MySQL should be renamed to another popular O'reilly series: the series with "Windows XP Annoyances."
I guess the reason they don't is that MySQL diverges so much from both SQL92 and SQL99 that you might as well not compare the two; It doesn't look too good to describe a complete product as an annoyance.
- I don't need to go outside, my CRT tan'll do me just fine.
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.
It never taught you that line numbers are a very important feature?
This is funny when viewed with your "cheap shot" earlier. When developing for yourself, you can use whatever is easier at the time whether you are an experienced DBA or not. When developing for others, the clients are saying, "We can't do good database work. That's what we want you for." They are paying you to be "aware of the logical capabilities of the relational model." Only they of course will never say this. They will simply say, "I want a reliable system." It's up to you as a developer to translate.
It's like when someone says, "I want my web page to be easy to use." They usually mean, "I want my web page to always stay up, have a logical, easy to navigate structure, be consistent, and yet deal with my color-blind sense of style and gaudy logo." Do you make a web site like someone who has never made one before (because the client doesn't know, why should you?), or do you follow all of their guidelines and yet still try to make one that can actually stand the test of time?
People pay you to be more knowledgeable, not as knowledgeable or less knowledgeable than they. This is not to say that you should disregard their desires. This is saying that when they can't tell the difference, use the better materials just because you know better.
- I don't need to go outside, my CRT tan'll do me just fine.
Thats exactly what you can do in PHP too you know. The code was taken from a database class.
But you are completely ignoring the fact that a wide variety of bicycles, motorcycles, cars, and trucks are available.
Are they >95% select statements? That's probably why. If your projects were more insert/update oriented, you wouldn't be quite so glowing in your praise. It also raises the question: have you used anything else? Have you used another RDBMS package or are you simply assuming that because MySQL was easy to setup that all others must be harder?
Try out PosgreSQL for a short time. It's free as well. Get any one of the books for PostgreSQL and go through the exercises/examples. Trust me. If you are coming from only MySQL experience, you will have quite a few "I didn't know that was possible" moments.
The worst thing that'll happen is that you will choose MySQL based upon an informed decision related to the job at hand. The best thing is that you'll have expanded your toolkit and opened the door to a much greater variety of database engines. (PostgreSQL is more like all of the other popular RDBMSs than it is to MySQL.)
- I don't need to go outside, my CRT tan'll do me just fine.
BWHAHAHAHA... "The first disadvantage to using Foreign keys is that we don't support them."
How exactly is that a "disadvantage", and not a "our software isn't up to snuff"??!?!
MySQL is easy to install
Bullshit. Postgres is easier to install.
What you are talking about here is a preference.
It is a pain in the but to get running on Windows.
OK, there you have a point. But then Postgres isn't a Windows app. You should have just said "Postgres doesn't support Windows", and left it at that.
Scalability isn't a database feature; it's a total app feature. Most people can't write scalable code (heck, no one can for a given value of "scalable"); thus, the advantages of Oracle (or even PostgreSQL) are wasted on them. For these apps, MySQL has no significant drawbacks, and quite a few advantages.
Remember, there are a lot more "little times" than "big times".
I had win 95 + Office 95, and I wanted to learn JDBC programming, so here is what i did.
Create a Excel spreadsheet and used MS ODBC + MS Query to define a query on the spreadsheet. Juse Sun's JDBC-ODBC engine to query.
That was the best JDBC self training I ever got, after that Oracle, Sybase etc were piece of cake.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
Design does matter. Usually it won't be noticable until some specific event, but when that event happens (and it will), you'll get burnt.
What you do after you get burnt is entirely up to you. Some change products, some deal with loss of information, some work to recover what they had, some didn't have data important enough to bother with anyway.
The more work you do to discover "why" the more you'll view MySQL's rationale as excuses instead of revolutionary minimalisim. Soon the banter of "work around the problem", "Not necessary if you do this and then that", "Bad for performance when you could just do this", etc. will come off as shallow excuses for fundamental problems that have been solved since the 1980's.
Lacking good design doesn't matter until failure. Good design is what you apply to prevent failure or at least mitigate it's effects. In the Ford Pinto's case, the car's inherit ability to turn into a ball of flame didn't matter until someone hit it from the rear.
Professionals (in any profession) are held to a higher standard. Arguing that a "good" design is wrong is one thing, arguing that a "good" design is irrelevant is tantamount to negligence. Compromises to "good" design should be made, but only when they are understood and "give" you something in return.
Choosing MySQL gives you little (speed) and asks for a lot (you do the work an RDBMS would in your code) in return. New DB people won't know the difference, until it's too late.
They amount to a trap door into an unknown amount of code for an insert or update. Sort of like the "COME FROM" construct in INTERCAL. In large database systems involving multiple development groups they can become an interaction nightmare; killing performance and having strange exceptions bubbling up from previously working code.
An esoteric scratched itch:
Homeworld Map Maker Tool
I am not singling you out to be jibed, but this is the third time in the past week or so that somebody has used "jive" rather than "jibe". In fact, I believe that this post is the first on /. to use the word "jibe" properly.
To counter this very un-/. behavior, I have left my misspelliongs intact.
http://dict.die.net/jibe/
http://www.wsu.edu:8080/~brians/errors/gibe.html
My god, you can't even do subqueries? What the hell? No views?!
Visit MySQL Gotchas for a list of the stuff you don't hear about mySQL around here.
MySQL is popular because it's easy to learn because it doesn't have all those "complicated" advanced features real databases have, so people who learn MySQL suddenly think they've become DB admin experts. Then they try Oracle or PostgreSQL or one of the other big boys, get confused and overwhelmed, and fall back on MySQL because it's easier for them despite having reduced functionality, often without them knowing that if they learned a real database they could do some incredibly powerful things with the braindead SQL they write to get MySQL to work. I've had to translate some Oracle single queries into as many as four for MySQL (!).
Seriously, that's why.
replication is a lot easier when you don't have to worry about transactions and data integrity.
You can buy decent replication for Postgres if you need it, for now.
Well, that's why we were audited. And we passed with flying colors. Apparently we're not getting too many wrong answers.
Hmmm... redundancy in datamodeling? I thought normalizing data reduced redundancy?
In any case, we have cross checking scripts that monitor data integrity and they do more than could be reasonably done via SQL anyways.
Cheers.
I'd say you are what most people consider to be a gullible bloke, if you think the parent was not pulling your leg.
I find your attitude (and most MySQL trashers) very interesting. My company is accomplishing amazing things with MySQL. Moreso than most companies ever accomplish regardless of the DB they use. But somehow you feel the need to save me. Anyways, I'll answer your direct questions:
We run about 75% selects. Our 24 hour average is bit over 200 queries per second.
I have used Oracle extensively. In fact, that's where I learned SQL and DB design. I know all about triggers, foreign keys, PL/SQL, etc. I prefer to build with MySQL.
I know it must really bug a lot of people that such a simple 80/20 database solution is proving to be the best tool for the job to so many people. Sorry.
Perl, ugly as it is, is more useful to me than Java, too.
Cheers.
Because Microsquish and Orihole are just too damn greedy on per seat licensing. Anything more than 5 seats I use MySQL for.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
It's not that the fact it doesn't support basic features of other databases that bothers me, it's the fact that the developers openly discourage the need for those procedures, thereby pigeonholing you into coding their way and removing your choices.
What if I want to use stored procedures, even if they think I don't need them? You can implement them and still tell me they're bad (we're ignoring the fact that such an opinion is laughable), while still giving me the CHOICE to use them if I want to. They're friggin' standard SQL.
If a feature's not implemented because you haven't gotten to it yet, that's fine--I can understand that. It's free software. But don't sit there with a thumb up your ass telling me I don't need it when I say I do.
It doesn't bug me that your solution works for you. The fact that you know the difference between databases and still find that MySQL is the best tool for the job speaks volumes. I am curious as to what aspects of MySQL you find to be superior to Firebird or PostgreSQL? I would honestly like to hear them.
I'm also curious about the 200 queries/sec. You have a setup with 50 inserts, updates, and deletes per second? I am indeed impressed.
Don't know where this came from, but good on you. If you're taking in values, running matches and substitutions, running queries against them, and sending off again, Perl is a great tool. I never would have thought ill of you for it.
- I don't need to go outside, my CRT tan'll do me just fine.
More apps means more MySQL installations. More MySQL installations means more apps. Wash. Rinse. Repeat. It's the same pattern followed by MS Windows years ago.
Inertia is not altered by better products; It's reversed by the introduction of "killer" features that are simply unavailable elsewhere. PostgreSQL has the features, but unless people know and understand what they are, they will not be determining factors, Win32 or no Win32.
- I don't need to go outside, my CRT tan'll do me just fine.
I'm glad the solution is working well for you. Best wishes to you.
:)
:/ Still, yes, our system often hits 50 writes per second (and higher), though that is not maintained.
;)
Okay -- sorry if I got a bit snippy there
I am curious as to what aspects of MySQL you find to be superior to Firebird or PostgreSQL?
I don't know enough about those RDBMSs inparticular to say. I like MySQL better than Oracle because it's cheaper and easier to administer. I am familiar with the more advanced features that MySQL lacks, but these have not been an issue in my experience. Since it meets my needs I haven't searched for something different. Note: I am using InnoDB tables which offer transactions, and more importantly to me row-level locking for higher concurrency.
My "best tool for the job" rating includes the fact that it is already doing the job; which is not trivial. I certainly wouldn't call anyone a fool for using PostgreSQL for a similar task, but I don't see any compelling reason to switch. If I had started with PostgreSQL (my research indicated it wasn't fast or stable enough at the time) I might be singing its praises today instead of MySQL.
My aim is not to convert anyone else to use MySQL, but rather to shoot down the meme that MySQL can't be used for real work, which comes up in every MySQL thread on slashdot.
I'm also curious about the 200 queries/sec. You have a setup with 50 inserts, updates, and deletes per second? I am indeed impressed.
Whoops - I made a mistake there: we average 81% selects -- I was looking at the current (2 second) number as opposed to the uptime average when I posted
This is for Zappos.com. I'm the lead engineer there, and it has grown faster than I could ever have imagined. We actually run two DB's, a primary and a replicated server. Both run on the beefiest Opteron systems you could buy last year. The primary averages 186 qps with 81% selects, and the replicated server averages 33 qps with 26% selects -- though that's misleading because it has to do all the same writes as the primary but handles only a portion of the slower reporting queries.
Most of our writes are for our recommendation engine, which tracks user viewing habits in real time to offer shoe suggestions. This feature is not promoted on the site yet, though it is live in testing.
Perl is a great tool. I never would have thought ill of you for it.
Heh... I just threw that in because I've often been told that Perl is a doomed language by the same people who tell my MySQL is a doomed database. As I said in an eariler post somewhere, I lean towards the "if it ain't broke don't fix it" school. It has served me pretty well thus far, but I still bump heads with the purists from time to time
Thanks for you thoughtful replies.
This strikes me as the kind of stupid shit people are trying to get away from when they leave commercial databases behind. The "pay for GPL software because we say so" thing could get pretty interesting as MySQL becomes powerful enough to actually do wonderful things like sue their customers.
But I'm sure a software company would never do anything like that.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
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?
I'm sure it was said in jest, but 30 seconds of "research" gives us the following...
From MySQL manual, "The official way to pronounce MySQL is ``My Ess Que Ell'' (not ``my sequel''), but we don't mind if you pronounce it as ``my sequel'' or in some other localized way."
From the PostgreSQL FAQ, "PostgreSQL is pronounced Post-Gres-Q-L."
You can run MySQL and Postgres on the same machine, as they use different ports by default; so the situation is not quite as dire as you're making out. I would also hazard a guess that somebody somewhere has a My-to-PG syntax translator or even a set of patches to the Postgres source that make it accept MySQL's slightly-unusual quoting syntax.
...............
The points you raise are all valid, but only in a minority of cases. In probably 8 cases out of 10, MySQL provides everything the user is going to want. And if someone's application is beginning seriously to outgrow the capabilities of the database backend, isn't there a chance it might actually benefit from a complete, from-the-ground-up rewrite?
I feel the situation is best illustrated as follows.
PHP Programmer: Look at my new improved speedy potato peeler!
Java Programmer: Does it peel apples as well?
PHP Programmer: No, it only peels potatoes. Nobody in my family likes apples, so I didn't bother peeling apples.
Java programmer: Well, then; if it's hard-coded to work with only one kind of vegetable, it's obviously crap.
............... later
PHP Programmer: I have redesigned my potato peeler to peel apples, although it now takes half as long again to peel a potato compared to the original version.
Java Programmer: Well, that's a start, I suppose. So does it cut up the potato into chips after peeling it?
If it makes you any happier, I'd ditch MySQL in a heartbeat if I thought something else would be better in a particular application. And that probably would be Postgres, since we have a "no source, no sale" software procurement policy around here.
Je fume. Tu fumes. Nous fûmes!
MySQL was probably the "best" available free "RDBMS" with decent performance during the dotcom times.
msql? Didn't try it, but MySQL appeared to be a superset of msql (not MSSQL).
While more sophisticated, Postgres95 just didn't cut it performancewise- I tried both MySQL and Postgres95. Postgres95 was just too slow for what I wanted to do. Was slow for reads, was slow for writes even with fsync off.
Things changed dramatically with Postgresql 6.5.3 (ok for reads still slow for writes) then 7.0, 7.1, 7.2 etc.
Now I have far fewer reasons to use MySQL over Postgresql 7.3 or 7.4.
MySQL's new licensing scheme doesn't help either.
Too much trouble to figure out when it is GPL and when it isn't, or whether that sort of thing is even valid.
Come on, I'm sure you're Bill Gates, don't hide behind that Mike Bouma name :)
Granted it's slow, but you can code a relation database with the above UNIX tools. Why bother with SQL for small applications without rigorous speed requirements.
First off, where did Java vs. PHP come from in this thread? If you look at my list, it includes PHP ADO. My point here was that if database abstraction is just as easy and just as much code as hard-coding a particular database, why code for just one? I don't know what kinda crack you're smoking with that potato peeling analogy.
- I don't need to go outside, my CRT tan'll do me just fine.
Maybe you should pay attention to the logical parts of his argument rather than the rhetorical ones? Like:
Stored procedures provide a higher level of performance, and provide *MUCH* more scalability. It's just common sense - moving *all* of the data away from the DB, passing across the network, and to business logic in the application will always be slower than having the logic in the DB itself (where it can be processed without having to move it across the slowest link in the chain.)
I don't have mod points but I do have database experience with enterprise databases as well as with MySQL and I think I'd side with ajs on the subject of stored procedures.
--LP