MySQL A Threat to Bigwigs? 505
Disoculated writes "Is MySQL a threat to bigwigs? is the question asked in CNN's technology section. The article notes that MySQL is running perhaps 20% of the web databases but its revenue is merely 0.02%... yet the company is still making money and putting out an excellent product. Is this a sign that the database market is in for a drastic change? Of course, there's no mention of PostgreSQL or mSQL, but I guess that's typical."
Comment removed (Score:5, Insightful)
Re:And the answer is .... (Score:5, Insightful)
Again, technical correctness doesn't always win the day.
Postgresql was way to hard to install... (Score:2, Insightful)
of those typical macho open source projects.
Installing the database was as big an effort
as using/developing something with the database.
They forgot that a typical Database developer
is not a sysadmin. In typical low budget web
projects, the developer has to be the sysadmin
as wel. Installing a database should
be as easy as possible. Developing a good
DB-application is hard enough on its own.
The postgresql is now paying the price for their
arrogance/ignorance.
Things may have improved now, but after I gave
v6.3 a few tries, I quickly turned away from it!
Regards
Re:Version 4 Will Tell (Score:5, Insightful)
Re:Postgresql was way to hard to install... (Score:3, Insightful)
20K reasons why it is (Score:1, Insightful)
Its well integrated into just about every web development system you can name.
With PHP or perl you can roll out a small interactive site in less than a day.
At least you can figure out how much it costs. I can't say how much customers love hearing about ORACLES price by the system you install it on system.
Its not one of Microsofts line of swiss chese products that have more holes than a typical sieve. Slammer worm anyone ?
Oh yeah MYSQL is a threat. Software that works and a revenue model that depends on satisfied customers.
Crash
postgres, schmostgres... (Score:1, Insightful)
I'm sure that a lot of uber programmer types are going to say "if you can't figure it out, you're a jackass", etc etc... but the bottom line is too much easy stuff is a pain in the ass to do, syntactically, with Postgres... Even auto incrementing IDs in Postgres are annoyingly difficult compared to MySQL...
I am well aware of the cool stuff that postgres does, but a lot of that cool stuff is only needed by people with specialized purposes.. your average blog site or even e-commerce site doesn't really need nested queries and all that stuff, so why go through all the syntactical annoyances when doing a simpler site?
When pg gets easier to use, i'll make the transition...
Re:If MySQL was just a bit more user-friendly... (Score:5, Insightful)
Fully indexed, with user comments... I often find new techniques while searching for something completely unrelated. I think the great documentation is one of the reasons why MySQL has taken off, it's just so easy to learn.
Doug
Fair price? (Score:5, Insightful)
The other thing is, why, exactly, should the price of database software be so high anyway? If the company behind it is able to make a profit then I'd say that the price they set is a fair one. That's a concept that gets lost a lot in a pure capitalist approach: just because you can charge more money for something doesn't mean that you must, or even that you should. People on
Re:And the answer is .... (Score:3, Insightful)
The more professional back room Postgres usage means it doesn't get much notice.
-Pete
Re:typical (Score:2, Insightful)
When you hear about a new "scripting" language, they're always hyping up these whiz-bang features that languages like Lisp and Smalltalk have had for 30 years. Never hear about languages like Haskell that might be doing something original. (*ghasp*!) Ok, not never, but rarely- probably less frequent than you hear about NetBSD or OpenBSD.
People are generally too stupid to be interested in much other than what is the most popular at the time. Nothing new.
Reason why PostgreSQL or mSQL weren't mentioned (Score:5, Insightful)
From the posting:
Of course, there's no mention of PostgreSQL or mSQL, but I guess that's typical.
This article has all the signs of being the effort of MySQL's PR firm. Nothing wrong with that; they didn't mention PostgreSQL or other OSS databases because their desired outcome is to increase awareness of MySQL, not the others.
Cheers!
Eweb databases != database market (Score:5, Insightful)
our company actually puts mysql onto websites, but no client comes (at least for us) and says 'can you replace my blah-blah db version blah point blah with mysql'. we usually put mysql as a replacement for product databases, forums, etc. which previously were stored in text files or worse. and we usually do this for clients who simply can't afford anything and haven't invested into updating their site in 1-2 years. if they can afford it, they usually already know what they want, and it usually doesn't come free in a cvs snapshot.
Re:Ethical obligation? (Score:3, Insightful)
If you don't think that businesses (to a lesser extent, individuals) have an ethical obligation imposed by the community to share modifications made to an OSS project, you haven't been reading Slashdot or other forums of Free/OS software discussion. Hell, half of the "Ask Slashdots" where someone is asking about some whether application that does x, y, and z exists for Linux, there is always a big hunk of replies stating "this is OPEN sourze d00d write it yourself and share it with the world. otherwise, you don't deserve to use OSS- even if this app already existed." Yes, it's a stupid attitude (IMHO), but quite real in the community.
Who Wants To Be A Millionaire? (Score:4, Insightful)
Re:If MySQL was just a bit more user-friendly... (Score:3, Insightful)
Furthermore, look at the dead-tree documentation available for each. Not only are there more MySQL books available than PostgreSQL ones, but the MySQL ones tend to be larger. For example, the New Riders MySQL book is over 400 pages longer than the PostgreSQL one - and their MySQL title isn't exactly brimming with filler. I'm convincesd PostgreSQL adoption will lag behind MySQL until more/better docs show up so people can learn it and its capabilities better.
Re:If MySQL was just a bit more user-friendly... (Score:3, Insightful)
So that's great, you blog well in PHP, but you utterly overstate the power of MySQL. MySQL will not even approach taking on the big database apps until they have a) subqueries and b) true ACID support. Many complex websites have stored procedures with subqueries in them, and it's logistically impossible for these sites to migrate to MySQL, since it would involve rewriting anything with a subquery (if it's possible at all without nasty temp table hacks).
And not having ACID (atomicity, consistency, isolation, and durability, btw) support? No enterprise-level website, especially one that does eCommerce, would ever think of running a database without proper transactions.
So, yeah, MySQL is great at handling small- to mid-size loads, but once you get to high complexity or you need transactions, it's over. Maybe if they include this stuff in version 4 and it survives a couple of years of testing, THEN we might see some significant migration, but it will not happen until then.
Re:postgres, schmostgres... (Score:5, Insightful)
Nah, they actually make much more sense in Postgres than they do in MySQL because you can access them using a standard query rather than some bozo non-standard driver extension as in MySQL.
The problem with MySQL is that the lack of basic functionality like triggers, subselects, foreign keys makes it a total PITA except for the simplest applications. Sure you can write code that works around the implementation limitations, but WHY should I have to reinvent something over and over that should BE PART OF THE DATABASE?
You may think this stuff is esoteric, and not needed for the average blog or even e-commerce site, but that's baloney. FKEYS *ARE* needed for just about *ANY* database application except the most trivial - ie. an address book.
MySQL - forget it - it just isn't competitive with other free databases out there.
MySQL vs "bigwigs" (Score:1, Insightful)
Or I can pay $300 for a MySQL commercial license and if I have any problems or additional functionality there are thousands of web sites with tons of free advice and code. And MySQL will blow the doors off of Oracle and other databases in terms of raw speed. Advanced options like data warehousing, replication, fancy triggers, rollbacks and other systems can be sometimes better-integrated on a hardware/os level so it's arguable as to whether MySQL's lack of some features is even a negative. You get more with less all around with MySQL: better support, more rapid bug/security patches, less hardware requirements, and more people in the online community who are willing to help without charging you by the hour because of their pretentious DBA title.
Tough choice...
Mindshare (Score:5, Insightful)
Re:Trouble for the bigwigs? (Score:3, Insightful)
Re:Version 4 Will Tell (Score:5, Insightful)
The bottom line is that Oracle (and other enterprise DBs like MSSQL, DB2) have enterprise features that MySQL (and other open source DB's) just don't have, and probably won't have for Years. It's more than just the ability to scale, and raw performance on simplistic tables.
Most everyone is very much aware of MySQL and other open source solutions are great for certain types of applications, but horrible for others.
That said, many enterprise users use Oracle in cases where MySQL would be much more cost effective, and probably better performing as well.
transactions (Score:5, Insightful)
Lots of message boards on the web use MySQL as their database, because even though people are uploading comments, the amount of data that they upload isn't all that much. Slashdot for example, a popular discussion could prompt 500 messages to be posted in 15 minutes, but still, that's not that much information.
The key word here is transactions, the constant reading/writing, downloading/uploading of information on a massive scale, where each occurence is audited. And I think that's where MySQL has its weakness. PostgreSQL is supposed to be a bit slower, but it takes transactions into account. Red Hat's database software runs on the PostgreSQL engine specifically because of this.
Banking and finance applications require this accountability, because it's just that important. Websites don't need that accountability and overhead, which is why MySQL shines for web servers.
Re:"Ethically Obliged"? (Score:5, Insightful)
That is how I read that statement, and from that standpoint, the author is correct.
"rollbacks" are an advanced feature? (Score:4, Insightful)
Commit/rollback is an essential component to any decent data management system. Until you are absolutely sure that your data is correct -- that is to say, until you have done all of your transactions on the page successfully -- you should never actually write data to your database. Without using commit/rollback, you are stuck with the haphazard method of trying to manage potentially disastrous records of data showing up in your db.
Your other quote: "And MySQL will blow the doors off of Oracle and other databases in terms of raw speed" is similarly incorrect: MySQL may be faster when you are dealing with a small amount of connections, but as soon as your application starts getting any amount of concurrent users, MySQL is famous for falling down rather rapidly as it strains to write its data to disk.
MySQL cannot scale reliably, period. Having two database systems act as a pool, under MySQL, is a crapshoot at best. Unless you like designing single points of failure into your web applications, stay away from MySQL.
Simply put, if you expect your web application to get any amount of decent traffic (say 100,000 pageviews+ per day), then MySQL is simply not an option. Oracle is simply the standard upon which others can only attempt to compare themselves to. MySQL may be fine for the low-end "check out my k00l dynamic site!!11!!" crowd, but for professional web applications, MySQL has a long, long ways to go.
Missinfg Features (Score:5, Insightful)
All those who can live with less, well, IMHO having these features still makes development of sound applications so much easier it pays off having it. PostgreSQL has most of Oracles features, conforms fully to ACID, costs the same or less as MySQL (nothing, compared to MySQL which is virtually useless free without the commercial table handlers), and there are some companies supporting it too.
In my experience an application which does correct error checking and handles faults etc. is not faster in MySQL than in most other DBs, just harder to write. And there are alternatives to PostgreSQL, if you don't like it.
Jürgen Strobel
Re:Version 4 Will Tell (Score:2, Insightful)
ReiserFS is trying to become a database. The first step was making ReiserFS v3 perform well on small files. (the idea is to store tree-like/XML-ish data in a directory structure where each file contains only a few bytes of data). Last I heard, ReiserFS v4 was moving towards a full transaction API that will allow atomic batch transactions on more than one file in a single system call. (aside from the space overhead problems inherent with storing tiny amounts of data in each file, most current filesystems don't allow atomic transactions that involve more than one write to one file...)
Re:Version 4 Will Tell (Score:3, Insightful)
Isn't that what Microsoft calls the Registry?
No. It isn't. (Score:5, Insightful)
PostgreSQL is a threat to the bigwigs, however.
This is not to say it won't change. MySQL apparently is trying to implement features that would make it compete with real relational databases, but last I heard, views weren't on the list, so I'm not holding my breath.
Other OSS projects that may be a big threat include SAP DB (used to be Adabas D) [sapdb.org] and... uh... right. There you go. Reply if you're a real DBA and think there's another competitor in the space of true relational RDBMSs. Hint: If you think MySQL could be on the list, you're not thinking of industrial strength databases.
Re:Version 4 Will Tell (Score:2, Insightful)
However, if you are a bank with multiple branches or a Wall Street institution, I don't see MySQL making inroads there. Oracle and Sybase will continue to rule those markets because those apps are already written and work. Proven transactions, complete SQL support, stored procedures, triggers, sequences, etc., means that when it comes to managing money Oracle, DB2 and Sybase will continue. MySQL will make inroads at places not tied to legacy systems, and for tasks that don't require the feature list that Oracle can provide.
For some people, a Humvee with GPS, TV, generator, and a satellite connection is required. For others, a Toyota MR2 with A/C is all that they need.
Oracle is preferable to me & my company. (Score:3, Insightful)
Sometimes paying a little can save lots more in the long run. I personally hate Transact SQL but it's probably because I started on PL/SQL first.
However, that being said I just don't understand some of the stupid ass implementations in TSQL.
MySQL is great because it's small, cheap(free), and very reliable (in my usage). Plus it's got that great JDBC driver that some guy wrote (name?) and the MySQL people hired him (way to go buddy!).
Oracle just seems to have the whole ball of wax. I've never felt I'm trying to program (stored procedures) around a piss poor implementation (like TSQL). So for my (and my companies) money I still say Oracle is the way to go. Plus, I have yet to see the reason to migrate from 8i to 9i.
I'm seriously considering implementing Oracle Financials as well. Show me the MS or MySQL product that can compare to that!
Re:postgres, schmostgres... (Score:2, Insightful)
ie. an address book.
And even then, you should be using LDAP.
Re:Version 4 Will Tell (Score:3, Insightful)
Re:I wonder who mysql steals marketshare from? (Score:2, Insightful)
This shows how much postgreSQL can really scale.
Re:Fair price? (Score:5, Insightful)
If MySQL evolves into a legitimate competitor to Oracle, *in the same market*, then it will instantly become necessary to reinvent MySQL. Perhaps we can then call it "Classic" MySQL.
I use MySQL specificly because it is *not* Oracle, or even anything like it.
And that's without even getting into the fact that using grep and perl on text files would be the appropriate technology for many of the uses MySQL and other small footprint databases are currently used.
Hammers come in a variety of shapes and sizes because so do nail like fasteners. Nail like fasteners come in a variety of shapes and sizes because it would be idiocy to hang a picture with a railroad spike.
There's a saying, "The right tool for the right job."
Perhaps you've heard it before?
As for your second point, virtually all software is ridiculously overpriced on a *fair* market value basis. They are able to get away with it in corporate software packages because a) The software generally replaces even more expensive services, and b) Because corporate buying policies are retarded due to the fact that most of the buyers aren't taking the money out of their own pockets, so, as my granny used to say, "What the fuck."
KFG
Not really (Score:5, Insightful)
- Microsoft Access
- Flat files
- XML files
- Static content
- Client-side scripting
- A large-scale database being drastically underutilized
to perform their various functions. In most cases, those functions would be faster, easier to implement, and simpler to manage using mySQL.For applications with these types of functions, which do not include complex queries, large transaction volumes, rigorous reliability including transaction log backups, recovery, replay, and replication, mySQL represents a major force. Unfortunately for mySQL and those who would have it take over the world, there's not much money available for those applications. Therefore, expect to see mySQL's installed base continue to increase while its revenue-based market share remains small.
For applications which do require features and levels of reliability and capability not offered by mySQL, postgres is the only serious freely-available contender. Even so, postgres is also somewhat less capable than Oracle or DB/2 and will be confined to the middle tier of applications - those which require better reliability and scalability than mySQL can provide but for which funding is scarce. Postgres probably does represent a serious threat to Microsoft's SQL Server, if only because Postgres is platform-independent and supports platforms which can scale beyond anything Windows can run on. Both are otherwise middle-tier products which are not and will never be taken seriously by the largest and most demanding database users.
Who are those users? Banks, government agencies, stock exchanges, payroll and records processing firms, insurance companies, large multi-site call centers, and other huge-scale enterprises. The top proprietary databases offer capabilities that do not yet exist in the Free Software world. For these users, who are less than 1% of all customers but which represent maybe 80% the revenue in the market, there is no substitute. These customers will stay with their existing solutions - Oracle, IBM, Sybase - until the systems running them give out. Then they'll call that company's professional services department and offer them a few million more to upgrade the system. That's the way it works. The system has to be attacked one customer at a time, an expensive and time-consuming process consisting of many lunches, legal bribes, and unrealistic promises.
I think the answer to whether mySQL is a significant threat to dominate the market economically is pretty obvious. Even if mySQL moves up to the middle tier to compete with Postgres and MSSQL and is installed in every application for which it is suitable, the product would still command less than 10% of the revenue in the market.
What a silly question.
Apples and Oranges (Score:5, Insightful)
On the other hand, if I'm dealing with a company that can't toss around the kind of money that you have to have for an Oracle DB, MySQL is my number one choice. I can slap the GUI of my choice on it, take care of data security with a hard backup and pocket a few grand of pure profit that I didn't have to spend on liscensing. You can argue Postgres, but I've never run into a case where I couldn't work around those features that haven't been implemented in MySQL yet.
The one thing I can't stand is when someone suggests: "I can't afford Oracle, so lets' go with a MSSQL database." That's like, I can't afford a space shuttle, and a ferarri isn't good enough for me, so I'm going to buy this million dollar llama instead because 1000 marketing agents can't be wrong, right?"
It has all the same feautres as Oracle, it's just that the features in Oracle WORK.
Just my
Re:MySQL DOES have sub-selects (Score:3, Insightful)
This is a pathetic excuse for a MAJOR lack of functionality. If a query can be rewritten to avoid the sub-select, why didn't the MySQL optimizer just do so?
Until a database can support transactions, subselects (yes on UPDATE/INSERTs too) and views (one of the most fundamental relational features) it has no business pitching itself as a real relational DBMS. MySQL is a glorified file system, and works well for people who need a SQL-like interface to a fast file system.
Re:The odd thing about MySQL (Score:3, Insightful)
I use postgres when I'm concerned about data integrity, and speeding up writes to the database- if I'm doing a sufficiently complicated write to the DB, postgres' stored procedures make it a much better idea. I've used it for embedded-type monitoring and data collection applications.
So there are situations where one or the other is better- like sometimes perl is better, sometimes C is better. Different tools for different jobs.
Get serious (Score:3, Insightful)
Is this a joke ? Forget, for a moment, the conclusions we're supposed to draw from 1) the observation that MySQL may run a lot of websites (this is about as relevant as pointing out that Hyundais outsell Ferraris - doesn't mean that Hyundais are superior vehicles), and 2) a lot of commercial websites might run MySQL (also about as relevant as pointing out that companies buy more Ford Focuses for their fleets than Hummers - doesn't mean the Focus is a 'better' vehicle than the Hummer).
mSQL is about as far away from providing the feature set of MySQL as MySQL is from providng the feature set of an Oracle or PostgreSQL - which is to say, worlds away. Sure, MAYBE mSQL is the tool for a particular job - but then we have to ask, are flat files a threat to the mSQLs and MySQLs - hell, the Oracles- of the world ? After all, flat files are free and we know they're in wide use in lots of companies.
Re:Reason why PostgreSQL or mSQL weren't mentioned (Score:3, Insightful)
That is the way that things tend to work in the magazine world. In this case, since MySQL is not that big a fish, Fortune's editor tells some junior writer, "Forbes and BusinessWeek have run articles on open source software in business. Do something on open source databases." The junior writer then looks at the figures, sees that MySQL is the most popular of the OSS db's, sees that there's an actual company behind them, and calls up MySQL AB's press office. Said PR firm basically sends him an outline, with relevant quotes from luminaries, and junior writer bangs out a story from that outline.
Moral of the story: magazine writers are lazy.
Re:Version 4 Will Tell (Score:3, Insightful)
Much of the time, someone starts working with flat files and ends up wasting a lot of time writing, testing and debugging code that simply does the file handling work. Sure, a database may be considered "overkill" for some tasks, but most of the time it's worth it just for the time you save not worrying about that extra layer.
Plus, it is a heck of a lot easier later on to:
- modify the database schema. eg. Even if your specific program doesn't need additional columns, you can add some which will be used by another program. XML can help alleviate some of that, but it's bloated so using a database instead really isn't really any more overhead.
- multiple user access
- security!
- easy to backup/restore
- ACID properties
- multi-language support
- so the next person to be in your position will know what the hell is going on.
- tons of other things you'll say "oh yeah" about down the road when your flat file system code doesn't cut it anymore.
Where are flat files good? Client application settings, documents to exchange with users, simple and single-user data.
Re:Mindshare (Score:4, Insightful)
Much as I wouldn't hire someone who's sole unix experience was with Linux (for any position other than Junior anyway). You simply learn a slew more tricks of the trade when your experience is diversified. When making a decision, you can usually back it up with a decent reason rather than simply "It's what I'm used to".
Nothing against Linux or MySQL. I've said the same to people who have solely used Oracle on Solaris.
Re:If MySQL was just a bit more user-friendly... (Score:3, Insightful)
Re:Why not mySQL? (Score:3, Insightful)
Well, the ACID qualifications have been satisfied by MySQL through the InnoDB handler for over two years. Other issues, such as advanced SQL features, are still in progress.
But to the original point, I think it's a good thing that MySQL doesn't think that ACID is important. They have different priorities. Their priorities do not lie in making a database that conforms to someone (anyone) else's theories of the perfect database. They implement features that are requested by their customers (pay a minimal licensing fee and you suddenly get a much greater voice in the direction MySQL is taking) and their overriding goal is to implement those features as efficiently as possible, so that speed and performance aren't sacrificed for feature bloat. They tend to implement their features along the line of standards, but they also through in numerous "extensions" to that standard that make way for faster processing and quicker development time. That sounds to me like an excellent way to run a software project.
With that said, they have a roadmap for implementation of various features, including subselects, triggers, etc. and they've already explained why one is getting implemented before the other. If you think a really, really important feature is missing, pay them some money and then say, "Hey, this is a really important feature to us and we just gave you $XXXXX."
Re:Have a look at SAP DB before talking about thos (Score:5, Insightful)
But for some reason people ignore it. Is it because it is created by a company and not a group ? Or is it that everybody has already chosen their favorite free DB and won't look at others ?
Sure beats me.
Re:transactions (Score:2, Insightful)
MySQL is not good for reading and writing the same table at the same time.
MySQL is lousy at handling writing and slow readers, enough so that I'd put slow readers on a separate slaved system.
If everything serializes nicely in the allotted time, MySQL will perform beautifully. When it doesn't, you get a cliff-edge like thrashing in the old time-sharing systems. When it doesn't, you'll find you need a much bigger and faster system.
About transactions. They are logically required when you have two or more things to update that must both succeed or both fail. The downside of transactions is that your transaction can fail for reasons outside of what you're doing. If you transfer funds from checking to savings at the same time that interest is updated on your savings account, One of the transactions had better fail. Now life gets interesting if the bank cannot update interest payments because customers are messing with their accounts.
Re:I think PostgreSQL is more of a threat (Score:5, Insightful)
I don't know about MySQL 4, but the biggest problem is that MySQL seemed to emphasise speed over robustness.. Large scale benchmarking in the 3-tree caused corrupted databases. postgres has had a journal for a little bit now (don't know how long though). Plus postgres's version-based rows allows for some really high performance parallel transaction control.
It all comes down to what you are really trying to do.. If you're willing to lose a day's worth of work, and you're not going to have more than a couple dozen simultaneous connections, then MySQL is probably good for you.
Perhaps 4 has allowed MySQL to catch up with Postgres / surpase it, but it's had too murky a history for a lot of businesses who rank data-integrity number 1.
Re:I think PostgreSQL is more of a threat (Score:5, Insightful)
I can. I have, many times.
These lead me to suspect that your implementation was broken. I've never seen them happen.
Hey, what? You can't store dollar signs and garbage in an integer or float, you shouldn't be trying to feed that to your db in the first place! If you want to do that kind of thing, amidst a `live' table is not the place for it: use a temp table and do it properly. Whis is probably why the PostgreSQL people didn't implement it.
I hope you've got a lifespan like Methuselah's, then. PostgreSQL does stored procedures in a variety of languages already. Your post does sound like a BASIC programmer grunting and squealing when presented with a real language that insists on him doing stuff like decalring variables, and has scoping etc, forcing him to do `work' (actually investing in manageability) that he didn't have to do before - at least, not up front and in small doses.
Re:I think PostgreSQL is more of a threat (Score:5, Insightful)
So no matter what happens, your database will eventually fail and lose power. Even if the power is 100%, the db software and/or OS will crash.
And yes, oracle crashes
Summary of arguments for MySQL (Score:3, Insightful)
None of the above is new information. Just my personal summary. In short, (ie. in troll) the argument seems to be simply: "Yes, mysql is pathetic, but so are most of us." Great.
Re:Version 4 Will Tell (Score:4, Insightful)
One thing that probably keeps a lot of users (esp. web people) loyal to MySQL, is the fact that they learned SQL on MySQL and don't really know what else it should be doing for them.
In fact, that is where I am right now: just realizing the limits of what MySQL can do and tired of writing various hacks via PHP or Perl to get around certain weaknesses.
But I think that a lack of SQL culture could keep many users locked into MySQL when other DBs might be better for them.
Features / cost not the issue (Score:3, Insightful)
It's the applications support. If you are buying a $5M ERP, CRM or whatever, it's going to support Oracle, and possibly DB2 or MS/SQL. In order to "port" to another DB, it's going to take a Huge effort with vendor support.
When third party commercial developers start supporting open source DB's, THEN you will see enterprise adoption. In order for commercial developers to start supporting OS DB's, they need to see enterprise demand. Before you will see enterprises requesting MySQL support, MySQL needs to have the feature set needed to support those applications (such as triggers, stored proceedures, etc.) and enterprise level support for clustering, load balancing, replication, etc. MySQL is beginning to get some of these features, but it's not NEARLY at the same level as Oracle.
It's the same situation as it is with operating systems. If the applications you need for your business are only available for the Windows platform, what real choice do you have?
Re:I think PostgreSQL is more of a threat (Score:3, Insightful)
this is not the fault of the DB this is the fault of the data-owners.
Obviousally your clients have very little value to their data as they do not have the proper equipment to protect it. Power switches getting bumped? what are they running on someone's old dell desktop in a closet? Buy a Compaq ML530 or other real server instead of running on junk. I have to hold in the power switch for 10 seconds before it starts a shutdown because of the configuration I have. a full power crash means unlocking the back of the server rack and unplugging the 3 power cords from the power supplies. As for UPS, I have a APC1400 rack mount for each server and the batteries are replaced YEARLY as well as the UPS's tested weekly.
we value our data, and it costs us $10,000.00 for every day of lost data. so spending money to protect that data is important to us.
Obviousally your clients do not have a high cost or high value to their data or they really dont care much about data loss, otherwise they would invest in server class hardware and other assurances. I can only imagine the nightmare that is their backup solution if they have such low quality IT equipment in place that your stated problems actually affect them.
Re:Version 4 Will Tell (Score:3, Insightful)
SQL comes into its own as soon as you have more than one logically distinct but related set of data. SQL allows you to query that data in arbitrary ways not necessarily catered for in the original design.
Further, XML is a poor way to store data unless you intend to read it all into RAM before doing anything to it. An XML file is essentially a stream of character data which means that it is difficult to index it (making searches slow), difficult to insert records into it (well you could just append new data thus making searches even slower) and not space efficient (lots of extraneous syntax which is only there to make it easier to export to other apps + binary data has to be stored encoded as character data in some way which invariably makes it bigger).