Slashdot Mirror
8 Reasons Not To Use MySQL (And 5 To Adopt It)
Esther Schindler writes "Database decisions are never easy, even — or maybe especially — when one choice is extremely popular. To highlight the advantages and disadvantages of the open-source MySQL DBMS, CIO.com asked two open-source experts to enumerate the reasons to choose MySQL and to pick something else. Tina Gasperson takes the 5 reasons to use MySQL side, and Brent Toderash discusses 8 reasons not to. Note that this isn't an 'open source vs proprietary databases' comparison; it's about MySQL's suitability in enterprise situations."
A nice flame war. I'm just going to sit back, crack a beer and enjoy it. It is almost memorial day weekend, you know. Hopefully it get hot enough in here to roast a hot dog.
Warning: mysql_connect(): Too many connections ?
1) It's not a real database
He lists six reasons. On the other hand, the anti-mysql guy tries to up his reason count by breaking licensing issues into two reasons
NOW
Seriously, the articles do nothing more than point out the *best places* MySQL may or may not work, not that it is better than anything.
One size yet again does not fit all.
Hmmm..where's my Model204 manuals...?
I know all about enterprise solutions. Those guys over at dailyWTF?! can't shut up about them. Every developer should model himself after what Enterprise Pushers say, because they obviously know best. XML, COM+ and J2EE for teh people!
1. MySQL Uses the GPL
2. MySQL Doesn't Use the GPL
3. Integration With an Existing Environment
4. Product Maturity
5. Feature Set Maturity
6. Availability of Certification
7. Corporate Considerations
8. Perception of Scalability
They all have *some* merit, but all are very dependent on your situation. 1 and 2 seem to cancel each other out, as in if #1 is an issue for you, #2 probably wouldn't be. #3 is sort of weak, arguing that if you already have many other databases, adding yet another different system is detrimental. That's not an argument against MySQL, but against disparate systems altogether. The rest of the issues are matters of degree. "While MySQL does have a certification training program, its training availability is not nearly as widespread as for, say, Oracle or MS-SQL Server." True, but if you're comfortable with the level of quality of certified MySQL people, then go forward. It'll contribute to the general upward spiral of adoption, hiring, certification and so on. MySQL is going to keep growing, it's just a matter of how quickly and in what directions.
P.S. Printable version here -> http://www.cio.com/article/print/113111
creation science book
close(rantPage);
System.out.println("Nothing here to see. Please, move along...");
The pro-MySQL "guy" can't pee standing up, either. "He" is a she.
The anti-MySQL guy is Canadian, though, so he probably doesn't pee standing up either. Lots of beer -> floor -> bladder evacuation. I kid, I kid...
Postgresql
Not all database types are fit for all purposes. Relational databases for instance are bad for data mining/warehousing due to poor query performance but good for data entry due to high transactional performance
One Size fits all!
s _a_condom/
Seriously.
I know there are different sizes. But is there really a point? They do stretch quite well
http://www.metacafe.com/watch/335285/how_strong_i
Someone need's to slap this author with large trout. There are many reasons NOT to use MySQL, of which this article touches on only one. For example:
--Innodb scaling across multiple processors (MySQL bug ID 15815, still not completely fixed)
--Limit of 1024 current transactions ( MySQL bug 26590)
--Terrible performace when running MySQL Cluster
--Single threaded mysqldump exporting and importing (recently fixed in 5.1)
--Single threaded replication (making many changes? Don't count on it if you're running replication)
--Poor handling of subselects
--ineffecient ORDER by and GROUP BY
--Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)
--better performance in 4.1.x
Let's also mention that 5.1 has been out in beta for years now. When is it ever going to ship? MySQL now is proclaiming fixes in 5.2, and 5.1 isn't even on the board to ship yet.
With all that, and more, I'm surprised this author could only come up with "it isn't made by Oracle" and "product mateurity."
*disclosure -- yes, I play with MySQL databases all day long in large high use production environments. MySQL is great for small systems, but there -are- some problems when running on large enterprise grade systems. It'll get there
/. is a commercial entity. goto slashdot.com
Two of them are "The GPL can cause you problems."
Two of them are "Product Maturity".
And one is "Someone might think it's not scaleable". Possibly valid. Probably not.
Chas - The one, the only.
THANK GOD!!!
And that's before you get into "which MySQL are we talking about anyway" debates. There are multiple configurations for how the tables are stored, for example. Then there's MySQL vs. MySQL Max (which is a different product).
Oh, and the data is very important. Not everyone knows how to draw up an entity-relationship diagram, let alone build an optimized database from one, and different databases will lean towards different optimization methods.
The sheer number of permutations of configuring MySQL, of using MySQL, and of using MySQL in conjunction with other products, is so great that a simple list is useless. What would be more useful for people would be a sizable table which lists different types of scenario and different types of usage against different database engines.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
No, that's part of the "8,573 reasons to not use PHP" article.
Done with slashdot, done with nerds, getting a life.
If you're cheap but adventurous and willing to risk a little maturity for a fast growing, easy to support DB, pick MySQL.
If you're a tight-ass who is insecure but is willing to spend money on something that's been around as long as you've been an adult or you've got an expensive DBA who's like this... pick Oracle (or some other proprietary RDBMS).
A fool throws a stone into a well and a thousand sages can not remove it.
Tina is a GasPerson! Shes pissed off with MySQL because its not so gasy!
One of it's strongest points is that it's easy to use and manage. It's incredibly flexible and you don't need to be a DBA or hardcore programmer to work with it. As a Unix system admin I often find myself needing a small fast database to store a few bits of information for management tools. Yum install mysql && yum install php and off you go.
Do you propose using flat text files for data warehousing?
Run and catch, run and catch, the lamb is caught in the blackberry patch.
A better title would have been Dissagreements between a TodeRash and a GasPerson. Are these names real?
The audience for both articles are for IT (upper)mangers. Most of your argument above would be better off for the technical lead whose doing the report for his immediate manager (maybe technical) who'll then give a report to the CIO or even to a manger below him that would say:
MySQL (GOOD)
Oracle (GOOD but expensive)
Excel (BAD)
Not that those managers inherently stupid (hope not), it's just that their more concerned with the bigger picture and the resultant budget.
I prefer Flambe as apposed flamebait.
The MySQL supporter is raving about the large talent pool of MySQL developers, and the detractor is raving about the GPL.
Yes, there are lots of people who have "MySQL" on their resumes, right next to "PHP". They're all clueless ninnies. If they weren't clueless ninnies, they would have chosen PostgreSQL years ago. Yes, you can hire clueless ninnies on the cheap. That's not the point.
What does the license have to do with it? I can conceive of a project where I'm going to be bundling up a database with my application and selling it. Why would your code be so deeply integrated with the database that you legally have to sell the whole thing under the GPL?
Not a typewriter
If 1 and 2 are both valid reasons, then all RDBMSs are just as unacceptable for use depending on which of the two reasons fit the situaiton. For that matter, all software... everything... everyone!
No seriously, I don't get it. Why is being under the GPL a bad thing?
Due to tue relative low incidents of formally trained Oracle DBA's being mauled by Tigers, you could also infer that formal Oracle DBA training will also protect you from Tiger attacks. (To re-use & mash up that old cliche).
What a lame argument. Of course there may be some bias, but the fact is that: Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.
To be able to manage these systems efficiently & keep a "Q9" system up & running, the formal training certainly does help but I would argue is not required as the documentation is pretty damn helpful unless you get one of those wonderful ORA-600 errors (is that the magic "WTF" Oracle error? I can't recall).
Sure - the woo of mega bux will entice many into Oracle DBA training but the weaker resources fall off quickly. You can't fake it when your production system is down.
IANAODBA
Even though the negative article is imperfect at best ("Perception of Scalability"??), at least it actually comes from someone who seems to understand the world of databases.
... stored procedures??). As such it's an unfair match.
The positive article, though, is ridiculously weak, riddled with IT-journalist misconceptions (AJAX is a language? Scalability is achieved via
On the positive side, what about:
1) MySQL is FASTER. Cite some research of the shootouts. MySQL always does well.
2) MySQL is OPEN SOURCE (at least the negative article addressed this, although in a stupid fashion). Journalists don't seem to get how much better it can be to work with a product with open source, when tracking down bugs, or merely finding good resources (docs, howtos) on the web -- aside from the TCO free-as-in-speech-and-beer aspects.
Many applications need a small to medium size database that contains important but non mission-critical data. MySQL is perfect for those applications. No licensing hassles, no funds requests, no major administrative overhead. I don't have enough experience with MySQL to recommend it for a really critical database, but we do have plenty of need for smaller databases that we can set up quickly. I certainly don't see spending a lot of money on SQL Server (which we are doing) or any other big commercial server to run a bunch of small databases.
The article is in CIO magazine, none of the downsides you mention is of a concern for a CIO. A Product manager? Maybe, even then probably not.
If you're going to choose 8 reasons to not use a product then at least back up those reasons. All of the assertive tip toeing is boring, and tells us you don't really think those reasons are all that valid yourself.
You know, I have one simple request. And that is to have sharks with frickin' laser beams attached to their heads!
Don't forget there's other options. For example, Sybase and MS SQL Server (based originally on Sybase 10) are both faster than oracle and more compliant than MySQL.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Even if this is about tight integration of the RDBMS into a redistributable product, the statement about PostgreSQL doesn't make sense. Do what you want with it is always do what you want with it. The author is throwing arguments from different viewpoints out as if they ought to be arguments from one viewpoint. Sure, there are those in the open source community that say BSD is too free that all should be GPL, but that's hardly going to be an argument from a user perspective, no matter what the user wants to do with it.
Yes, my arguments may be technical in nature, however the arguments in the article are worse than straw-man arguments. I'm surprised the author didn't mention that MySQL doesn't cost $20,000 per processor, therefor must be bad. Even given the intended audience (who, as you suggested, may not be extraordinarily technical) the pro-MySQL author did a much better job laying reasonable arguments.
You mention Excel jokingly, but I know some companies which maintain large databases worth of information inside of Excel (statistics on hundreds of applications for hundreds of devices on dozens of networks, reported daily ) because no one wants to write a script to input data into a database.
/. is a commercial entity. goto slashdot.com
Last time I checked, DB2 was more scalable than Oracle (less performance hit as you stuffed the database) and both Sybase and SQL Server were faster.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Just keepin' it real. Gotta love the internet.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It is painfully obvious from the article that this writer was or is a consultant. All of the reasons not to use MySQL are PHB reasons. Not one is based on actual abilities or inabilities of MySQL. He seems to be intent on agreeing with a position that he doesn't understand or didn't want to take. "...I'd be hard-pressed to tell a conservative IT manager making a platform decision for a mission-critical application based on this factor that he's doing the wrong thing." Yes, it does sound like he would be hard-pressed to tell any IT manager that the stupid decision he was making was the wrong thing.
The info at the end of the article says that he guides many projects based on MySQL, but it is hard to believe that he has ever used it. It sounds like all of his research was with PHB's or admins that have never really given MySQL a good try. A good admin knows both the pros and the cons of the software he uses, and hopefully, the good out weighs the bad. Many people that use or even swear by MySQL could give you some good reasons not to use it, under the right circumstances. Obviously, this guy could not find any. Either that, or he did his research in the wrong area.
I realize that this is the CIO magazine, and that some CIO's really are PHB's. However, Tina was able to write a good article on why a CIO should pick MySQL and give good reasons that were understandable to both technical people and PHB's. The only other conclusion I can come to was that Brent was trying to steer people towards MySQL and thought a badly written article against MySQL was the best way to do that.
Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
This article comes from CIO website so I think that it if fair to say that they are most interested in applications for the enterprise. Enterprise applications don't bundle the database. They may require a certain database vendor product/version or a small set of database vendors but they don't bundle the database with the application. This is true whether or not you use SQL Server, DB2, Oracle, MySQL, or PostgreSQL.
IANAL, but IMHO there is no legal restriction to selling a commercial, closed source application that requires MySQL as long as you don't include the MySQL application with it. This isn't a problem for enterprise applications because businesses that need such applications already have sufficient IT experience to run the vendor specific database that they are going to accept. If a company doesn't have sufficient IT experience to do this then they are going to have to go the SaaS route. Their are not going to be able to manage the application even if it did come bundled with a vendor specific database product.
The link I have there for the MySQL internals doc seems to be invalid... It has moved to here: http://forge.mysql.com/wiki/MySQL_Internals_Clien
Here is a quote: I don't think that's a valid use of copyright, but I'm not a lawyer. Can anyone explain to me how that's a valid use of the GPL?
That depends entirely on the platforms you happen to run them. DB2 on NT (what used to be called "UDB") is a joke; DB2 on OS/390 is pretty much what defines a "big-iron" database. Oracle on NT is nowhere near as good as it is on Solaris. But Sybase on NT is actually quite good - almost as good as SQL Server on the same hardware. Sybase 12.x on HP-UX is also quite good.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
MySQL comes prepared to support all the most popular Web 2.0-ish languages, such as Ruby, Ajax and, of course, PHP.
I've got the php_mysql.so library, but I can't seem to find the MySQL library in my Ajax installation... Oh wait, ajax isn't a programming language. I'm sorry little things like that really get under my skin (e.g calling the CPU "the hard drive", "I've got the Internet on my computer", calling excel spreadsheets databases). In case the author of the article didn't know, postgreSQL also comes prepared to support Ruby, and PHP.
I also didn't see where they listed phpmyadmin as a reason to use MySQL. Seems like they always use that as one of the reasons.
Bzzt! Thanks for playing!
SQL Server was based not originally based on Sybase System 10. It was much earlier than that. Thats why there is no CT-lib client interface for SQL Server, it didn't appear till System 10.
Whether either are faster then the big O depends on a number of factors. Traditionally, Sybase has been strong in the Wall St. type businesses where there is a very high OLTP workload.
I don't even have to RTFA to know that 8 is more than 5, therefore I obviously shouldn't use MySQL
But some +5 commenter pointed out what the 8 points against were, and they sounded lame. Another commenter actually listed 8 real problems with MySQL. But no matter how you slice it, the biggest, baddest, most ass kicking websites on the planet* are powered by MySQL. So... uh... deal with the reality. MySQL isn't going away.
* Google.
* Yahoo.
* Digg**.
** Yeh, I'm the Digg DBA.
fifth sigma, inc.
you forgot one big one:
-- Views do not utilize the underlying table indexes
For example, Sybase and MS SQL Server (based originally on Sybase 10) are both faster than oracle and more compliant than MySQL.
That is debatable. Oracle is very good at high levels of concurrent updates & selects to the same data.
For the article writer a product's maturity solely depends on its age.... *thumbs down* I wanted an interesting read and got this?
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
It was enough that on the 3rd or 4th page of the '8 reasons not to' article that they used the PHB acronym, but then explained it in parenthesis. *TWEEET* Gene police! Out of the pool!
--Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)
What does Al Gore have to do with this?
Doesn't seem odd to be complaining about the speed of mysql cluster when the pgcluster web site hasn't been updated since 2005?
evil is as evil does
I agree with you that the author has not made a single insightful comment. But you are looking at MySQL as an Oracle DBA which isn't much better. I don't disagree with any of your points - they are all valid issues and are a result of MySQL not being used extensively on Big Iron in favour of clusters of commodity hardware. It comes down to the right tool for the job, and writing and architecting your application with the strengths and weaknesses of the DBMS in mind. Database neutrality is a great ideal, but for anything high-performance its unrealistic, and when taking an application written for one database and running it on another, downright unfair
e.g: Limit of 1024 current transactions (bug 26590). Why are you running so many simultaneous transactions on one box? Partition your data and take advantage of the fact that MySQL runs incredibly fast on cheap hardware and that you aren't limited by license cost.
If large web-based social networking sites with millions of hits per day can make MySQL work for their needs, it can work for you too. Don't expect your application written for Oracle to run flawlessly on MySQL without some tweaking, though.
I recently started looking into databases, and I asked a bunch of friends. All the experienced ones gave roughly the same advice: If you don't have time to read directions, just throw something together with MySQL. It'll be okay. PostgreSQL would be better.
So I took the extra ten minutes, and I'm pretty happy.
Every large site I know of that uses MySQL has had scaling problems of one sort or another under load, usually to do with trying to handle multiple writes to the database. At least a few people have simply swapped in PostgreSQL and seen problems disappear instantly. One friend did performance testing, where what he found was that MySQL was faster for small sets of clients, but that it slowed down faster, and that for largish N, he couldn't get it complete the test on the available hardware, but PostgreSQL just ran.
Having set up both a few times now, and having debugged problems with both, there is simply no way I'd use MySQL given any choice at all. It runs, but it feels accreted rather than designed. I know, Cathedral and Bazaar and all that... But there are times when you really do want the feeling that someone considered something up front.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
In datawarehouse environments & app environments I've always seen more Oracle than SQL server. For speed/stability I've always had more success with Oracle but have no qualms with SQL Server - it is mighty fast and easy to use(ducks & dodges eggs & rotten tomatos) but I've queried sql server to a crawl more often than I ever have an Oracle db.
We have an instance of Sybase where I'm at now but haven't given it a thorough thumping yet.
I guess my original comment should have specified "in general". Anyway, the point is, There are a helluva lot more reasons than "formal training" for choosing Oracle more often than others.
From my own experience one of the main problems is a misleading feature set. When you choose MySQL you then have to choose one of five or so ISAM packages for it to sit on. This is a problem since they all have difference features. Do you want the one that supports multi-user, the one that is fast or the one with transactioning. Personally I want all of those and can't get them. Then we had problems with a number of queries where we had the where clause specify fields in the primary index and the optimizer cleverly would always do a table scan. Asking MySQL support led to the answer that we should edit the source fix the optimizer and submit it back to the project. A bit beyond the scope of our little project. Seem that MySQL is good for web applications where a web server talks to it with one connection and each exchange is atomic, so multi-user and transactioning support isn't needed, so you can use the fast/light isam package.
The catch is that large web based social networking sites are fairly simplistic when it comes to the database design. In more "enterprise"-like apps (I hate overusing that term, since what it means is so vague, but Im sure you can guess), the amount of joins and long running transactions and datamining queries you need to make will almost systematically trash MySQL to the crawling point.
:)
So you're right on most everything else you said, but comparing web based social networking sites (which have incredible amounts of simple queries, the vast majority that are reads) to, well, EVERYTHING ELSE, is a bit unfair too
PostgreSQL (AWESOME and FREE)
And PHBs can spend budget on paid support.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
> Not all database types are fit for all purposes. Relational databases for instance are bad for data mining/warehousing
> due to poor query performance but good for data entry due to high transactional performance
Your information is incorrect:
1. relational databases have been used for warehousing and reporting (data marts) for 15 years - and are used for more than any other solution for this purpose. Ok, sure you've got a lot of OLAP out there, but there's probably almost as much Relational OLAP (ROLAP) via Microstrategy, etc as there is true OLAP.
2. Take db2 for example, it:
- support three different forms of range partitioning (union-all views, multi-dimensional clustering, and range partitioning)
- supports hash-partitioning of the data across many servers - think "beowulf cluster"
- given the two above you can spread your data across 100 4-way servers, each with fibre access to a heavily-cashed SAN.
- Now when you issue a query db2 will spin up all 100 servers - each hitting its own local piece of the data (not 100 copies of the whole data, but each server with 1% of the whole).
- Because it also supports range partitioning each server is probably only going to scan 10% of the total data in a typical query.
- Because it support query parallelism it'll split each query on each node into four separate pieces (getting near-linear performance speedups) - now you've got 400 cpus working.
- Because its optimizer is about the best one on the market - it isn't going to auger itself into the ground on your 100 line sql query.
- That should allow you to crunch down a billion rows to your 24 row output in couple of seconds at most.
- Of course, it's also smart enough to rewrite your query to automatically hit any summary table that could speed the query up. So, it may only have to scan 2400 rows - and may return the results in 0.001 seconds.
3. The point is that warehousing, reporting and analytics work very well in a relational environment. But you need to pick your products well. If you want to handle terabytes of data you can put it in MySQL, SQLite, MS Access, Foxpro, etc - if you really had to. But, life will be *far* easier if you put it into a product that can handle the volumes much better.
If you read a little further you'll discover that a reason not to use MYSQL is because you're already using something else. um, DUH?
Wow, talk about one-sided. That was ridiculous. I think MySQL is great, and I use on almost every project I work on, but even I could come up with a better list of reasons not to use it.
The first two reasons not to use it are "It's GPL licensed" and "It's not GPL licensed". Neither one of which are very good reasons not to pick an otherwise effective tool.
The anti-MySQL guy says the first release of Oracle dates from 30 years ago, whereas the first release of MySQL dates from 15 years ago. Uhhh... I'd like to know if there's a single line of code in Oracle dating from 1980.
When I were a lad, we used to go to the swimming pool and on the way home go to the chip shop for fish and chips or chicken and chips. Those were the days before dad was a wuss and he had a car with a powerful engine.
Since dad got old and mellow and concerned about saving money, he uses MySQL despite the fact that PostgreSL has a better license and now I am allergic to the batter on the fish.
My brain has gone and I forgot the point of this post...
Stick Men
Tina is dead bang on with the TCO commnet; We pay more for Oracle support than we pay two Certified DBA's.
Brent's comment about "ignorance" of workers not knowing a company has a site license for propertiery systems is not a technology fault, but a management fault. That cannot be properly consider a fault of the technology.
Seems to me to be a send up. A trial ballon to support a future brochure slick about why paying $$$ for an RDBMS makes sense and why something "Free" isn't. We all know that using open source isn't free unless you have unlimited staff time and don't count system administration costs against a particular project. Open Source CAN cost a lot more than a closed source system, but it's not something I've seen. I'm sure there are examples, I just don't know of any.
There are also times when open source doesn't make sense. Like in situations of unlimited libility in case of failure. Take a nuke reactor. Say you use open source products to control that reactor, and it melts down because a pump failed to start, a valve was incorrectly closed, and humans didn't follow proceedures. Automatically, it's the fault of the open source product, obviously, because you were too cheap to go buy "good" software.
Until the human race as a whole can value a gift freely given by a stranger, it won't grow much past it's current point.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
That's correct. MySQL is used internally by Google Adwords for keeping configuration parameters only. For actual products they use BigTable.
Exact. IIRC, MSSQL is Sybase 4.2
/much/ faster than ORACLE.
And I have seen ORACLE beat MSSQL almost every time on non trivial queries.
In general (over simplification), my experience is:
Sybase/MSSQL : low setup costs (parse et al.). You can send a stream with hundred of simple statements and get them executed
ORALCE : high setpup costs (parsing, optimizing, etc). But if you send complex statement referring to on-disk data, you'll generally get a better result than MSSQL/Sybase.
This page has a list of MySQL gotchas
http://sql-info.de/mysql/gotchas.html
Some of my favorite are things where MyQL accepts values it shouldn't and it doesn't throw an error. For example you can insert a 0 into a date field, 30000000000 into an in column (it will just ignore the higher order bits.
MySQL is OK for quick and dirty, but it will always be dirty. If you want MySQL to be decent:
1) Set it up with InnoDB and make that the default table type. MyISAM should only be used for data warehouse tpye applications where you are doing a lot of IO and its OK for the DB to be down for hours while you recover your corrupted MyISAM tables.
2) Set the strict sql mode in the my.cnf. I don't remember exactly what the parameter name is, but you want MyQL to throw an error if you throw stupid values at it. Otherwise it will accept wacky values and you'll end up debugging it later.
3) Set the default character set to UTF-8 if you can. This can be a bear but its worth it to be able to handle foreign characters.
4) Avoid the fancy "features" if you can. The old features still have unresolved bugs and it isn't going to get any better with more and more storage engines going in.
5) Monitor the performance constantly and be prepared to partition your data. Scale out isn't always as easy as it sounds.
Interesting post, albeit arrogant, but let me ask you, was the problem with MySQL the database software itself, the hardware used, or was the problem with how the schema was designed and/or the application code? Sure, transactional processing in MySQL is new, but do you have solid evidence to support the fact that Oracle has better/more accurate/faster transactional (commit/rollback) processing than MySQL? Also, do you have expertise with MySQL at all? Last, what is your definition of a database? I admire your arrogance, but you would care to back it up with actual helpful data in any way?
Horns are really just a broken halo.
What a lame argument. Of course there may be some bias, but the fact is that: Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.
And price.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
I've RTFA, and I got to say it is complete crap. OK, actually I only read the first page, and the reasons I read aren't convincing enough. Beside I dislike websites that make you go trough 8 pages at one paragraph each of content only to get lost in their completely cluttered up design and in your face advertising.
~ In Trust, We Trust ~
My point was that its stupid to continue to be locked into one tech because you're "already using it." Or are you still browsing the internet using Chameleon on Compuserve with an old 286 and Windows 3.0?
The guy is a 14-year old in underpants posting from his parent's basement. You fell for the troll.
I'm agreeing with you- not directly, but in pointing out that "because you are using something else" has nothing to do with MySQL in and of itself. I share your sentiment that the article is rather lacking in many respects.
If that site was running on mysql we would most likely be seeing horrible server death right now.
Right, so in one sentence you talk about how the people you work with mock MySQL for being for the ignorant. However, until your "Technical Architecture and Strategy" group banned it, you were using it for major projects.
So why should we believe that it wasn't your "not knowing databases" that was the fault, not MySQL?
I hit him with my +5 longsword, rolled a natural 20, and dropped the bastard! But still, they keep getting up!
Horns are really just a broken halo.
Yes, a good admin denormalizes his tables and removes all referential integrity because MySQL really roars as a flat-file database.
The paradox makes the anon post ever so more credible than you can imagine my friend. The purse is often in the hands of the clueless and all it takes to throw monoey in the wind is another illiterate with good social skills. Of course the ancestor poster's attitude usually helps to definitively bury the technically better option; that's why I always draw an ear to socially obnoxious nerds touting stuff: they may be onto something....
e
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
This is true. Why do they post "content-free" stuff on Fridays? (okay - they do it all the time, just MORE so on Fridays :-)
...understand the part about having to buy a commerical license if you distributed MySQL with your program. Can anyone explain that?
Coder's Stone: The programming language quick ref for iPad
8 is more than 5!! Looks like I won't be using MySQL!
Did you ever notice that *nix doesn't even cover Linux?
Those people are unable to use the mysql client library to add mysql support to their software without buying a commercial license. If the server were GPL and the client lib were BSD/MIT (or even LGPL) then it wouldn't be a problem.
For example, the author makes statements like: "Clearly a GPL license is a plus for many, but for some environments, GPL'd software is a non-starter."
He does absolutely nothing what-so-ever to back those statements up. Why is a GPL a "non-starter" for "some" environments? What environments?
And the entire article is like that. A series of assertions with no reasons behind them.
I believe good arguments could be made for, and against, MySQL. But, you won't find those arguements here. Just a series of unqualified assertions.
The only benchmarks that show mysql beating postgresql are benchmarks of a single connection making queries in serial. It performs very well at this workload, but most real world workloads involve many connections all performing connections concurrently. Mysql sucks at this, and the more parallel queries, the worse it gets. Postgresql is way faster when handling typical loads of multiple connections making queries at the same time.
While we're kind of on the topic of issues with MySQL, I have a couple questions about PostgreSQL that I'd like to ask /.
(hell, I've got SO many questions, that I could make this into an "ask slashdot" by itself, but I'll digress)
I'm designing a personal web business (and very new to it - this is a personal endeavor) that will require hosting small files, perhaps no more than 5 megs each, but the overall byte size of the database could reach into the terrabytes potentially. I have chosen PostgreSQL over MySQL due to user opinion for it's robust nature, BSD license and solid stability. I know of the max file size of NTFS as 16 terrabytes, I believe, so is PostgreSQL capable of storing and managing terrabyte size databases effectively? Would breaking down the data into multiple databases consisting of minimal tables be better or would handling all of the data in 1 database with lots tables be best? And how many tables can a single database handle? thousands? millions?
I have books on these databases, however, none of which answer these questions. They probably assume Joe Average is making a small family site to host pictures and such.... or maybe a small corner store going e-commerce for the first time. The BIG answers are hard to come by since most forum traffic consists of "bits" of information that would require piecing together hundres of forum threads and web site data to get 1 complete answer. I hate wild goose chases. The open source community is great for information, but piecing it all together can be a real pain in the ass.
And on a really tangential side note: I'm considering IX web hosting's top plan which apparently has no size limits for data storage. Is this web host capable of handling terrabytes of someone's web business?
"Not the Earth!!! That's where I keep all my stuff!!!" - The Tick
That statement is proof positive that you have no fucking idea what constitutes a good quality RDBMs or when you ought to use one.
I was hoping for concrete evidence for and agaisnt mysql, but instead read about someone raving agaisnt the GPL and slamming mysql, then supporting the GPL and slamming mysql because its not gpl?? Then I read about how some dbas' are idiots because they buy more than 1 database license when one already exists and then somehow turns this agaisnt mysql. Last he slams mysql because its not 30 years old like oracle and just 15 years old?? What does that have to do with reliability?
.... I did not bother to read more.
Whatever
At least mention the pros and cons of price, features, flexibilities, and needs when writing an evaluation. Worse is the author who bashed mysql did not even offer an alternative but Oracle a few times just because you may have a license already.
BTW I think mysql is weak compared to a real database with acid support and better clustering and transact sql. Those could be arguments for postgresql or ms-sql server which are better than mysql for certain situations just like Oracle is better for very large scale operations.
http://saveie6.com/
LOL !
Please show me examples of too much Transparency not being in public interest. I absolutely love the concept. I can't get enough of it in govt, business and programming code. It could help impact corporate corruption government corruption, and some FUD attacks. Kudos.
Not sure what you mean by "faster". In my post, when I say fast, I mean the humble act of selecting data, which is 90% of the queries in I'd bet most traditional web applications. I care less about insert, updates, and deletes because those just don't happen as much.
Oracle run by a good DBA is fast fast fast. I don't have benchmarks for you. But I have personally migrated an application from MSSQL 2000 to Oracle 9i. I have more experience with MSSQL than I do Oracle (and so you could rightly infer that at first, my coding practice was optimized toward MSSQL which is in many cases the opposite of how you code for Oracle), and yet my application runs much, much faster on Oracle. I chalk it up, in part, to the efficiency of the indexing. The b-tree indexes in Oracle are just awesome. And now that I actually understand how to really tune a query in Oracle like I do in MSSQL, I have to say that Oracle provides better tools to enable you to tune. The explain plan alone, when you really understand it, is hands down better than, say set statistics io on and set statistics time on in MSSQL. And that's not even getting into TKPROF.
Maybe your real world experience says the opposite of what I just said, but in the corporate environment (like at work) I wouldn't even think of using anything other than Oracle, not out of prejudice, but based on years of experience. I'd like to try MSSQL 2005, though. Always willing to give them another shot.
But I have also used Oracle DBs admined at let's just say, a less-than-competent level, and it's quite horrid. Oracle has to be done well, and paying a real DBA is costly. Enter MySQL.
blah blah blah
It looks like the article "5 reasons for" is an enumeration of technical reasons it could be good for an organization to use MySQL, and the article "8 reasons against" is an enumeration of reasons why a CTO/CIO may be unwilling to be responsible for what might happen if MySQL were deployed.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
And security. After all, they did call it "unbreakable", therefore it must be true.
I will take a crack at this.
With a traditional RDBMS, you define your data essentially using a pseudo-mathematic model, assign data constraints and triggers to ensure that the model is not violated, and add views to provide handy ways or putting the data together. You may optionally add stored procedures as a functional interface to that model.
Until 5.0, MySQL didn't even try to be this sort of database. Even in 5.0, you only get real data constraints, triggers, etc. on some types of tables, and strict mode (which does actual data type checking) can be turned off by the application. MySQL still does not compare well to traditional RDBMS's in their home turf (though PostgreSQL, Ingres II, and to a lesser extent Firebird do compare reasonably well-- Firebird to a lesser extent just becuase of some interesting cases involving NULL's).
In fact, MySQL is almost, though not entirely unlike Codd's idea of an RDBMS. MySQL is not something to consider for your RDBMS. Period. End of story. It is not worth it.
However, if what you want is a simple data storage engine for your one app with an SQL interface and many of the features from real RDBMS's, MySQL is not bad. It is a remarkably flexible software development tool with many very useful. It just is not a substitute for a real RDBMS (where, for example, the server must authoritatively and robustly provide data sanity checks).
LedgerSMB: Open source Accounting/ERP
For correctness, the GPL also covers the other clients (Java, .Net).
Add to this, that MySQL AB is absolutely horrible at explaining their position on GPL coverage (read the Licensing forum on mysql.com). Continue adding, that the FSF prefers to interpret "distribution" to also cover making publicly available a Web site driven by MySQL (FSF GPL FAQ). Finally, the few explicit statements from MySQL AB personnel (again, from the Licensing forum), stating if you use MySQL with non-open source software, you should use a commercial license, period.
Based on this, I would say that the GPL'ed MySQL is a no-go in a corporate environment, period.
I only use the most recent version of MySQL, and I have the exact opposite perspective. MySQL does what a database is suppose to do really well - simple relational queries onto data. MySQL's transactional processing; the ability to set a savepoint and then commit or rollback, seems flawless to me.
Oracle on the other case, seems to be doing exactly the opposite of what a database is supposed to do - it's encouraging you to push more and more of the application layer into the database (first plsql, and now Java at the database layer?).
I just want to create tables, select, insert or update data. Not much else. That's what Codd truly intended. Codd would roll over in his grave if he saw the bloated mess that Oracle is today. And you can design a horrible denormalized schema in Oracle just as much as MySQL - neither force any form of normalization at the RBDMS level. (Some applications merit denormalization)
Not to even mention the absolute shameful way Oracle considers, manages and patches security issues.
MySQL is a simple, free relational cruncher. I can't believe a true finance architect considers Oracle more robust that MySQL, especially when its comes to security.
Horns are really just a broken halo.
Don't forget P-Mate!
WHO NEEDS SHIFT WHEN YOU HAVE CAPSLOCK/ DAMN1
A database that is shared between multiple applications must maintain consistency by itself instead of farming it out to the applications since otherwise the applications can disagree on what constitutes a valid state. From the comments I've read about MySQL it seems to be sufficient for smaller operations where everything is under your control but once you get bigger and have many different entities accessing your database you want to enforce consistency and access privileges centrally which also makes sure that any changes to those can be done centrally instead of altering every tool that interfaces with the DB and that improper (potentially malicious) commands to the database can be prevented from doing any harm. Think e.g. a bank database, it gets accessed from every company that runs ATMs and has to provide them with the information that an ATM needs but it also has to make sure those other companies don't access data they have no business reading or write data into the DB that creates an inconsistency (e.g. withdrawing money from an account with a remaining credit limit lower than the amount withdrawn, if there is no DB level check the other company could subtract more money from an account than that account is allowed to lose).
Justice is the sheep getting arrested while an impartial judge declares the vote void.
It doesn't surprise me that both articles don't really contain much usefull information. It's like two people debating wether FreeDOS or MS DOS is better. No actual real-life or even academic issue.
[rant]
The more and more I do professional projects that go beyond a 'single freelancer' scope the more and more RDBMSes bug the piss out of me.
Databases suck. What we call databases today is nohing much more of a historically grown apocalyptic chaos. With one of the oldest and crappiest programming languages ever as a cornerstone of its technology. A weedy mumbojumbo of wanna-be virtual machines, wanna-be server daemons, makeshift security layers, obstrusive user management and pseudo operating systems and a bazillion proprietary variants of said programming language that make a Perl debugging session look like a walk in the park in comparsion. With features bolted on left right and center. This basically is the case with any current DB in widespread use, be it MySQL, Oracle or anything inbetween.
And if you look at the core of it Database technology and how long it has been that way there isn't much hope that DB's will go anywhere anytime soon. Mostly because people are to thick to f*cking drop the notion that SQL has some sort of value in itself.
It litterally scares me to see many experienced developers who are so brainwashed by unquestioned traditions that they truely believe they need something different than the programming language they're using for their application to handle the persistance layer. A Database PL and 30+ dialects of it from back in the days when we flew to the moon using a slide-ruler as primary means of calculation. A PL that would have any CompSci student score a clean 'F' in compiler and parser building would he deliver something like it as project today. A PL so broken the only other I know that compares to it is Lingo. We waste tons of money and manpower educating DBAs with technology and concepts that are a pain in the ass and not even very tranferable. And the technology doesn't even do it's job very well! Relational Trails, true hassle free de-normalisation, true hassle-free scalabilty - no go. Nowhere. And no, having to need three 200$/hour Oracle DBAs who spent years stuffing their brains with proprietary sh*t to move from one server to 10 is _not_ what I call 'scales well' nowadays. So Postgres (and maybe some others) have entity inheritance. Halleluja. Big fat hairy deal. And the new DB2 can do nested sets with XML (serialized data). I am over-f*cking-welmed. Hello? What time are we living in?
I understand that something like SAP has a hermetic market and they are the proprietary king of the ERP hill with a licence to print money. Their army of suits is the right thing for dealing with CEOs and special SAP devs have to deal with ABAP as a tradeoff. I can get that, it's a marketing thing, not a software thing. They get paid enough anyway.
I also understand that we are still living in the early days of comodity computing and that universal unicode and some other stuff I as a webdeveloper run into every day - and bugs me just as much - still need another few decades to even themselves out. After all I can't force all my users to use Firefox 1.5+ and pure unicode on their clients.
But it's nearly *only* developers that deal with RDBMSes. Our code writes the data and gets the data. But why so many devs who all are in total control of the backend and what it uses put up with this pile of doo-doo we call 'database technology' nowadays is totally beyond me.
[/rant]
My 2 cents.
(SQL-fanboys please cue remarks about how I don't know what I'm talking about below)
We suffer more in our imagination than in reality. - Seneca
SCO has their mitts in it.
boycott slashdot February 10th - 17th check out: altSlashdot.org
WRT the Certification Training Program, maybe MySQL simply doesn't have the tonnes of crap piled onto it that Oracle or MS-SQL server typically do? In other words, maybe you only program Oracle or MS-SQL at a technical enough level if you're "certifiable?" (-:
Disclaimer: I spend a lot more time on PostgreSQL than MySQL, but know a few of MySQL's developers. It would take a specific and feindishly complex access situation for me to prefer (e.g.) MS-SQL to MySQL.
For the vast majority of single-use situations I prefer PostgreSQL but basically would be very happy using MySQL instead. PostgreSQL has a few more useful detail features but in most cases they don't make a substantial difference, and MySQL does things like going faster and using fewer resources, general properties which make it attractive beyond the mainstream things which it does exceptionally well.
Either of them are streets ahead of MS-SQL in terms of clear simplicity, and if you don't need Oracle's labrynthine complexity (and such cases generally speak more to poor project design than to any genuine need for complexity), then don't suffer from it. Sticking to MySQL or PostgreSQL also means that you don't have to work anywhere near as hard to port your app to a different database when that time comes. Oh, yes, and installing either is just an apt-get or urpmi away, rather than an epochal session involving either leagues of cryptic commands or massive insecurities or both. And you don't need to bow and scrape before intricate and/or overkill licence terms.
Got time? Spend some of it coding or testing
Oracle's vaunted B-Tree indexes? How are Oracle's indexes any better than MSSQLs? As I understand it, most RDBMS indexing is based on some kind of tree structure. I hear the WatCOM SQL team finds Red-Green trees particularly handy in Canada.
As for some other erudite fool's suggestion that DB2 is a terrific tool for scanning a billion rows...when I find myself faced with the task of scanning a billion rows, I have to ask myself, how did I get here?
A tree (index) will get me through a billion rows with 32, maybe 33 comparisons.
The real deal on RDBMs...there are 3 serious products. Oracle, Microsoft and IBM. A programmer/DBA will be able to do pretty much anything with any of these three. Differences in performance will be largely attributed to the programmer/DBA's personal preferences. A programmer who loves Oracle and hates DB2 will, when confronted with a requirement to make a DB2 database, make a crappy one.
So, when you talk about how much you gained going from MSSQL to Oracle, I'm pretty sure most of that's because of your preference for Oracle, not the actual differences between MSSQL and Oracle 9i.
First let me say I have very little experience with MySQL. I have basically tried it out a couple of times, but we use MS SQL Server at work so I don't use it much. I am not an MySQL fanboy by any means, but I find the slant of the article disturbing.
His first two reasons:- MySQL Uses the GPL
- MySQL Doesn't Use the GPL
It doesn't take Sherlock Holmes to see a logical problem here. These two could actually be seen as a reason to use MySQL. You can choose the GPL if you wish to use MySQL for free and plan to use the GPL yourself, or you can purchase a commercial license if you want to keep your code to yourself. Choice seems like a good thing to me. Each one cancels out the negatives of the other. If you choose the other RDBMSs mentioned (except POSTGRESQL), you are stuck with all the minuses of option #2 and more (since you still get the MySQL source with option #2) without the choice to go for option #1.- Integration With an Existing Environment
Basically he says that if you're already using another RDBMS and have enough licenses, why not use it? This could also be seen as a reason to use MySQL if you already use it for other projects.- Feature Set Maturity
It looks like he is saying that MySQL has all the features you need as of version 5.0, but it is only one year old so how can you trust that they work well since they weren't in the previous version? Seems like a lame stab at MySQL whereas a real analysis would use the features and judge them on their merits. While the new features have only been in production for a year, they were in beta long before that. It's confusing because he mixes in faults of previous versions in his discussion, very strange indeed.- Corporate Considerations
Wow, this is incredible to me. He actually says that because Microsoft and Oracle are publicly traded companies that they are more reliable. I would argue that since you get the source code to the RDBMS that MySQL has the upper hand here. Other solutions stop supporting versions after just a few years and you have to pay new license fees as well as go through the pains of an upgrade (admittedly easy I know from SQL Server 2000 to SQL Server 2005 at least). With MySQL you have the source code and can fix any problems yourself and use it as long as you want, for free if you use the GPL.He makes some claim that if a crash occurs during certain operations that the database can be left in an inconsistent state. I can't vouch for that one way or another but that would be a reason not to use MySQL.
I don't agree with your premise, but the solution is a good one.
All a database requires is ACID^2 (Add,Change,Inquire,Delete,Atomicity,Consistency,I solation,Durability) the bugbear here is the 'Consistency' tag. Originally and properly this only really refers to referential integrity, but it has been gradually extended to include more and more of the user application. First off came column types and 'NOT NULL' and it's grown from there into the horrific mess that is MS T-SQL.
What you are doing is putting the application server into the database, code that often goes into libraries or special servers (and sometimes nowadays in 'web services'). Stored procedures and triggers are reasonable solution to the problem BUT do not define what an RDBMS is.
An RDBMS is something that solves the difficult ACID^2 problem and so provides a solid base for the application and application services. Once you have that base the application level consistancy (eg "the G/L must balance") becomes a lot easier.
So back to the top, MySQL isn't a true database when it doesn't have transactions, but as long as you choose a backend with transactions it most definitly is an RDBMS, but perhaps not an application server.
See e.g. this or this.
(Hint: B doesn't stand for binary.)
Karma: Excellent (My Karma? I wish...:-( )
And please do not ask your ops group to support more than 2 db's.
It is strategically imperative to add a free db to the mix if only to give you some leverage over the non-free vendors. Otherwise Oracle will bleed you. So OK they're going to bleed you anyway but maybe not so badly.
The list is still crap. What big picture?
;) ).
Stuff fit for a real online CIO mag should be:
1) License may be incompatible - list the various licensing issues with MySQL
2) Strategic: Oracle owns Innodb and Sleepycat - technologies that "serious" MySQL sites depend on.
3) Strategic: management of MySQL Inc seemed to not have anticipated 2).
4) The MySQL Inc people (developers etc) were not concerned about data integrity for a long time and came up with _excuses_ rather than saying "OK we screwed up, we'll fix it". (this shows you what sort of people are behind the long term product direction).
5) Better options out there - Oracle, Postgresql, DB2, MSSQL etc: see our article "Which databases for your company?" for details (and read more ads there
6) Lots of technical problems with it (see our article: "MySQL the gory details" which explores these in depth).
If you are a real CxO your internal additional negative reason list could go something like this:
7) Your Legal Dept recommends against it for legal reasons.
8) Your top techs recommend against it giving technical (and sometimes other) reasons.
9) Your company is already using Oracle/MSSQL/Postgresql/etc and the IT/IS dept has other more important things to do for you and the company at the moment.
10) You checked with a few of your trusted competent contacts and they recommend against it. If you are a real CIO/CEO you should know a few people who know stuff, otherwise you're just one of the fakers.
I was responsible for ensuring it got banned, after it became clear that even people with quite senior roles in my organization didn't understand what was meant by the words "scalable", "high availiability" and "transaction".
Rather than argue the toss on a case-by-case basis, I simply pointed out to our CTO that we have 1000s of proven Sybase, SQL Server, Oracle, Ingres and Teradata deployments, none of of which had ever been the root cause of a $1.24 million loss, and it was banned the next day.
When you have a large (0.5TB) database that requires quite literally 100% availability, globally, 24x7, you cannot afford to be playing with broken toy database systems.
I'll put it in language you fresh-out-of-college no-experience so-called computer "scientists" will understand:
MySQL FAILS IT.
What? 500Gb is a small database. You gotta be kidding me! That's your large precious database? LOL
Seriously. If you're going to troll, at least do a decent job.
If any proof was needed you are, indeed, a 14 year-old trolling from mommy's basement, here it is.
My biggest gripe with MySQL is its convoluted means of dealing with Master/Slave and failover. There is a lot of room for error and painstaking backlogging to repair such.
I have to wonder who designed this and what medicinal drug they were overdosing on at the time.
If my Master fails, Slave takes over, I shouldn't have to spend a ton of time tweaking to get the failover to return back and replicate.
That alone would be enough for me to go commercial, regardless of the cost.
Other than that, the throughput we've had has been fine - though our application is not high I/O.
If they had version 6 "break with historical stupidity," that would forcibly break compatibility with legacy applications, and it would pretty much eliminate any argument for remaining with MySQL.
After all, if the migration to version 6 requires rewriting your applications, isn't that a "breakage" significant enough to cause decision makers to say: "Hmm. They're requiring me to rewrite my applications. At this point, there isn't any reason not to open my choices wider, and consider other DBMSes, is there?"
That's one of the reasons, I expect, that Windows Vista didn't have so many Longhorn features in it; if it's fundamentally a totally new (and significantly incompatible) platform requiring substantial redesign of applications, people will think more than twice about adopting it. The same sorts of things hold true.
If you're not part of the solution, you're part of the precipitate.
A goodly number of pro and con arguments were presented there; Tina evidently sought to glean the ones that she could keep as unambiguous ones. She failed, on the "price" one, in that most of the other OSS database systems don't have a MySQL AB ready to collect licensing fees from you...
If you're not part of the solution, you're part of the precipitate.
"was the problem with MySQL the database software itself, the hardware used, or was the problem with how the schema was designed and/or the application code?"
Does it really matter? Some senior architects pointed out to the MySQL guy, since they fired. Either those seniors had no clue (in this case that Fortune 100 have more serious problems), or it was the MySQL guy in fact the one to blame (well, on a corporate environment things are never so black-and-white, but it's good enough for a first approach).
Now, I think you have your points but still, don't understand the issue. Let's see this way. You are on the HR department trying to fill a position; you have two hundred resumes and you know from previous experiencies that around ten out of those two hundred will quite fit the post. You start doing a first cleaning: you go for those with proper certifications, past experiencie and the like; in half an hour you have detected a very suitable candidate. Maybe one of those without certifications is very good for the post; maybe one of those without previous experience is a genious. Are you going to loose another four or five hour to know? Surely not: in half an hour you have a perfectly suitable candidate, so to the hell with the other 199 resumes. Will you loose a better candidate from time to time? Probably yes. Will you get the best possible candidate? Probably not, but you *always* will get a fairly good candidate on record time: that's efficency and it's a very good quality on a corporate environment.
Again with MySQL: it's *very* adecuate the saying from the previous poster about it being banned on his corporation on the basis that it is the database of those that don't have a clue. Is it true? Statistically yes. Maybe because it's "too easy to start with", maybe because it made up a strong niche coupled to PHP (which is quite the same: the language for those that don't have a clue). Is it just? probably not. Can there exist the case where a good DBA would make up a good data backend out of it? Probably yes but, efficiency-wise, who cares? Am I going to risk millions on a database I know the one that recommends it doesn't have a clue more times than not when I have a way to efficiently discriminate good DBAs from regular (or bad) ones when using a different tool (say, Oracle) and I do have demonstrable experience on such an environment? No way, sir, no way.
"but you would care to back it up with actual helpful data in any way?"
The point is that he doesn't need to back it up nothing! He is a senior architect who can point to a proven track record of success on -say, Oracle or maybe Postgres or Firebird. He has no need at all to change successfull procedures or tools. It's *you*, the newby, the one that must prove beyond doubt the virtues of the new tool that wants a piece of the cake, not him.
In most systems (probably even including MySQL), a B-tree is an index structure consisting of sets of pages. Each page might be (say) 8K long, so that if the index value were (say) 16 bytes long, you could fit somewhere on the order of 512 index entries on each page.
In that case, the number of index accesses required to access "billions" of rows would be log (base 512) (10^9), so you'd expect to hit the desired tuple in 3-4 page accesses.
(Obviously, if the number of tuples per page is lower or higher, the base for the logarithm changes...)
If you're not part of the solution, you're part of the precipitate.
The real deal on RDBMs...there are 3 serious products. Oracle, Microsoft and IBM.
You haven't said much to support that argument. PostgreSQL is quite a serious RDBMS, and I see no reason why it isn't out ahead of MS SQL Server.
Social scientists are inspired by theories; scientists are humbled by facts.
I use MySQL 5.1.x for my business and when I started I found that this was a well supported engine and went ahead. Now that we've got more experience on it and scratched below the surface we will consider the switch (propably to Postgress). Here are my reasons:
- support for stored procedure is still in infancy. Expecially error handling. There is no way to raise a custom error and the compiler gives imprecises error messages. There is not trace mecanism to troubleshoot them.
- the availability of multiple storages back-end may appear as a feature but I believe this should be handled internally. Especially some critical features such as referential constraints are implemented on SOME back ends. This complicates the DBA job tremendously.
- the first back end to support ref. constraint is InnoDB. It has been acquired by Oracle. It is unclear what will happend. Can a GPL licence be withdrawn ?
- when writting a trigger, it is impossible to cancel a transaction. This remove almost all interest in triggers.
- the commercial licencing model requires you to pay every year. Although the price are low compared to other commercial DB, this is a major hindrance when someone want to embbed this engine into the produc.
Bascally, for non-critical internal application, MySQL is perfect. For advanced critival applications or sellable products, I have trouble to go that way.
>> Last time I checked, DB2 was more scalable than Oracle
> That depends entirely on the platforms you happen to run them. DB2 on NT (what used to be called "UDB") is a joke; DB2 on OS/390
> is pretty much what defines a "big-iron" database. Oracle on NT is nowhere near as good as it is on Solaris. But Sybase on NT is
> actually quite good - almost as good as SQL Server on the same hardware. Sybase 12.x on HP-UX is also quite good.
DB2 UDB actually scales extremely well for warehousing, decision support, search engines, reporting, etc - far beyond anything except maybe Teradata. If you're talking about NT - you're talking about an OS that is two generations back-level. But aside from that personally, I'd rather run a database on unix anyway - much better scriptable and command-line environment.
I just read the ten pages of comments and added my own. The guy gets slagged totally and deservedly so.
I'm not a big fan of MySQL. I tend to think that it might be okay for serving up dynamic Web sites, but for serious DB work outside of Web page serving where you are manipulating corporate INFORMATION in various domains by dynamic queries that may be complex, it's not that great - in fact, it's pretty weak. PostgreSQL has much better features for use in that scenario.
But the reasons cited not to use MySQL are simply pathetic. I mean, you've got an Oracle DBA, so go Oracle so he's "comfortable"? Supposedly this saves you money over time? WTF?
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
"So, when you talk about how much you gained going from MSSQL to Oracle, I'm pretty sure most of that's because of your preference for Oracle,"
*sigh* Then re-read the comment. I said I was more experienced with MSSQL and had to move. You cannot justly prefer what you do not know so well. I had been working with Oracle for a long time, querying remote databases etc, but that's a far cry from actually designing an application's database on an Oracle server. Then you have to know the nuances. Now I know both Oracle and MSSQL well, and I prefer Oracle.
Indexing is totally different in MSSQL and Oracle. For example, the clustered index in MSSQL is the most important index there is. In Oracle, there is no such thing (there are cluster indexes, but cluster has a different meaning in Oracle). So this means that you have to think totally different about indexing an Oracle DB. Honestly, I am not sure of what exactly behind the scenes makes Oracle indexes more efficient (or seem more efficient). But my experience is that querying Oracle is very fast, much faster than MSSQL.
MSSQL feels like a toy when you are used to Oracle. Not to say it's a bad database. I like MSSQL. But for high volume, high availability, high traffic websites, in the corporate environment, I'd choose Oracle. At home, I'd choose MySQL. Because it's better than MSSQL? Not so much. It's about the same, to me. But the difference is the price. MSSQL ain't free, unless you want a junior version. So MS has priced what is a very competent database out of the market. It's not as good as Oracle, not as free as MySQL. That's a tough spot to be in.
blah blah blah
Did you read through the docs you linked? Using STRICT_ALL_TABLES will cause MySQL to reject some invalid data, but will let other data get through. From your link:
More generally, the tangle of interacting configs needed to make MySQL behave in a still only approximately sane way gives the lie to the myth about it being so easy to set up and use.
Are you adequate?
You know, that new default is not really an improvement. The behavior every other database has in the same situation: generate an error and roll back your transaction.
Are you adequate?
See Spot Run. Run Spot Run. LOL
I can now see why you hesitated to clarify your wordy evasions instead of worthwhile technicals.
If words like "scalable" and "transaction" are your most important criteria, you listed those not I, your systems must be in disarray or in decline. Harvard once determined that only 1 in 100 experts can clarify adequately. sigh.
It is MBA types like yourself who quickly turn healthy companies toward the road of decline because you lack formal education that experience cannot fill. LOL
Score & Karma: SASA: Slashdot Approval Seekers Anonymous
"You cannot justly prefer what you do not know so well."
I defintely prefer a Ferrari to a Sienna mini-van, but I know the mini-van so well...
You talk about feel, but you don't talk about comparing Oracle and MSSQL and (DB2) with serious benchmarks (competitor reviewed even). When they're benchmarked and submitted to TPC, MSSQL doesn't win on most tpmC per system. Oracle does. With 4 million to 1.2 million from MSSQL. However on cost per tpmC MSSQL's most cost effective configuration is twice as efficient as Oracle's most cost efficient configuration. So, if you're setting up an $11 million system for your corporation, you're probably better off with Oracle.
http://www.tpc.org/
So, MSSQL might seem expensive compared to MySQL, but it's certainly inexpensive compared to Oracle, and for at least some corporate purposes, it will provide enough performance to do the job.
My point, that developers/DBAs who want to make a product perform do better with that product than developers/DBAs who feel saddled with the product is still a valid point, even inside Corporate IT shops. Even if it doesn't apply to you personally.
Postgres isn't making the list. Neither is MySQL.
"I defintely prefer a Ferrari to a Sienna mini-van, but I know the mini-van so well..."
Fair enough, good point.
Impressive benchmarks. *yawn* Sorry, but benchmarks are pretty much useless. Just a SWAG here, because I don't want to look up every DB vendor, but I'd bet that every DB vendor can point to benchmarks in which their product excelled. Benchmarks cannot take most factors into account that impact real world performance. They are just theoretical wankfests.
Real world performance, not benchmarks, is what matters. Not saying SQL Server is bad. I just wouldn't be as likely to use it as Oracle or MySQL. You feel differently. Fine. I'm glad all those DBs exist so that everyone can use their choice DB.
blah blah blah
However, the term "RDBMS" tends to refer to databases which base their storage models on relational algebra. Because of this, it is *not* designed to do what you say, but rather a whole lot more (contraints, triggers, functions, views, etc). Oracle on the other case, seems to be doing exactly the opposite of what a database is supposed to do - it's encouraging you to push more and more of the application layer into the database (first plsql, and now Java at the database layer?). I share your dislike of Oracle in many areas. Oracle has some strange issues involving comparing zero-length strings and NULL's. This does not seem to me to be mathematically correct, but YMMV. I just want to create tables, select, insert or update data. Not much else. That's what Codd truly intended. Codd would roll over in his grave if he saw the bloated mess that Oracle is today. And you can design a horrible denormalized schema in Oracle just as much as MySQL - neither force any form of normalization at the RBDMS level. (Some applications merit denormalization) MySQL violates Codd's 12th rule, and by my interpretation, his fifth rule as well.
Why are you using SQL in the first place? Why not a simple object persistance layer built on BDB? Or any of a number of other good object databases? That really seems to be what you are after, and it would allow you to avoid coding in more than one language in order to get your work done. Not to even mention the absolute shameful way Oracle considers, manages and patches security issues. No argument there.... MySQL is a simple, free relational cruncher. I can't believe a true finance architect considers Oracle more robust that MySQL, especially when its comes to security. My view is that PostgreSQL is my preferred db of choice. I only use Oracle under absolute duress. Firebird is better but still not preferred.
Oracle has a number of screwy issues that I cannot stand (mostly involving NULL handling, but also I find their concept of schemas relatively backward, compared to most other RDBMS's which recognize that the standard is broken in this regard). However, if I need an RDBMS, and MySQL and Oracle are the last two left on earth, I would be torn between my love of even the approximation of open source and the need to do things in a way which approximates mathematically correct modelling...
Neither one though would score highly on my list of choices.
LedgerSMB: Open source Accounting/ERP
- support for stored procedure is still in infancy. Expecially error handling. There is no way to raise a custom error and the compiler gives imprecises error messages. There is not trace mecanism to troubleshoot them. PostgreSQL's PL/PGSQL allows for custom errors (and has for a long time), and more recently (last couple years) addes support for trapping exceptions without rolling back the transaction. - the availability of multiple storages back-end may appear as a feature but I believe this should be handled internally. Especially some critical features such as referential constraints are implemented on SOME back ends. This complicates the DBA job tremendously. And break's Codd's 12 rules.... - the first back end to support ref. constraint is InnoDB. It has been acquired by Oracle. It is unclear what will happend. Can a GPL licence be withdrawn? No, but they can use it to make life really hard for MySQL AB (the company) which has to resell additional permissions. And they can kill further development. - when writting a trigger, it is impossible to cancel a transaction. This remove almost all interest in triggers.
- the commercial licencing model requires you to pay every year. Although the price are low compared to other commercial DB, this is a major hindrance when someone want to embbed this engine into the produc.
Bascally, for non-critical internal application, MySQL is perfect. For advanced critival applications or sellable products, I have trouble to go that way. I would go back and say that for non-critical single-db app where SQL is the preferred interface, MySQL is perfect. The further you move from that (rare, and usually temporary state), the more problems you will face.
LedgerSMB: Open source Accounting/ERP
The number of comparisons is different from, and larger than, the number of page accesses.
Easy enough, places that want to ship a product (assuming the interface libraries are GPL not LGPL). Or just places that want to ship a product with the database embedded inside it. They might be better served with Postgress, or sqlite. Or licensing Oracle or something (of corse if licensing a database is an option mysql can do that).
Which doesn't mean the article wasn't kind of weak, and half the points aren't lame...but this one at least made sense.
"Sorry, but benchmarks are pretty much useless." When it comes to most benchmarks, I agree with your statement. But even you say "pretty much useless" not "completely uesless." TPC.ORG database benchmarks are accurate and sufficient to model real-world database behavior. Take a careful look at their benchmarks. You might learn something about databases.
You have a database system that instantly solves all communications problems that occur between it and any client anywhere in the world? That's awesome! I can't wait to run one at home so my internet access never goes down.
You already know how to use a Relational Database and don't want to use something inferior to MS Access.
Are you saying that a non-gpl product can not legally be used with MySQL? Because I don't think that is correct.
Also, how common is it to embed an entire database system within a product? BTW: you could not do that with most non-gpl products either.
There is also the issue of quality control. Some of the bigger propietart systems have got amazing levels of quality control versus MySQL
Jack V All the IT vacancies in one place