Slashdot Mirror
MySQL A Threat to Bigwigs?
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."
It all boils down to how MySQL 4 is looked upon. Big sites already use MySQL, as seen here, but will version 4 have enough features, be robust enough, and provide the support to convince those running things such as Oracle to switch.
We used to use mySQL, but moved to postgreSQL for performance reasons, and we're glad we have.
On the postgreSQL general mailing list, people rarely talk about mySQL anymore (let along mSQL). It's (mySQL) is generally regarded as a good alternative to the Berkeley DB stuff (i.e. non-relational), whereas postgreSQL these days gets lots of traffic from Oracle people wanting to go somewhere cheaper.
Oracle mustn't be happy, I'd think.
Have you ever looked at MySQL's online documentation? It's wonderful...
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
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
There's also a lot of interest in SAP DB
It seems oracle is going nowhere in terms of its core market. I am hoping its eating middle end and low end databases like ms-sql server. Access in the low end isn't going anywhere because of its gui and development tools.
I wonder about Sybase and Paradox which seem to be mid to high end of the market which Microsoft really hurt and now so its mysql.
I tried out mysql and its ok but postgreSQL is alot better for a RDBM. Its no wonder that RedHat picked postgreSQL for its database product. In Asia the situation is opposite of the west and all the technical books are for postgreSQL.
I just find it hard to believe its eating Oracle's or IBM's core markets. Mysql is a simple bicycle vs a high end car in comparison.
http://saveie6.com/
A lot of the viability of any product is based on who is selling it as part of an end to end solution. More and more developers are doing this with MySQL, but most of these developers are doing it for relatively low end applications. The "high class" consutlants and developers will be using DB2 and MS SQL forever, because a) they're told to do so by the people who can fire them b) they're used to it, and used to touting its glory c) they have a ton of tools for it.
Furthermore, there are some applications that just don't make any sense to switch. An example is government databases. I'm working right now with a state government database written on top of Sybase, and i don't think it's ever going to move off of Sybase unless the company tanks. There's actually three pages of (somewhat unfounded) explanations as to why it can't be ported to MS SQL. Mostly bullshit about WACOM SQL being incompatible with Transact (which begs the question, why not just use Transact in the first place when MS' and Sybase' version are about 80% similar). Can you imagine the developers, who have big enough egos to include three pages of MS SQL Server bashing in their docs, redoing their whole bloated app just so it can run on a free environment? Lord no! Not to mention the cost to taxpayers, who have already footed massive bonds to pay the usually high up front costs for software. Think they're going to pay a hundred k for some developers to rewrite everything in a free environment when they could just pay a few thousand for a Sybase license?
Do I think that truly open minded (some would say wise) development houses looking to cut costs on new systems are going to go MySQL? Absolutely. But there'll always be a place for the behemoth server app, not because it's better, but because it's PERCEIVED as better.
Hey freaks: now you're ju
In a job I had to migrate an application done originally in clipper to web/sql/etc, and choosed mysql because I thinked that it will be enough, but if not, the migration to a new sql server will be a lot faster and less complex than the first one.
all ms software is 'at your own risk' software.
very much so more because you can't even do anything with them if ms decides so that you don't deserve it to work anymore. mysql is pretty much easy enough to install for somebody who wants to have alternative to ms-sql server, however sometimes people don't for very questionable reasons even want to look for change(and i'm not saying mysql would be the only best option either, just that most windoze users can even install it, mysql's website does offer very good docs btw, and i thought support is what where the money mentioned comes in? and the point of the article is that it is __not__ a fringe, experimental db anymore, instead it is very widely deployed).
world was created 5 seconds before this post as it is.
Sorry.
The GPL, one of the licenses under which MySQL is distributed, states that if you re-distribute it, you are also required to share the changed source code.
My complaint was that the article was imprecise. If a company changes, but does not re-distribute MySQL, they are under no obligation at all, ethical or legal. If they re-distribute it then they are under a legal obligation to share their changes to anyone who uses it (not just MySQL AB).
J'aime mieux les méchants que les imbéciles, parce qu'ils se reposent. -- Alexandre Dumas
The GPL does not merely give you an ethical obligation to share your modifications with anyone you distribute them to. It gives you a legal obligation. Until shown otherwise by a court, the GPL is legally binding. As such, stating that the (presumably only) obligation that someone modifying the code has in an ethical one furthers the outdated notion that all pieces of Open Source Software are amateur projects that are only held together by people who choose to donate their time for whatever higher reason. Not that there is anything wrong with volunteering your skills, but there are major businesses investing time and money in OSS.
From a business standpoint, OSS is legitimate. It would be nice if CNN reported it that way.
Note: I contacted CNN.com regarding this when they first posted the article. Predictably, I have not yet received a response.
My legal education, in nifty podcast format
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!
Ehttp://eugeneciurana.com | http://ciurana.eu
MySQL is a phenomenal product, in terms of just how much a small to medium size business can accomplish with it, for so little cost.
;)
Having to use a data-storage solution like Oracle is simply unfeasible for anyone but large companies. I've been using MySQL for 3 years to build web applications, and I've never had a crash or corrupted data. The only problems I ever ran into was when one of my systems had a table get to 2GB on the 2.2 kernel, but that wasn't MySQL's fault
With the inclusion of InnoDB, MySQL definitely becomes a threat. The main problems I've run into with MySQL is backing up/restoring without locking up the whole system (table-level locking). InnoDB of course removes this!
I see no reason to use Oracle over MySQL for anything but the largest system. Then again, why even that? Doesn't Slashdot run on InnoDB...?
I moderate "-1, Fool"
you probably won't find too many databases on the 'net that need the kind of performance some commercial brands give. so i wouldn't say the drastic change is coming, unless companies start putting their payroll records for the web to see.
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.
I was thinking of how to intentionally fail my drug test... It would make a good memoir story someday.
Read what you put in bold again. This journalist said that they become ethically obliged- not legally by the GPL. And largely, that is the case. It would be nice if the writer could have said more than just that, but how could it have been said better in one sentence?
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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
GPL Admin tools like TOra 8very good, targeted at Oracle) and some KDE Tools like Kexi will prove that MySQL ist a professional database. However, more important is easy administration. Imagine MYSQL without PHP!
That's hard? Give me a break. MySQL is so internally inconsistent that auto_increment is practically the only atom in the entire data definition syntax that uses the underscore! How about this bit of MySQL genius:
Which is the default: 42, or max(foo) + 1? The statement is internally inconsistent but MySQL allows it anyway. Nevermind the stupidity of requiring a unique index on the auto_increment column.
PostgreSQL has a number of operational problems -- vacuum, toast table indexes, and so forth -- but the SQL syntax is not one of those.
Put a wrapper/installer around MySQL or PostgreSQL that lets you import a SQL Server database dump -- including stored procedures.
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.
Ita erat quando hic adveni.
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.
Uhuh.......... CREATE TABLE foo (bar SERIAL PRIMARY KEY); (PostgreSQL)
CREATE TABLE foo (bar INT AUTO_INCREMENT PRIMARY KEY); (MySQL)
In both of the above tables, the bar column will behave pretty much the same way in each database. Yes, annoyingly difficult compared to MySQL because....... the syntax is different? Maybe if the first db you used was MySQL things seem "harder" because Postgres is a little different, but you'll see differences like that moving between any database.
In any case, even though I use Postgres, and prefer it over MySQL (which I have used extensively before), I am happy that opensource dbs are getting recognition out there.
Even auto incrementing IDs in Postgres are annoyingly difficult compared to MySQL...
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 being more popular than Postgres has a lot to do with mindshare than product quality. Take me, for instance. I set up apache for the first time a month ago, and I wanted a db server for some things. I had heard of both MySQL and Postgres, but I had been bombarded with the words "LAMP" and MySQL guide/tutorial/howto so many times in the past that my first thought was to give MySQL a try. I found it was already installed on my machine, had lots of documentation, and had no learning curve - no complaints at all. So, Postgres didn't even get a fair consideration from me. Of course, you might say that newbies and students like me don't count, but keep in mind that I might become a database admin some day, at t which point I would have a lot more experience with MySQL than Postgres...
MySQL has the power (pretty much) to replace MS-SQL Server.
OMG, you didn't really mean that, did you? Oh, that's so cute...
MySQL is barely ACID compliant, doesn't support triggers or stored procs or views (just for starters), and you say it has the power to replace MSSQL Server?!?!? For goodness sakes, MySQL just NOW has a shared SQL area (query cache). You gotta crawl before you walk, and you gotta walk before you can run with the big boys. MySQL is a very capable database in its own right, but it's still in it's infantcy.
With some of the best replication and datawarehousing functionality on the market and consistently a price/performance leader, I don't think MSSQL Server is going anywhere anytime soon.
MySQL is good for certain applications, where you only read data, and don't write too much data. This works out especially well for most web sites, since they serve information, but doesn't necessarily allow too much information to be posted by the user.
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.
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.
As long as MySQL doesn't conform to all of ACID, it won't be used by serious players. So all those who use Oracle etc. and need a real RDBMs won't even try to switch. There was a lengthy discussion (or should I say ranting) over this in user comments in the online MySQL manual, but it looks like they removed that. Here's the best link I could find: Manual/ACID.
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
I work at a heavy-duty Oracle shop. I would say that Oracle has gone way beyond being just a database vendor, in that they provide a complete--but proprietary--environment. Since I haven't needed to use many of their features in the past, I had never realized how complex their software is.
I can't believe MySQL doesn't even have subselects yet. I've been living on subselects and 'connect by' for years. I never did like PL/SQL all that much, but it does allow you to run complex programs over the network without creating high traffic. And SQLNet does make things a lot easier. The whole thing is kind of like a database flavor of Unix, with its own world of commands, scripting tools and permissions.
As for Oracle's 'fancy' products, like Express, Forms, the OID, Portal, and Workflow, they are serious attempts to extend the database principles into a generalized suite of enterprise-level business tools. They are a little too cutting-edge for my taste, but you won't find anything like this in a non-proprietary product.
Rollback is not an advanced option. It's essensial for any non read-only database. When you have a typical OO or other modular system you often ask a particular function to do something without it being aware of the wider context. Something in that wider context may well decide something is wrong. Without rollback (and commit) life becomes a royal pain in the arse and/or your data becomes rat shit.
Replication is useful for keeping things going 24/7 and allowing intensive off-line reports etc.
Lets not confuse "advanced" or "bloated" features with "features I don't use".
mySQL is, unfortunately, a SQL interface to a bunch of files based on various index sequential access methods. It gets its speed by ignoring transactions, triggers, stored procedures and other things that, when your company is successful, will need in its database. mySQL's replication is also not guaranteed and when its spotty, it doesn't tell you.
The open source DB community is a powerful force with a lot of potential and a lot of success. That success is in markets where transactions are low and/or not critical to the customer.
mySQL and others need to ensure that they have these features:
- stored procedures (implementation outside of the A in ACID aren't complete - perl, java, python, etc)
- Referential integrity, foreign keys, transactions
- hot backups where you don't have to take the database down to get a backup with guaranteed integrity.
- reliable replication (argue away, only shareplex, NT SQL server & Sybase have it today)
- sub selects
- temp tables
- function based indicies
- automatic partitioning
- rollback (true rollback w/transactions)
- triggers
- block and row level locking. A select on
a 50 million row table shouldn't lock
the table.
- joins that do not lock tables due to full table scans
There are a lot of good reasons for using mySQL as a platform to begin the development of a project. For personal use, it's hard to beat! If you are a professional in a company that needs to support real clients with real data with real guarantees, spend your money on a real database.Where do you want to spend your R&D money? On your product or on the database that does most of the things you need, but not all of the things you need. Don't you want to spend your time building the product that pays your salary and makes your customers happy? Why spend time on the database, just buy something that works.
One more thing, a not unreasonable architecture for a database driven application is:
- UI layer
- Business rule/application layer
- Application Programming Interface
- Stored procedures (potentially hundreds)
- Database
Good luck.MySQL is not a threat to the bigwigs, because they compete in different realms. MySQL is a threat to filesystem-storage and BerkeleyDB.
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) 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.
fifth sigma, inc.
Not sure why it hasn't gotten around to PostgreSQL yet that MySQL does support transactions.
I see it as one of the main advantages of MySQL over PostgreSQL is that you are able to turn off transactions if you don't need them.
The main difference between MySQL and PostgreSQL is more 'philosophical'. MySQL does not attempt to hunt Oracle based on features. Instead, the main objective for MySQL is speed. PostgreSQL on the other hand attempts to duplicate as many Oracle features as possible.
BTW: MySQL does support replication well, even in its non-commercial version.
---- join dshield.org Distributed Intrusion Detec
I am frankly surprised that MS SQL Server was ranked along oracle and DB2 as a 'high end' DB. Anyone who has had to work with it usually disagrees!
Personally I have seen SQL server most on small/medium size business environments. Any large 'enterprise' sized business deserves what they get if they are dumb enough to rely MS SQL server. Look what happened to Bank Of Americas ATMS when the last MS virus du jour made its rounds.
I think MySQL is the best bet to reduce Microsofts share of the DB market. Oracle is better, but small business isn't willing to fork out that kind of cash, especially in this economy. MySQL is especially perfect for the small business web site, and with Microsoft irrationally increasing subscribtion fees and forcing upgrades, a good percentage of their customers will be running into the open arms of MySQL/Postgres.
- You can find lots of documents online at oracle, but I guess you didnt care
- Speed, MySQL is speedy, because it doesn't have to do anything
- Again, no refirental integry (OOps, I didn't mean to change that foreign key, now I don't know what it pointed too, my database is corrupt! AAARG!)
- Rollbacks are not fancy stuff, they are essential to a real database
- Hardware levels? Ok, go back to your parents basement
With Oracle you can choose: speed, security.Mysql: Speed. Only.
Mysql is like a dragster, fast but no control.
Next time you want to start karmawhoring, at least pretend that you know what you are talking about.
However we use MySQL, MS SQL Server and Oracle (different solutions/architectures). I don't see the pricing problem with either MS or Oracle. You can get the standard editions for around $1500.
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!
ie. an address book.
And even then, you should be using LDAP.
I know that I'll get yelled at by this crowd, but, without knowing more specifics on your application, I'd recommend PostgreSQL DB, a Visual Basic front end for forms, and perhaps Crystal Reports for reporting.
This will give you a nice blend of tremendous power and ease of use.
This discussion seems to be omitting an entire market segment of database engines. For instance, Advantage is a powerful database server that's priced at less than half the cost of M$ SQL Server, and Oracle. It's not a "free" product, like MySQL. In addition, Advantage isn't limited to SQL, which is nothing more than a limited reporting language, meaning, it's much more flexible to utilize Advantage than either of the products you seem to be comparing. And, No, I don't see MySQL as a threat at all to products such as Advantage.
In addition, MySQL isn't really all it's cracked up to be. Features such as page-level locking, (used by MySQL) and locking escalation (used by M$ SQL) will degrade performance in a multi-user application. So, while MySQL is great for a web-server, developing/deploying an application that uses MySQL can cause undesired performance degradation when multiple users are simultaneously accessing the data.
SQLite claims to be twice as fast as both MySQL and PostgreSQL, and is more SQL92-compliant and ACID-compliant than MySQL.
Does that mean everyone should drop MySQL and PostgreSQL for SQLite? No. It means you have to evaluate your situation and choose the best tool for the job.
Personally, I've have very good luck using PostgreSQL, and probably won't ever consider using MySQL until it is truly ACID-compliant.
A couple years ago I started a large hardware conversion project for a major telco. One of the requirements was a fairly large database to support real time call processing. I had already told the customer that I would only do the job if it was on a non-Microsft platform so I didn't need to worry about them wanting SQL Server. However, since they were a large telco I assumed that they wanted a well know commercial product so I proposed either Oracle or Informix - their preference. Their director of DP said something like "it's too bad we can't use MySQL" since they were using it for some smaller applications, unknown to me. My next comment was "do you want to use MySQL?". The answer was "yes, provided it could do the job". I said "I will make it do the job". Now it's been about two years and MySQL has almost faded into the background. It just runs, unlike my experiences with Oracle and Informix where you have to constantly administer them. That's my personal experience, your mileage may vary depending on your skill and attitude.
I've seen it demonstrated, and tried it myself, although as the MySQL guy pointed out a log of sub-selects can be done with joins.
The next version of mysql will also have views.
/* FUCK - The F-word is here so that you can grep for it */
Firebird (was Borland Interbase)
http://firebirdsql.org
it's had all these abilities for years.
I've had 76GB single-file databases on my FreeBSD machine since last year.
Faster than Postgres on everything but deletes, but it cleans up after itself when postgres just marks pages for deletion during the next sweep.
Same speed as MySQL on insert/update/delete.
Slightly slower on selects, but that's understandable.
After all, it does have:
Stored Procedures and Triggers using the same PL.
Views, cursors, custom datatypes.
Multi-terabyte file handling capacity
Transactional Engine, with full Commit/Rollback.
Full referential integrity
I've had it doing ~300 transactions/sec on my Celery450, so it rocks along nicely.
I've used Mysql, PostgreSQL, SQL Server.
So far, Firebird outstrips them when you weigh all the features and performance.
Sure, you can power huge sites with MySQL, in the same way you can pull a 6-berth caravan with a Daewoo.
Firebird is a 4MB install. Why choose anything else?
BTW. It works a dream with PHP, Perl(DBI), C.
Probably more, but they're the ones I've used personally.
- 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.
We had a DB with about 65GB of data. It is being used 24x7, and we do backups every 12 hours. We have around 200 users all the time over about 85 tables. We use transactions alot, but I can't be certain on the number of ROLLBACK's that are issued. Plus we use the internal postgresql stored programming language.
It is an internal application for an insurance company. We run the server on HPUX, currently on version 7.3.1 of postgresql.
It isn't too hard to find people using postgres for serious work. Just hang out on the mailing lists for a week and you will be able to write a short book on them
I don't know why people insist on comparing MySQL and Oracle. Oracle is huge and bloated, but it runs pretty quick, and is chock full of the sort of features you need if quadruple redundancy and data integrity are a must. If I'm working for a company that can afford the licensing, I'm Oracle all the way...There is no commercial product that really compares.
.0363160 Bulgarian Leva worth
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
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
In my experience, MySQL has been faster at doing select-type operations. I use it for a web-based CMS, where transactions are unimportant, and the majority of database work is grabbing stuff from the DB and displaying it.
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.
What a strange bird is the pelican, his beak can hold more than his belly can.
MySQL does have transaction support and is fully ACID-compliant--iff you use the InnoDB table type. This also allows you to use foreign key constraints. However, it's not as fast as MyISAM and doesn't support certain features (e.g. fulltext indexing).
In my (informal) tests MySQL/InnoDB is less than half the speed of MySQL/MyISAM but still about 50% faster than PostgreSQL for simple and small tasks. That said, PostgreSQL has more features than MySQL and I still prefer it for most tasks.
Gates' Law: Every 18 months, the speed of software halves.
no mention of PostgreSQL or mSQL,
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.
features that MySQL (and other open source DB's) just don't have, and probably won't have for Years.
SAP DB is free, open source and GPL. It also has all the best big-guy features. Not many people seem to know about it - it certainly has small mind-share. But it is the real stuff - miles ahead of MySQL.
that have received little comment so far:
* Firebird (ne: Borland Interbase)
* SAP-DB (ne: Adabas-D)
Both are good, high quality, commercial or formally commercial products released under an open source license. (interbase public license and GPL respectively)
Further, SAP-DB has excellent commerical support available from SAP, the company, at or better than the same level of responsiveness as, say, Oracle support.
Both are fantastic, enterprise level full ACID RDBMS's with all the great management features a heavy duty shop could want:
* online backups,
* transaction logs,
* restore to point in time
* subselects, views, rules/triggers, procedures, etc.
* great storage management
Check 'em out.
-- Pat
The biggest problem with communication is the illusion that it has occurred
Actually, multi-valued/post-relational databases have been doing this for many years now. Such database vendors are Pick Systems and IBM uniVerse (formerally Informix/VMark).
These databases are extremely fast, loosely typed, support many different table types, support SQL, support multi-valued (columns within columns) versions of SQL, fully ACID, have APIs written for every major language out there. All of these databases usually support two procedural languages underneath which are native to the database. One is called Access/TCL (Terminal Control Language). The other language is ordinarily a flavor of BASIC. The former language is extremely terse, much like RPG. While the latter is much more like writing a GW-BASIC program.
These databases have been around for decades now. They are running in huge environments, processing terabytes of information, have been tested and re-tested, and have been stable for decades.
Check them out if you are interested.
See the other poster's comment about this being like MS's registry. It is not. Any problems with the Windows registry is an issue with implementation, not the concept in general. There is an equivalent to the registry available for Linux, used by some GNOME apps. Not sure how many actually use it (%) or what it is called at the moment.
Nonetheless, the kind of system-wide database is not the same thing as the MS registry, although the MS registry is a good idea, although (very?) poorly implemented. I'd much prefer it to having flat files that are in scores of different formats. There is no reason you could not edit this registry from the command line using a small utility just like you could edit flat files.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I am a web developer and in the last few years I have written products that use SQL Server 6.5, 7, 2000 and Oracle 7.x and 8.x. MySQL has always been present whenever we discussed data back ends and was always dismissed as "not good enough." Usually because it did not cost a gazillion.
During the last 18 months or so I have run my personal sites with a MySQL back end. I have never had an outage or loss of data that can be traced back to the MySQL servers. I ran it first on Windows 2000, later on freeBSD4.5 and now on a freeBSD4.6 jail. It still works perfectly.
Back when we were still arguing (two jobs ago) about using MySQL, the DBAs usually claimed that you could not trust MySQL because of the lack of stored procedures and the fact that it could not pass an ACID test. Since then I never bothered learning the DB system itself beyond the minimum needed for SELECT/INSERT/UPDATE/DELETE operations, I did not try to verify this on my own. Years later and I am convinced that these DBAs probably read that in a magazine, and that none of them had even seen MySQL running.
After the dot-bomb nightmare nobody in his right mind should be proposing to their managers to spend obscene amounts of money in SQL Server and Oracle licenses just to do simple SELECT/INSERT/UPDATE/DELETE operations. Sure, stored procedures rock but it does not make any sense to spend that much money just for the 1% of your functionality that will be run by stored procedures!
Most of the people I know that use SQL Server don't even know how to write one, and in the last 5 years I have only written two web applications that have more than 1% of their sql operations as stored procedures. And for Oracle it is even worse!
Pedro
----
The Insomniac Coder
With MySQL you have to lock tables before a backup. But that is hardly a showstopper for most applications. Once they are locked (and something else... check out mysqlhotcopy) the data files can be copied right out from under the database server. Takes a second, maybe? I can't think of any system I use that would be hurt by such a delay. Financial? Heh. When did any financial transaction take less than 5 or so seconds, anyway? ATM, online, etc... Plus you could consider MySQL's query log a backup. Heck, just run them on another database all the time, or mirror the main db... tons of options, here. The other thing that keeps coming up on this board is integrity contraints and checks. There *are* such things as dynamic contraints, or contraints entailed by the application, not by the database. Anything the database can do in this way, the app can do as well. And since you generally have to inform a user of any problems of this sort... why not just put it in the app?
I agree 100%, I think a huge amount of MySQL catching on has to do with the online docs which are great. Most people getting into mysql are new to databases, and having all that info super-handy in a great structured format is very very handy, yup. I would have never got into mysql without it either, because for years there were no books on it.
sig:
See the "..for smart people" banners Wired runs here? Look elsewhere guys.
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.
I disagree with the idea that small projects should use flat files or XML in place of MySQL. First of all, the flat file only looks good while there seems to be a single entity in the system - let's say person. It rapidly turns into a convoluted mess when a second entity rears it's head - let's say a person can have multiple cars. Second, many applications end up developing reporting requirements that were not envisioned in the original design. That's what makes relational databses great - ad hoc reporting.
Another way to put it - as the application grows in complexity, more functionality will be added to the data store as the programmers painfully rediscover all the challenges which real databases have already conquered. Of course MySQL doesn't cover all of those, like ACID, but it covers most. Look at the amount of effort that went into MySQL, Postgres and Oracle - it's huge.
Of course, you may be thinking of simpler applications than I am. If the data can legitimately be represented by one table, with no denormalization, then I agree a database may be overkill.
It would be nice to see MySql get up and take the big boys on (Oracle, DB2) but I don't think it is quite ready for that.
Speaking from an Oracle point of view, as I haven't worked with DB2, it just has too much going for it atm. For example the ability to do
create table2 as
select *
from table1;
Hey Presto you have an exact copying of table one(constraints and all). If you add a few more characters (not commands just characters) you can move it to different tablespaces, schemas and even whole databases on completely different machines. With oracle 9i you can move whole data files, turn on and off tablespace enlarge and reduce tablespaces all on the fly while the db is running. You can't imagine how much time this and 100's of other nifty features saves,
I am not knocking MySql, I think for websites like slashdot where speed/uptime seem to be the main factor and not table complexity/integrity/constraints it does great (how many times has slashdot been slashdotted?). However, having used MySql I don't think it is up the job of replacing a database like oracle.
On the other hand a couple of years go Linux was not ready to take on solaris, AIX etal... and now look at it? I suppose you never know what will happen!
It said "windows 98 or better" so I installed Linux
Great discussions on this thread! We are reading them carefully to learn what we can do better.
Let me just comment on the overall impact of having such articles appear on Fortune.com and CNN.com:
The article is indeed the result of PR work done by MySQL AB, but the value of it will benefit the entire free software / open source community. We need to get many more business articles out there, so let's be happy about this one, and let's produce more of them!
Although this very article mentions MySQL only, please have a look at other articles where we at MySQL AB consistently mention the other open source databases. Here are two such articles on prominent business-focused sites (one of which, incidentally, is powered by MySQL):
= A2 44_0_1_0_C
http://www.open-mag.com/01943583279.htm
http://www.alwayson-network.com/comments.php?id
Our ambition is not to be a threat to bigwigs per se, but to make superior database software available AND affordable to all. With your help we can do it.
Marten Mickos
CEO, MySQL AB
Well, its all very well to claim speed, but its not always true. Yes, MyIASM is (generally) quicker than postgres.. The problem is that innodb is really slow.
For example, imagine that I have a bugs database (which I do; its called Bugzilla). I want to find all bugs where I'm either the reporter, or I've commented. Since bugs can have zero comments, I need to outer join the busg table to the accounts table. With randomly generated data, and 100,000 bugs, 1,000,000 comments randomly distributed among the comments:
select distinct bugs.bug_id FROM bugs LEFT JOIN longdescs USING(bug_id) WHERE (bugs.assigned_to=86 OR longdescs.who=86);
mysql: 3.33 sec
postgres: 14423.07 msec [I can get this down to 11758.74 msec by changing a
config option - I should probably file a bug on that]
(returning 46 rows)
But the thing is that I just want bug numbers. I don't care how many times I've commented, or need to know the contents of the comments. What I really wanted to ask was:
> SELECT bugs.bug_id FROM bugs WHERE bugs.assigned_to=86 OR bugs.bug_id
IN (SELECT bug_id FROM longdescs WHERE longdescs.who=86)
mysql: error
postgres: 137.66 msec
(To be fair, this does need CVS-postgres to be fast. It is, however, possible to create a UNION join to make it much faster, arround 6ms. Thats not appropriate for the generated SQL bugzilla uses, and having the db do the transformation from teh LEFT JOIN requires knowleges of the distinctiveness of bugs.bug_id, and the distinct in the original query, so its not trivial)
Oh, and it took almost 2 minutes with innodb. I will admit to not having tuned the various innodb parameters, plus this was 3.23, so I'm sort of ignoring that.
Queries are often slower, too - as far as I can see, mysql doesn't produce a query tree, but rather a list. If you only have one table, then this doesn't matter, but if you start doing complex joins (and without subselects, you do that more often than you may want to) then it does make a difference. Yes, I know that mysql has subselects in the development version. I'd be interested to see if they have the same speed problems as in postgresql I see it as one of the main advantages of MySQL over PostgreSQL is that you are able to turn off transactions if you don't need them.
You always need transactions. If you think that you don't, then its obviously not important to you if your data gets lost. (You also want foreign keys and constraints, but....) And whilst I don't know too many 'bigwigs', I'm pretty certain that most of them want half of their commited data to not vanish if there's a power failure.
Now, I'm certainly not saying that postgres is always better than mysql, and I'm sure that people can come up with similar examples to the above, but where postgres sucks and mysql blows it away.
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.
The following is my personal opinion based on experience with MySQL 3.x, PgSQL 7.x and MS SQL 6.x-2000. YMMV.
... IN () and EXISTS. The difference is orders of magnitude.
-- MySQL
MySQL's #1 feature is exceptionally simple use and administration. #2 is excellent read performance. If you are building a web site with a simple DB backend, a lot of reads, a few updates/deletes, no transactions, then MySQL is ideal. It may have an infrequent index corruption problem. A couple of versions had a problem of eating all CPU on occasion. But most of the time it just runs. Very easy to learn, nearly 0 maintanence.
The problems start when the database grows in size and complexity. DISTINCT sucks: if a query is large enough distinct just does not work. UPDATE/DELETE don't work with joins. No transactions. Yes, yes, I know, some things are addressed with another table format, some are patched up in 4.0. But it's done at the cost of what I listed above as #1 and #2.
-- PgSQL
PgSQL is the #1 OS ACID-compliant DBMS. It has transactions out of the box. It works. It can be tuned to run as fast as MySQL. But the learning curve is steeper both for programmers and for DB admins. The first thing to learn is VACUUM ANALYSE. If the table has a lot of updates/deletes, do it often, otherwise performance would suck. And I mean really suck. When the the V/A is running, the table is pretty much unaccessible. Pg's aggregates are bizzare. MIN() and MAX() can be programmed around, but if you need COUNT() you are out of luck. Flat out can't use it on large tables because aggregates do not use indexes! Another surprize is difference in performance between queries WHERE
Pg's query planner/optimizer is not too smart. It can be easily confused with variable types. It often chooses wrong indexes. It's about the same quality as the p/o in MS SQL 6.5. Be prepared to spend time tweaking the queries and indexes. On the other hand, the memory cache is too smart. You can't make it read the whole DB into RAM and keep it there. Pg is trying to behave nicely and releases RAM when the table is not used for a while. Which is a bad thing on a dedicated server.
Hopefully, the next release will have failover and replication. And maybe aggregates will be eventually fixed. Then PgSQL can be seriously considered for enterprise-scale projects.
-- MS SQL
Microsoft went a long way from MSSQL 6.5 to 2000. 7.0 and 2000 are pretty much the same. If it were an OS project, 2000 would have been called 7.1 or 7.2. The MSSQL 2000 is a pretty solid product. For an all-Windows shop it works. But the price! The MS SQL server license, The NT Server license, a license for each connection. If you need to access it from a FreeBSD or Linux box, then FreeTDS is needed. FreeTDS has its own issues. MS SQL has a problem with scalability because it's tied up to NT and NT is not available (yet) on massive hardware.
In conclusion I would say that MySQL is certainly no threat to big boys, not now, not in the near future. PgSQL may become a real contender in the next two years. It is already eating into the lower end of the MS SQL market. Unless MS ports the SQL Server to other platforms, it's going to be sqeezed really hard.
MySQL is great for lot's of tasks, but adding subselects and transactions isn't the issue. Postgres has Loads more features than MySQL, yet it isn't really replacing Oracle in the enterprise. Why?
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?
ERROR 1064: You have an error in your SQL syntax near 'People Web != Enterprise and $Web $Enterprise' at line 1
Game... blouses.