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."
Oh, boo-hoo, dual-license bad!
The rest of the article is equally stupid. For example, "If you already own proprietary licenses ..." has NOTHING to do with whether Mysql is a good fit or not. Next it will be "I hae Pepsi in the fridge; I really want a glass of free cold water or a bottle of Coke right now, but I'll buy some more Pepsi instead seeing as I've already standardized on it".
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...?
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...
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
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.
Oh goody! I'll help get things going:
Happy Memorial Day!
Happy weekend to you, too!
I prefer Flambe as apposed flamebait.
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.
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.
Just junk food for thought...
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.'"
The 5 reasons to use it are far more informative than the 8 stupid reasons not to use it.
It boils down to corporate culture.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
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.
Heh, I think Larry Ellison also added a special JIS encoding mode which gives you kind of an unagi flavor ;->
Of all the reasons to not use MySQL, and there are a lot, the licensing is probably the least likely to convince someone to use or not to use it. And the author presented those reasons in a stupid way, giving ridiculously stupid ways the licensing could effect you.
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.
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.
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!
to be fair, water, coke, and pepsi all use basically the same syntax ;]
--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.
I initially came across this article when no one had posted anything. It's a good thing I didn't waste my time reading it and just came back for the good stuff. The article is probably boring but I agree that the the flame war could should at least be interesting.
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
Use the Preview Button! Check those URLs!
That is, unless you WANT us to go to that add-infested parked domain.
Free beer is never free as in speech. Free speech is always free as in beer.
> 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?
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.
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.
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
Interestingly, despite the fact that I almost never recommend MySQL, I do agree that the 8 arguments opposed were not that wel thought out.
My comment to the article was:
First, I do not recommend MySQL frequently and I figured I would explain why. Although I have no formal training in database design I consider myself more educated in these matters than the average developer.
The basic issue is that, until recently, MySQL has avoided being a classical RDBMS. Instead, it has been developed as a quick and dirty data storage system with an SQL interface. While this is great for some kinds of applications (light-weight web content systems), it breaks down quickly when you need to have many different applications (some commerical, some inhouse) running against the same database. Even MySQL 5 does not get away from this concern entirely (even though the features now exist, enforcing them by the RDBMS is still problematic).
Basically-- if you want a rapid development storage device with an SQL interface for a single application, there is no reason not to use MySQL (aside from the standard Gotchas). If, however, you want to have a more intelligent database which mathematically represents your data as well as possible, and displays these properly to many different client apps, it is still not adequate. Note that the former case has a nasty habit of evolving into the latter case.
LedgerSMB: Open source Accounting/ERP
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
I am not familiar enough with Sybase, IngresII, DB2, etc. to comment on them.
LedgerSMB: Open source Accounting/ERP
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.
Jokes that are true are funny, those that are lies are NOT. Specially when you are not using metaphores as in: "read the PostgreSQL manual eight times".
If you tried to read at least once, you would see that it came long way in 2 years.
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.
In a nutshell, I wouldn't recommend MySQL for mission critical stuff either.
Mission Critical data usually accompanies a staff and a dedicated support plan.
If you want a quick, dirty, reliable database, go with MySQL.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
It's not so much that the reasons are poorly thought out, as that the reasons may not apply to what you have in mind.
You can't talk about reasons to use a database platform apart from the application(s) you are supporting, the requirements you have to meet, and the people you have to support it.
The last point is important. The only database platform that can handle just about any application thrown at it approximately as well as the competition is Oracle. However, Oracle is a massively complex (alternatively extremely tunable), and attempts to simplify it are like pasting smiley faces on an airliner cockpit to make it "user friendly". When you buy into Oracle, you ought to consider buying an Oracle savvy staff along with it.
Like any other product, MySQL works fine in situations where it works fine. The important thing is recognizing that. I do like their integration of network with security. That's innovative.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
Those 5 reasons to use mysql are more informative than those 8 "reasons" against, simply because the majority of those "reasons" are in fact straw men.
...
I mean, ACID compliance being called a "feature" of a RDBMS? Unless your company views its data as replaceable junk that will never be need to be made sense of again at any point in the future, ACID compliance should be mandatory and enabled by default. Surely a comment on this would be useful to CIOs? Instead, all we get is this:
"Feature Set Maturity
However, if the user's temperament is particularly gun-shy toward new technology, the longer-supported feature is the more certain bet. In this case, these three major features are still relatively recent additions. Even as of MySQL 5.0, ACID (Atomicity, Consistency, Isolation, Durability) consistency is not guaranteed in the case of a crash when some kinds of stored procedures or functions are used to modify the database."
If I have seen further it is by stealing the Intellectual Property of giants.
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...:-( )
Wait a minute. Doesn't MySQL AB offer dedicated support plans, training, and certifications?
What's your definition of a "real database" then? I wouldn't think you would say that anything not fully conforming to ANSI SQL isn't a real database because I don't believe any RDBMS fully conforms to the spec (it's huge).
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
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.
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.
What is it that you are proposing as an alternative? I hear alot of complaining, but you dont see to be offering anything else that might work better.
... back to the original point. Storing large amounts of heterogenous data in a form that can be quickly (ie, nearly instantly) read back and added to (in a performant way) is hard. It's easy for small data sets, but gets very hard to solve in a way that scales linearly.
I believe the reason that RDBMS's are the way they are (at the core, not the peripheral feature sets) is that the problem they are trying to solve is a fundamentally 'hard' one (hard in the CS sense).
I believe if you tried to solve the data persistence problem yourself (assuming a reasonable sized data set, figure items in the millions to billions range), you would end up building the core engine of a relational (or maybe hierarchical) database all over again, but it would be tuned to the particular character of your first app's dataset.
Then as you re-used your code and tried to re-use the storage layer, you'd end up just generalizing your code. Do this for about 10 years of evolution, and whammo, you've just re-invented Oracle DB.
Also note that you can get by just fine for data storage using just standardized SQL (maybe a few dialectical issues like semi-colons, statement delimeters, etc). So from the app's point of view you're just talking to a generic database. Hence the upsurge in use of DAL's and ORM's in the industry the last couple years.
Then do your optimization at the DB layer, where it is invisible and abstracted away from your app layer.
But
Now I'll grant you that all the major DB vendors do add alot of cruft onto them, and seem to be moving towards a full blown mini-OS and platform. But thats really tangential to their primary use, which is just storing and retrieving structure data while maintaining data integrity. And you can do that with anything, including Oracle, without ever touching PL/SQL or any other oracle-specific bloat features.
What is it that you are proposing as an alternative? I hear alot of complaining, but you dont see to be offering anything else that might work better.
I believe the reason that RDBMS's are the way they are (at the core, not the peripheral feature sets) is that the problem they are trying to solve is a fundamentally 'hard' one (hard in the CS sense).
I totally agree. (said something simular a while ago) The link to the real world and it's limitations has to be the way it is in most places. I even don't see a problem in having a persistance layer with the bazillion means of configuration such as MySQL. It offers the needed flexibility and learning about the details here isn't pointless.
However I do expect an alternative to SQL and it's countless dialects. As I think I brought across quite clearly in the above post. The alternative being, of course, no second language at all. Or should I say 'no extra language per DB in use'. All open source languages I know of offer wonderfull devices for filtering and moving data from A to B in every which way one could imagine. Each and every SQL variant is at least 5 steps back from all of these.
Let's look at PHP for an example:
#Possible PHP way (current):
array_search($user.names, "Miller");
#Possible PHP way (fictional persistance layer integration):
$user.names['miller'];
#SQL way for PHP:
"SELECT * FROM user WHERE name=".$myName.";";
Now it's given that PHP isn't the most elegant of OSS PLs and that it's well within it's achestors tradition (Perl) in being a tad quirky. But it hardly get's any more complicated and weedy in PHP, no matter how complex your requests are. But try linking 3 entities in SQL and comprehending the error messages while trying to do that in any Database and you know what I'm talking about. Perl, Python, Ruby, PHP, whatever only would need a handfull of additions to deal with any solvable problem that occurs when connecting to the persistance layer. And no, what goes through as 'Database Abstraction Layers' nowadays is not what I'm talking about. Just ponder the concept of DBALs for a minute and it will strike you how backwards it is. The best we can come up with is automatic SQL generation and for my taste that is just to much overhead for a technology that doesn't deserve to (still) be there in the first place. Whenever I get back to that I feel like I'm back in 86 at my Sharp computer and hacking it with Basic Peek'n'Poke and Opcode. At least that made sense in making my code faster and more flexible.
What I'm basically saying is this: The devices and concepts SQL offers for handling data are so out of line of everything else we deal with it isn't funny anymore. I have no problem with RDBMses and I have great respect for people taking on the task of dealing with our HDDs and taking the load of Filesystem developers for another few years. But why this all has to happen seperate of all the other stuff that has moved on so fast in the last 10 years I really don't understand.
Let me emphasise yet a little more by giving a proof positive for things that can't be stopped from sucking: XML. XML is relatively new. But XML sucks. But XML sucks because it serialises n-Dimensional structures. It squishes them into 1-dimensional streams of data. That's a classic hard problem in CS - and it will allways suck. Until the end of the universe it will. Considering that, XML is a perfect solution (RelaxNG fans, please don't get nittpicky) as it is our way on agreeing how this problem can be expected to suck. Thus I can focus on getting my data in line when dealing with XML, but needn't be to annoyed about the standard.
SQL on the other hand sucks where it musn't. It's old and the people back then didn't know better. In fact, they probably did, but they wrote SQL for to be typed by humans live into a terminal connection. It must have been magic back then for that kind of task. But explain to a CS guy from '78 what we are doing today with SQL (using it for fully automated data linkage and juggling) and he'll shake his head in disbelief.
My 2 cents.
Educated opinions welcome, please join in.
We suffer more in our imagination than in reality. - Seneca
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.
So if I'm understanding correctly ... you want structured and fast (ie, indexed) data storage, without having to deal with the separate domain (and language) of set theory, which is what SQL allows you to operate on.
The problem I see is that if you want structured data storage without SQL (and therefore, without set theory), then you're going to have to give up something. You either give up the incredible value of a relational data store (ie, normalized data, referential integrity, constraints, joins, indexes, etc) and basically use a big cache of dictionaries/hash-maps, or you use a DAL/ORM.
I guess what I'm saying is that the best way we (we as in humans) know how to store data in a robust fashion, that maintains data integrity, minimizes redundancy, and maximizes searchability, is the good ol' Relational Database. Done properly (ie, avoiding just storing everything in one big wide table with many sparse columns), you end up with many tables. In fact, you basically end up with something that minimally represents an ERD, with extra rounds of normalization done on it to reduce data redundancy.
But unfortunately, now you're dealing with a storage structure that is heavily optimized for data integrity (and low data redundancy), and high speed of access (through indexing and partitioning optimizations within the DB). This optimization creates a data structure that is non-trivial to retrieve information out of. In other words, the data is so highly normalized (ie, broken into many small but full tables) that it requires complex set algebra to get that data back out.
Now you could ditch relational data structures entirely, and use something simpler. That will give you simple key-based access to long rows of data from the store.
And that will seem to work great in the simple case, with a relatively small amount of data. But as your data size and complexity grows, you'll start to see problems. You'll have to put lots of data-integrity code in your database, and if you make a mistake, you'll have bad data in your system (orphaned records with no parent, null values where there shouldnt be, etc).
So the problem with that approach is that it doesnt scale. It works decently in small apps where your table structure is nearly exactly 1:1 with your object model (ie, one table per 'entity' in your object model). But you run into problems when your data structure needs grow more complex. These usually revolve around data integrity issues (ie, data that is 'bad' is allowed into the system).
I've seen this happen many times over the years where, for example, someone doesnt believe in using Referential Integrity in the database, and they think it should all be done in the applciation layer. And that works great, until people do direct maintenance loads or modifications against the DB directly, without going through the application.
There's also big performance benefits to a normalized data structure. Because the structure of the data adheres to certain theoretical concepts, the query optimizer has great power to make decisions about how to efficiently access this data. If you move to a big hash-table type structure, you lose this. Performance would be fine at small scale, but access times to data rows would see linear (or worse) scalability as data size expanded. Contrast that with a relational data store, whose access times are very insensitive to data size (ie, a nearly flat response curve compared to data-size).
So I know I'm getting a little strayed from the original concern, but there is a connection.
Reliable data storage requires some sort of specialized storage structure (like a normalized data structure).
This requires a relational database engine (or something like it) to manage the data, and keep it in line.
Accessing data in this format requires a specialized language, to deal with the highly specialized nature of the data storage domain.
So in other words, if you give up SQL, then you must necessarily g
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