Slashdot Mirror
MySQL A Threat To The Big Database Vendors?
geekinexile writes: "Bloomberg is running a story on the growth of MySQL as an alternative to the big commercial database systems." The story mentions PostgreSQL as well, and presents a generally positive view of both.
Linux + Apache + MySQL + PHP
It's the ultimate Free Software combo... and it powers StumbleUpon just fine, thank you!
augment your senses: http://sensebridge.net/
sourceforge just bailed on opensource databases and ill bet ya all bloomberg's money that story came out of an oracle or sql server db.
mysql/postgres have their place, but oracle is not running scared just yet.
four-oh-four
How can a challenge occure when the market for MYSQL is in the range of "Free" and the market for IBM, et al, is in the 6-figure range? Do they think I'm going to be able to afford something from the big DB vendors? Do I think the DB vendors will ever be able to offer the personal user anything?
This seems like a bunch of nothing. There's no challenge because the two markets are completely different.
PostgreSQL is a serious competitor, but MySQL is not. Everytime someone slobbers off about how MySQL is the greatest thing since sliced bread, what they really are doing is yelling "I AM IGNORANT! I AM A FOLLOWER!". I'm not kidding. The basic database functionality missing from MySQL (though always "coming soon") absolutely KILL it in any credible comparison.
This is a dumb article, because what they're really saying is "These morons could have gotten by with Windows 95 and the ODBC dBase IV driver as their, err, relational database driver, so they used that instead of Oracle".
1.4.3.1 Using the MySQL Software Under a Commercial License
(snip)
When you link a program with code from the MySQL software or from GPL
released clients and don't want the resulting product to be GPL, maybe because
you want to build a commercial product or keep the added non-GPL code closed
source for other reasons. When purchasing commercial licenses, you are not
using the MySQL software under GPL even though it's the same code.
-----
This means you can't use libmysql in your closed source code.
If you have a need for the scalability, reliability, high-availability in Oracle (or similar), then MySQL isn't even a consideration.
Maybe someday. But not today.
---
Information wants...you to shut your pie hole.
I'm sorry. I can't take any article that uses "pooh pooh" as a verb seriously. Masterful use of the english language. The spacing error is theirs too. Nice touch.
Now, big DB companies are not going anywhere soon. It will be nice to see them sweat.
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
``We've spoken with other agencies about our open-source projects,'' she said. ``People first get interested after hearing about the budget savings.''
MapStats hasn't crashed since it was created, she said.
not bad for a low end peace of fluff.
"It is a greater offense to steal men's labor, than their clothes"
"MySQL: The Communist Threat."
--Rick "If it isn't broken, take it apart and find out why."
As the report says, it will take couple of more years before the database vendors will be fearful of MySQL or PostgreSQL.
MySQL, in particular, is missing quite a bit of essential functionality like views and stored procedures that - this is the key - makes it more difficult for other applications to use it as one of the data sources. A lot of enterprise products supports one or more of these expensive databases, and unless those enterprise software are changed to use PostgreSQL or MySQL as the database for it, the big db companies will still have years of guaranteed revenue.
They may be able to take away some of the lower end market, but until the time when likes of SAP and OpenText supports MySQL and PostgreSQL as well as Oracle and DB2, I don't think the db companies will seriously be challenged.
now if only MySQL would finish adding subquery support, I'd be a happy man.
I love MySQL, love the speed, the accessibility, the ease of deployment and its suitability for small and medium-sized projects. I'm an advocate.
... Nope. ASP and SQL Server. I cried my way to the bank.
...
But -- it can be a tough sell to the big fish.
I was hired by a Fortune 500 financial services and real estate company to do an internal project that really was not challenging development. Essentially, the requirements boiled down to a very hobbled version of Slashcode. I bid the project at X dollars, spec-ing PHP and MySQL, figuring that I was going a bit high for the actual hours involved and that I would make a nice roll of dough if they accepted. But I still knew that given the sheer size of the company, that my bid would be considered a bargain, if not a lowball.
What threw it? MySQL and PHP. What are they? (WHAT ARE THEY?!?!?!) Well, we're going to have to get through Standards and Compliance, issue an exception, and well, we'll see, we just don't know. Okay, said I, I'll do it for four times the cost and implement it entirely from scratch using ASP and SQL Server.
Great! Sold. Damn. And you have to understand I really TRIED. I wrote two papers, directed them to a bunch of links
I believe inroads will continue to be made for open source. I have faith. But I think there's still some time and a lot of tireless advocacy to come
MySQL is simply not ready to even play in the same ball park with a serious DBMS. I have used the Linux + Apache + PHP + MySQL thing. Sure it is easy to use, and is nice for little db driven sites. But MySQL lacks the huge set of features that make up a modern relational database.
Like the guy said above, nothing to see here move on.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
This story is about as interesting as watching Outlook Express download the latest worm through an oldskool 300bps modem. I'ma go browse ThinkGeek's overpriced shit or something...
This motherfucker is BORING to the tenth power today. Stupid Slashdot, be more entertaining!
A few months ago, ESR gave a talk at the local computing department and told us that Big Unix died because it was closed source. When asked how he explained Microsoft's 20 years of success, he replied "Really good advertising?".
The same explains why MySQL is popular -- if you have good enough advertising, it doesn't matter what sort of crap you put out or how many better alternatives there are.
Tarsnap: Online backups for the truly paranoid
Now I know everyone's going to jump down my throat with "Hey, that's going to be in 4.x.y" blah blah... these things have been in use since the stone ages, too little too late and the support still isn't on par with Sybase, MsSQL, Oracle, etc..
scott
We tested porting our company's software to Linux and MySQL.... we kept the Linux port but we couldn't use MySQL because our application does a lot of reading and writing, and from what I understand vanilla MySQL does not support transactions but instead locks the entire table. I think there are some mods to MySQL that support transactions but without it fully supporting transactions I just don't think that major companies will ever move to it. It is perfect for Web sites where the ratio between reading and writing is heavily skewed towards reading, but for applications that need to do both, I don't think MySQL is an option... yet. Some people in the company, however, swear by MySQL and say it is heads-and-tails faster than all the "enterprise" dbs like Oracle. Certainly it is not a resource hog like Oracle.
I personally would like to see 3 kinds of database engines that allow one to scale the gammut with little or no application rewrites along the way to fit the different syntax and conventions.
1. Small, lite-duty engine mostly for embedded or small-footprint apps. Subset of lanugage of #2.
2. Full language, but lacking performance tuning. Mostly for development and smaller shops.
3. "Big-iron" version that has full language and performance tuning features.
I realize that one can use Postgre if they out-grow mySQL, but it is a different language and conventions. You have to rewrite some of your application software.
I am afraid that as mySQL becomes more popular, it will become a "feature beast". I would rather see a split between #2 and #3 rather then live with a feature beast.
Table-ized A.I.
Just in case anyone else is reading: the section he quotes actually means that mysql is available under two licenses.
You can use it under the GPL for free.
If you want to incorporate Mysql into your closed source product, you can get a non-gpl license to incorporate that source by paying them money for a license. This is how mysql ab makes money.
So in short, you can incorporate mysql in a closed-source product, just not for free. It is the best of both worlds, all the advantages of GPL and MS's "shared source", with none of the disadvantages of either.
The dirty secret of big databases is that most people don't know how to program them, how to configure them, and don't need most of the features. And even if they get everything right, they still end up with a very costly and complex solution, a solution that likely doesn't perform very well and needs a special DBA to keep it all running. That's why MySQL is successful.
They are two different products with two different uses.
MySql came along and took away the appeal of using text files as data stores for web applications and such - it gave perl scripters a simple, easy-to-understand database that works pretty darn well.
MySQL is a great product, but only for the things it does well. If you try to make it do things that it can't, of course you're gonna get burned.
If you actually *like* databases, you'll probably like PostGres better anyway - don't bother with MySql.
MySql has found its niche. Linux, Apache, Perl/PHP and MySQL are powering thousands of websites right now. I have a few myself and they work well - There is absolutely no need for me to change the database - it just works.
I wouldn't want American Express to start using it today though - they actually *need* the features that Oracle offers.
Not all databases need the kind of bomb-proofing that you can do with Oracle - some applications just need to be able to pull data quickly from simple tables.
The thing that I don't understand though, is why MySql has so much more popular appeal than PostGres - It seemed that one day, everybody just seemed to be using it. Why was that?
Cheers,
Jim
-- My Weblog.
...most people don't need Oracle.
Oracle has been used for a lot of projects where it doesn't really need to be used, usually because the company already had a licence, but sometimes because the project was way over-spec'd.
Don't get me wrong, MySQL doesn't even come close to challenging the benefits of Oracle or DB2 in replication, scalability and so on. However, in applications where you don't need them, MySQL is perfect, especially because it requires no monetary investment. (It requires other kinds of investment, of course, but everything does.)
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
As long as you don't need some of the more advanced features, MySQL is a very good choice. It is fast and there are both Linux and Windows versions.
This means that you can write applications in a RAD language like Borland's Kylix and easily port it to Windows using Delphi.
If you need more advanced features then use Postgres. But as far as I know there is no Windows version so your market is smaller.
I think these companies are in denial when they say that they're not even a little worried that an Open Source product can cut deeply into their market share.
The race isn't always to the swift... but that's the way to bet!
I work for Conectiva (Brazil), involved in a project where a minor telecom company is replacing most of their Ora*le databases to PostgreSQL. Mostly due to cost reduction (should be for a more noble cause, but...)
Note, this is the first step of a big project involving migration to free plataforms everywhere it is possible inside the company.
IMHO it's a good idea, but they must keep in mind that there already are some limitations that I'm sure it'll be solved ASAP. Of course that a little of investment in the FreeSoftware/OpenSource comunity will help a lot too, but this is subject for another project ;o)
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
The best part is that mysql is integrated well with other free technologies like php and perl, which have been gaining a lot of acceptance. So when you turn to an open-source web solution you're freed from the need (hey, that-- oh you know) to run expensive oracle or sybase (or DB2, I guess I should be fair) RDBMSes. This is especially easy because websites tend to be redundant these days, so they're pretty robust by default.
Anyway, the plan is to add stored procedures and triggers in mysql 5.0. It already does replication, which one expects to improve. It's one-way now. Once these things happen, mysql will just need to undergo some serious testing and possibly some serious bugfixing to ensure stability even under really terrible conditions, and maybe provide a better management GUI, and bango! The big guys will be running scared. At that point, mysql will be able to take over all but the largest installations.
So go mysql! We're counting on you. Oracle costs too much.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It's sad how all criticisms of MySQL on slashdot are consistently modded down. Although MySQL is a fine product with a lot going for it - there is plenty to be *legitimately* critical about.
Is it that the MySQL supporters on slashdot are only familar with application programming interfaces to relational databases - and so don't understand the differences between a modern relational database and MySQL? Or are they simply pushing the product that they are most familiar with?
I've been involved in purchases of millions of dollars in relational database software over the last sixteen years; been a DBA on Oracle, Informix, and DB2; and developed on those as well as Sybase, SQL Server, Adabas (SAP-DB), Dbase IV, and Access. And I can say that there are plenty of traditional IT applications that I would try Postgresql out on - just about everything in the OLTP arena that doesn't require massive scalability. And unfortunately, there are far fewer traditional IT database applications that I would recommend MySQL for - it simply lacks too many features that are already available in postgresql, and that in the RealWorld(tm) save your bacon.
Ok, you can mod me down now.
and sourceforge badly needs money. fill in the blanks.
You need to pick a database that suits your needs. For some people MySQL is all that they will ever need. For others, referential integrity, transactions, stored procedures and triggers are a requirement not an option.
I've seen instances where an app was done in Oracle when it should've been done in something like FoxPro v2.6 for DOS, and I've seen apps done in M$ Access97 that should've been done in PostGres/Oracle/Sybase/SQL Server.
Each has its place and should be chosen to fit a business model. Picking a database just because it has the most features is not always the correct solution. Picking a database because it has the least initial cost is also not always the correct solution.
Sure, MySQL is simple. Sure it doesn't do everything Oracle can do. But there are a huge number of small businesses, Churches, scools, etc which don't have huge budgets, have to work with a very limited IT department (In some cases volunteer labor) and need some sort of database capability. Used to be DBase III (And I've seen some HUGE apps implemented in DBASE.) MySQL provides the right combination of features, stability and price to compete really well in that arena.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Next in Slashdot:
Linux: A Threat To The Big Operating Systems Vendors ?
and
Apache: A Threat to Commercial HTTP servers ?
I wish TPC www.tpc.org would do some MySQL tests and show just how it really perfoms when compared, to DB2, Oracle, and MS SQL Server.
.NET crap is doing this. Imagine XML results sets with heirachy. Tree based joins may also be in the works with this kind of power.
Why can we not put an end to this debate. I wish slashdot would just refuse to repost this crap that people keep saying to see their words be pubilshed.
It is simple, MySQL is a simple db system well suited to web-sites and application where it doesn't really fucking matter. Suppose if slashdot lost a couple of days worth of stories. Is the world going to end, NO, people will be, well whatever that feeling is when you loose data, but life will go on.
If I lost 5 minutes worth of production data, I'd probably have to find another job. People would not get their orders, we might loose a client. If I worked for the NASDAQ, it might mean real $ figures.
People who work in these high stress database positions understand the debate, and probably won't even post anything beause they are tired of it. I know I am. Learn Oracle, or SQL Server and MySQL postgres and then post your ideas, just don't learn MySQL.
Now that is not to say there is no hope for open systems, I sure hope there is because Oracle is expensive, and I hate most big companies. There is a large list of things that Postgres and MySQL have to do. Here are the big ones.
Log based transactions.
Whenever something happens to the data, the change is stored in another file, along with the data file. This way transactions can be rolled back or restored from transaction log backups without a need to restore the whole database. Get a copy of the datbase backup from a certain time and restore every transaction log backup after that and your back to your last transaction log backup. It also helps to replicate a database, and makes true "live" backups possible while a system is live without a huge performance impact, because the transaction log is also backed up, but at the last second, so when you restore the db, you also restore that log backup that was made at the last second while the database was locked.
One data file for multiple tables.
Having a seperate file for each table is like using dbase or paradox. Hell even Access has one file folks. It is needed for mysql and postgres to manage their own "file system within a file".
I think Postgres is going to do this soon according to some of the discussions.
Complete SQL-92 support.
for all the bitching we do about not supporting standards, MySQL seems to think it is all right to say, "oh they'll make it slower". Give me a break.
Locking, Locking, Locking.
This is imperitive for true transaction support. It is also complicated, deadlocks are no fun. But we must be able to do db, table, row, and key locking. This way you can lock down a row for editing, and not allow anything else to mess with it until your current transaction is done. The classic example is the checking to saving account transfer by two people at the same. MySQL and postgres are not as good of Multiuser system as the big boys. Right now postges sends a message to the application saying, this is locked retry transaction, this is just not up to real enterprise levels.
XML support.
This is a new one, but one that is going to rock the DB world. The crappy thing about current tech is that all record sets are 2 dimensional. But if you've ever done more than 3 or 4 one to many joins this can be a big bitch to scroll through. It also replicates data in the result set leading to more memory consumption, network bandwith, etc. MS SQL as part of the whole
Stop saying we will take over Oracle, and take the steps needed to make it a reality.
I've just recently gotten into Oracle out of necessity. It is very very reminiscent of my Novell days.
They are too focused on their appserver and various "microsoft replacement" apps. Documentation is awkward when it exists, and even the smallest things result in a support call to find out about a bug or workaround. It takes even the resident guru days to do what would take a morning for me on a BSD/Apache/PHP box.
The point? It's not that "Oracle is crap". That's clearly not the case. They're just so busy making the database do *everything* that they're going to look up and find out that people are using open source databases instead of Oracle. By then it may be too late. It won't happen overnight....remember that there are plenty of Novell boxes still humming.
It's Oracle's arrogance about the up-and-coming databases that make it a statistical goliath.
The brief history of software is littered with companies that were once of the same mentality as Oracle. They need to stop trying to be the end-all software co. and write some documentation.
This is simply the sound of the database market evolving -- a testament to the viability of using MySQL and PostGres for a growing number of database projects. Why should anyone pay thousands of dollars for a database back-end to something like a messageboard?
But for more complex projects, like those that use geospatial or geodetic information, something like Informix's Datablades or other proprietary API's will make the difference. The competition from freebie databases will just feed this kind of innovation. The market is still there for Oracle/IBM/M$, as long as they can stay ahead of the curve.
I've been using it for quite some time, and I love it since it's nice and easy to use and very fast.
But if you think that it will replace a company like Oracle, you're way off. MySQL is cool, but it can't handle nearly what Oracle or even DB2 can.
Those bigger DB's run the biggest stuff for a reason. There's no way that MySQL (as it is today) could handle the loads that they do. It may happen in the future, but that's a ways off. There is no current threat at all to the big guys.
Sure not everyone that uses the bigger DB's needs their full potential, so some could switch to MySQL. But the biggest databases will stay with the commercial vendors.
But the GPL license isn't a problem, since you can buy commercial licenses for MySQL so that it can be distributed with non-free software. So that's a non-issue.
This is left as an exercise for the reader.
I've been using mysql for four years, and I've recently began migrating to Postgresql. I've found Posgtgresql to have all of the features that I've wished MySql had, and they don't feel "tacked on" like InnoDB and Berkeley DB support do in MySql. I would highly reccomend Postgresql over MySql for any serious application due to its native support for transactions and sub-selects. It also has wonderful features like views and stored procedures that are still in the planning phase for MySql.
Seeing as how both are free, the only winning factor for MySql at this point seems to be speed. If you're planning on using a system that doesn't have to deal with the possibility of simultanous writes to a particular table then MySql probably makes more since due to it's superiour speed; however, if you're handling a high number of concurrent writes then Postgresql is the way to go due to it's improved reliability and ACID compliance. MySql only supports table-level locking by default, which seems silly for any application where a lot of inserts are happening at the same time. I know that there are 3rd party libraries which provide a solution for this, but I'd rather use a database where these features have been planned for from the beginning.
MySql is catching up in the areas in which it's lacking, but it's still going to be a bit longer before it has a comparable feature set to some of the more industrial strength databases. On the upside, I'm glad to see free software solutions in the database market making their mark because the acceptance of these technologies will only further Linux's success in the long run.
A musician without the RIAA, is like a fish without a bicycle.
MySQL Max binaries support InnoDB, which uses row-level locking. It can also be compiled from source with InnoDB.
/. uses InnoDB.
Also, IIRC,
Simon
A free program doing certain tasks better than high priced commericial programs? This should be illegal here in the USA, don't be surprised to see corporate execs begging Congress to ban this kind of thing!
C:\>
Does anyone know why Sourceforge feels the MySQL was not enough?
Whether MySQL or Postgres, I don't care as long as open source ends up being a platform for databases. Microsoft can try to portray Linux as a niche webserver platform now, but with a solid foothold as a database platform, open software, as a platform, will be substantially harder to dislodge.
--LinuxParanoid
Okay, I just have a real simple question:
Let's say that Database package A is made by a huge corp and package B is like MySQL, free, open source, etc.. Now, let's say that functionally they're similar and that any given company could use one or the other without aching too much.
If there is a bug in package A, the corp would have monetary incentive + engineers to fix it. (This is hypothetical, so spare me real world scenarios...) If there's a bug in package B, what exactly is the incentive to get it fixed in a timely manner?
Just to be clear, I am not criticizing free software. I'm genuinely curious because I'm not fully educated on the topic.
This is an important question because larger companies are willing to pay the money for the 'package A' scenario, but only because they have a sense that spending th1e money put into it means problems are quickly correctable. (I know, reality is a different story, don't beat me up for that point.) With package B, if something's missing, they don't have much alternative other than to go ahead and use package A. Package B is free, but if they already adopted it there's time/money/effort already invested. This could prove embarrasing. It seems like it'd be hard for a company with enough money to buy and support package A would ever be interested in package B. So how does one go about convincing them?
I'd really like to understand that aspect of Open Source before I recommend MySQL or something like that to my boss.
"Derp de derp."
If you want something more on par with Oracle, then try SAP DB ( distributed under GPL or LPGL ):
/ /www.sapdb.org/sap_db_documentation.htm
http://www.sapdb.org/
It has a lot of the features that MySQL lacks:
http://www.sapdb.org/sap_db_features.htm
http:
Ever tried JDBC with PostgeSQL? If you haven't but are planning to, then you'll have some or lots of troubles depending on what features of JDBC 2.0 you use ( specially with LOBs and no performance benefit with BatchUpdates ):
http://lab.applinet.nl/postgresql-jdbc/
What about clusters with distributed data? No shared storage. What software does this?
That *is* a key problem in open source. The project developers develop features around their own key interests first. One could fairly argue that you ought to just code the features in question that you feel are missing from the product, but that's hardly a possibility for most of us because of the time and skill needed to modify something as complex as a RDBMS like MySQL.
That said, you really don't need to sell your boss on what a given open source will be. You only need to concentrate on what's there right now and the ROI tradeoffs involved in procuring such a product over the traditionally favored commercial product (be it Oracle, SQL Server, whatever). At the end of the process, you may find yourself choosing the commercial product anyway. It happens.
As the article said, not everyone needs aircraft carriers. Most of us get by just fine with a frigate. Choose the right tools for your environment. Like it or not, those factors may include political factors which force you to steer clear of open source.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
...for the applications that don't require those things.
(Why drive a truck when a bicycle would do?)
Oracle is great, don't get me wrong, but I have seen applications spec'd with Oracle maany times when the developers weren't using those things at all. Very often, this is being done with your tax money too.
Too many people think that a kickass databse is somehow going to make their crappy schema into a good one.
Of course, the whole key is to start with a good design and know the limits of your tools. If you do that, both MySql and Oracle can happily co-exist.
Cheers,
Jim
-- My Weblog.
I have to agree with this, there are certainly many applications that require the name, stability, and configurability of one of the big providers. However, I have noticed a pretty distrubing trend, distrubing to me as a software analyst anyway, the firm I work with purchases loans as an investment, it buys a few hundered loans a year. They originally used a spreadsheet to track payments, balances, and other info about the loans. As this became unmanagable, it was decided that a database would be needed, they bought a new system and put oracle on it. By the time hardware, software, and the consultants were paid, the bill was quite large, all to track about 1500 loans! Say what you will about Access, but this was about the perfect application for it. MySQL or PostgreSQL would have worked, but no one there knew how to manage it. There are people who could be taught how to create and manage access, especially for something this small.
I also am beginning to believe that these sorts of applications of enterprise databases, for something like this, I would guess that most managmets would be quite receptive to a no liceses cost alterative to Oracle. This is starting to give me the hebejebes about investing in enterprise database companies.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
Yeah, this is another instance of the "nobody ever got fired for buying IBM" problem. There are some interesting books out there that helped this crazy market make sense. The "Crossing the Chasm" books by Geoffrey Moore explain that there really is some reason why Oracle still exists -- and it has nothing to do with technology. Even if you're an interested bystander, this might be an interesting read, but if you're involved in a technology product company, you've got to read it!
____DevManager_____
agreed, you one dumb fuk if you think athlons are unstable
It's important that MySQL and other similar open source is free of charge, as it reduces the price of web hosting, as you can get a server for a good cost and everything that runs on top of it is now open sourced. Dramatically bringing down the price of smaller upstarts to host on the web.
Well, they'd all have OD'd on the crack, so we clean the streets.
If it were would VA Software be switching to DB2?
Personally I like Postgres but hey if the Bastion of Open Source won't even it's it's own food.
Of course this is all just my opinion.
Addressing the typical slashdot negativity when MySQL is mentioned...
MySQL, w/ InnoDB tables (binaried as MySQL-Max) supports transactions with row-level locking and multi-versioning. It also supports foreign key constraints to some degree (on delete cascade, IIRC).
MySQL w/ InnoDB is extremely fast, and this isn't just on SELECTs. UPDATE/INSERTs are much faster than in MyISAM tables. Looking back, the turning point where MySQL went from a good database to a great database is when it picked up InnoDB, IMO.
No, MySQL does not yet support stored procedures, subselects, or views. These are coming in 4.1, along with built-in hot backup support. Plus better replication. 4.0 is available now and seemingly stablizing. The biggest buzz is how thrilled people are with the query cache. At the current pace of development I imagine the above mentioned features will appear and stabilize in version 4.1 within 2 years.
Is MySQL an Oracle replacement in all circumstances? Absolutely not, but very often Oracle is wholly unnecessary for many of the tasks it's purchased for. We're currently running MySQL + InnoDB on a 36GB dataset at a load of ~500 queries/sec average against a 3 month period. Approxiamtely 30% of queries are data modifications. This is obviously not an impressive system to many of you, but I'm fairly pleased with it, especially considering that "professionals" have been telling us abandon this toy database for years. Personally, I'm glad we saved the down payment on Ellison's next yacht.
Is MySQL a PostgreSQL replacement? Probably not. There are back and forths about speed and features--PostgreSQL does support more of the features listed above--but I find MySQL to be easier to use and better supported, and the benefits to me of switching are not very apparant. Your mileage may vary. It's not the end of the world to enforce some business logic in the application layer, and it has its own benefits.
MySQL continues to impress us and the support we receive is outstanding. And that was before we even decided to purchase a yearly support contract. I have nothing but praises to sing about MySQL, and I think it can only get better.
Oh and it's free and open source. *shrug*
MySQL is basically a database as powerful as Access and others with no performance hit whatsoever. It's not that MySQL is an amazing feat of programming (a good one, but not an amazing one) but it shows what a simple database can do when performance is key. Consider /. which is run on MySQL. A personal database powers one of the best sites on the web, bar none...
apt-get install postresql
I would suggest the reason is that for consultants who are recommending a custom solution the terms of the GPL are not onerous. The GPL unlike other licenses does NOT require one to give source changes back to the original developer. You just have to give the source code including your source changes to the customer licensed under the GPL.
In theory the customer can then take your changes and distribute them for free under the GPL. But why would the customer do this if your solution is giving the customer a competitive advantage?
I would conjecture that databases are an almost ideal situation for the GPL to not affect consultants. The customer will not be worried because in all likelihood they aren't going to be distributing the customized database outside the company, so they don't have to reveal the code you gave to them under the GPL. You don't have to be worried because even though you licensed your code under the GPL, the customer has no incentive to publicize it.
When I first came to webdb programming four years ago and looked at the open source options available (I was a poor student who couldn't even begin to consider affording anything else), I couldn't see any real reason to adopt MySQL over PostgreSQL other than the extremely tight intertwining of MySQL with Apache/PHP. Given that PostgreSQL has some basic features that MySQL does not, e.g. MVCC, transactions, etc., why do people choose MySQL over PostgreSQL anyways other than its relationship to Apache? Not trying to start a flame war, but I'm just genuinely curious why somebody would make that decision.
http://starboard.flowtheory.net/
The company I work for has used MySQL for about 4 years. First off, we are not some little code shop. We rank right up there with Amazon.com and Yahoo.com. We handle a lot of data.
If you doing heavy data mining, Oracle is your product. If you doing thing such as handling customer transactions on a web site, then MySQL is your product. Oracle has a lot of bells and whistles that you'll never use.
In our tests, MySQL is way faster than Oracle. We don't get corrupt tables (used to about 2 years ago). We have one person managing the database, where Oracle told us we would need two people if we switched.
When it comes down to it, Oracle with a 2 million dollar price tag ( that's with 30% discount ) or MySQL with a 3000 dollars service plan, it's not a hard choice.
Before you try to respond, remeber MySQL gives us no problems at all. Why switch?
Oh yeah, Sybase. We couldn't even get pass their used car type salemen. I guess that's the remaining M$ influence.
Boy it seems not a couple weeks ago we were discussing something along these lines here on SlashDot. I think I've said everything I need to say on the lacking features of MySQL, so maybe I'll chat about something else.
:)
I think everyone 'knows' of an Oracle-dependant piece of software in your shop (or school, or website, etc.) which really doesn't 'need' Oracle. We look at apps with 100 users and say - "Heck! Even flat-files would be fine for this app!". Those sorts of Oracle installs are certainly feeling the IT budget crunch. No longer can management write $80K checks to Oracle each year for support and product upgrades. They're looking for a way out and I think some of the smaller more niche products (Sybase ASE, PostgreSQL, MySQL, etc.) need to be ready to step in and take them (so listen up MySQL developers and zealots!).
When we discussed this before I brought up what I thought were valid complaints (no hot backups, no binary dumps, EXPLAIN output is cryptic and could be cleaner, replication is still a little immature, etc. etc.). Regardless, some 'rebuttals' I received were the Open Source Party Line - e.g. 'Why don't you code it yourself?' or 'There's a workaround for that.' That is certainly not a healthy attitude to tell potential customers of your product. These guys dropping $100K on a RDBMS and are feeling the pain would love to pay MySQL support contracts, however if you have the attitude that somehow the end-user, who would like to actually pay you money for your product, needs to keep their mouth shut and gratefully take what you charitably give out you're not going to retain them as a customer. Like it or not, they are used to getting what they pay for. And if you're really focused on getting more Enterprise-ish people to use it then you'd best start acting like it.
Give them what they want, treat them like CLIENTS (e.g. deserving of some respect) and not simply another l33t hax0r ("Code it yourself, n00b!") and they'll beat a path to your door.
Thanks,
--
Matt
In our corporation we used Oracle with good success for many years. We switched to Postgres for many reasons and have found great success with it. It is very stable, excellent documentation available and is much more straight forward to administer. No problem convincing the suits as the cost of the Oracle licenses went into orbit. I would recommend Postgresql for use in a production environment
The army is using mysql for at least ONE war simulation project, on the backend. Of course, I've not seen it as it is classified, just have heard about it from several sources. And NO, I am NOT talking about that America's Army game.
= Grow a brain...
Pabst Blue Ribbon!
20721
I think you and a lot of like-minded people are missing the point. There are certain apps where it really would only make sense to use Oracle or Progress or something beefy like that. Then there are apps where you can choose between MySQL and Postgres, and you might want to go with Postgres because (for example) you'd like to use some sort of procedural language. Last I checked PGSQL has 3 and MySQL has 0. Then there are apps where you can pick between the two, and it *just doesn't matter at all* which you go with, so you choose whichever one you or your developers are comfortable with / whichever one your DBAs support / etc. For a Web portal, should you use Oracle, Postgres, or MySQL? Most of the time portals would only require PGSQL or MySQL. So you pick one.
There is no one database to rule them all. Stop thinking in absolutes and just go with what makes sense.
Paranoia. It is what really drives the high-end systems. Fear of loss, Fear of CYA failure, Fear of unauthorized remote installs on the intranet, Fear of non-DBA Employee "Smith" starting up a self-managed little project, Fear of having to support "Smith's" little project if it proves to be successful, Fear of systemic failure if the project needs to grow. Fear of "why not? why can't we do that?", Fear of the lack of speed, Fear of the lack of Rollback, Fear of the lack of manageablitity, Fear of others taking the lead and doing things that "the people with the Software Licenses on the team" should be doing, Fear that things will come to a crawl with data corruption and they will be called in to figure it out and provide statistics for improvement, Fear that the backup cannot be restored, Fear that they are not the sole source of authority for the DB, Fear that some application somewhere will not work and they will be called in to fix it on the back-end. Fear of the lack of scalability when something really needs to scale. Fear of reviews and email when something doesn't quite work out on the production DB. Fear of the lack of control.
MySQL has limited support for the Enterprise. Let's face it, most paid DBA's are paranoid, critical, selfish and self-aggrandizing people who like to get it right the first time and who will not share unless told to by higher powers who may pay them for getting projects done and documented--hence, all this poopooing of MySQL and Fear of losing the corporate crack pipe. If someday an Open Source DB can really deliver the features, then crack pipe DBA's will be exposed for what they are-- people who try to remotely collect and control reality after the fact with tools that never give the real picture. DBA's only "indicate" reality for management decision making.
Wait until Homeland security has us all in the DB, crack will be on every corner.
I've been telling this all along. Linux is not such great idea for business environment. Having today such a wide support from IBM, Oracle or recently Sun we will see opposite trend in upcoming months.
How much more prove is needed to see the damage Linux is doing to our economy and companies. Soon, more and more software companies will go bankrupt if we start replacing everything with free stuff.
It's time to slowdown with linux development and rethink the strategy. Linux should stay as a hobby and free development platform for colleges before future CS students move to commercial work.
What really is the news here? "Free software is cheaper than paid software" Or maybe the news it... "Simpler tools is easier to use for purposes that do not need the features of more complicated tools" If MySQL is (or is not) a threat and not a completely unrelated product to the likes of Oracle and MS SQLServer then it is because of the notion, touted by many database zealots and salesmen, that ALL of your data, no matter how simple the application, should be in an enterprize database. The rationale, and it does have a certan logical ring, is that since you can't predict how your data will be grow and be needed in the future it makes sense to have it ALL in a common repository and since that repository represents such a huge asset it must be in the strongest and most powerfull possible storage. The fact that this greatly increase the political power and influence of the DBAs is not to be lost either.
I jumped at the chance to use MySQL for a large project as a win for opensource. I carefully designed a db that would hold one billion records, as required for my project at work. Well, after a week of importing, when it came time to reindex a field, MySQL's technique was to freeze the table and make a fresh copy (thankfully I had enough room), although the copy took 3 days (during which the db wasn't available). I switched to Oracle and life has been so much better.
In the end, MySQL might handle the raw numbers that some of the big players do, but when you're working with large data sets, Oracle (and presumably others) give you more power. Take the actual physical data structure that Oracle allows you to work with: each database comprises of dynamic multiple variable length data files that can allow tables to span physical disks. MySQL will get there someday, but they're still a little behind.
_______
2B1ASK1
It says right there that if you want to spend the time and money on non-OSS development, they'll be happy to take some of your money in exchange for providing you with some code & service.
Is it a crime to profit from you work?
Alternately, go look at the BSD licenced PostgreSQL if you want to fork it and use it closed-source.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Comment removed based on user account deletion
From the premier site for fruitless technical job searching
Mysql: 49 hits
Postgresql: 2 hits
Oracle: 4595 hits
One could argue that the people that post on DICE are dumber than most, but there still doesn't seem to be much of a market for mysql and postgresql.
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
mySQL is the right tool for *far* fewer jobs than those to which most people believe it applies. Many people end up writing code to deal with various aspects of data management that the database is supposed to take care of because they don't know that the database is supposed to take care of the data.
If you only know mySQL, you will attempt to solve your problem within the limitations of the tool. The problem is that many things can't be done in multithreaded or worse, multi-process application code to ensure integrity. If the DB won't do it, and it doesn't support transactions, then you've just gotta hope people don't ever use your application in a way that will make your data invalid.
I just don't get the appeal of mySQL. The last time I tried it, it seemed more difficult to use than postgres, and it supports a subset of the functionality. I have not done a project that doesn't require at least some basic database feature that mySQL doesn't have in years. Sure, I suppose I could've written code to emulate some of those parts of the database, but certainly not all. For the parts I could emulate, the application would most certainly run more slowly (multiple queries to emulate a subquery or what I do in a stored procedure), and the ones I couldn't would just have to be left out, which would make the applications more buggy (lack of transaction support on applications that run on multiple front-ends would simply cause the apps to fail).
Anyway, basic point is that if you don't understand your problem and/or the tools that are out there to help you solve it, you will solve it incorrectly. It may seem like it's working, but those types of implementations fail really quickly when they go multi-user.
-- The world is watching America, and America is watching TV.
Great, YET ANOTHER article on open source databases that fails to mention SAPDB or Firebird, even though they're both a hell of a lot better than MySQL in most respects (especially true of SAPDB).
Most journalists (and 75% of Slashdotters) apparently are ignorant of the advanced features offered by the "big boy" commercial databases they so love to deride; they end up doing all open source databases a disservice by equating all open source databases (in the mind of the pointy-haired boss) with the puppy of the household, MySQL.
Erlang.org: wow
Actually MySQL does replication just fine (but it is only one way, there can only be one master). If you need few updates and huge amount of reads this allows you to spread the load amongst several servers.
That's a weakness PostgreSQL (which doesn't do any replication at all) should fix in a future release.
You can enforce relational integrity (foreign keys and "on delete"/"on update") are available in mysql 3.23 if you use the innodb table handler (which is good)
Most people on a messageboard READ. They don't post. Only a fraction of readers also post, so that makes it a read intensive application - something where MySQL is good at. And if you are halfway a decent coder, you'd cache the generated page so that they are only generated once when somebody post something.
What kills the whole thing is messageboards who count the number of visits (how many times a thread have been red) or other small statistics : this require a huge amount of writes and kills the performance.
MySQL (or even Postgresql) don't claim to be drop-in replacement for DB2 or Oracle. But they claim to be good enough for simple database tasks, which happen to represent a huge share of the business market (for every high-availability banking application there are a 1000 small databases storing employee holidays, classroom affectation, etc.). These small databases are not only a bigger market in term of quantity (if not in value), but some of them also grow into big databases someday.
Remember when Microsoft was doing MS-DOS, no Unix vendors would have been worried, they had much better capabilities. When millions of PCs were sold with MS-DOS they started worrying. When Windows came out they growed gray hair. Now SQL Server and Windows Server have eaten the market of smaller servers and high-end workstation. This is the strategy of eating your way from the bottom to the top, and it will also work for MySQL and Postgresql : as time passes and as they mature they eat out an ever larger chunck of the database market.
"MySQL A Threat To The Big Database Vendors?"
*LOL*
A Fortune 500 company probably isn't limited to local business. They probably do business all over the world. I don't know which one is more globalization challenged, PHP or MySQL, but they're both like Gilligan's Island: primitive as can be.
.Net, XML, HTML 4, etc., are Unicode to the bone, the last I checked poor PHP and MySQL were both still stuck in the legacy world of regional character encodings. You can build a global app with Java/Oracle or .Net/SQLServer, but the best you can do is a regional app with PHP/MySQL.
Whereas NT/2K/XP, SQLServer, ASP.Net, Java, C#,
This doesn't only matter for monster projects. Small systems can still be global -- unless you decide to go with tools like PHP & MySQL.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Is MySQL an Oracle replacement in all circumstances? Absolutely not, but very often Oracle is wholly unnecessary for many of the tasks it's purchased for.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Few people realize that Slashdot has only ten users. Each of them has 55,000 accounts.
I have some clients that are going to be filing a suit
in LA for reperations from the rodking riot. Angry
african americans burned down entire neighborhoods
in a display of pique and my clients are going to demand
payment from the black community for damages done.
One have to remember that MySql is not a "true" open source project in this matter. If you want high level support, extra help or whatever, you can sign a contract with MySql AB. Their most extensive alternative includes visits of a developer at your premises to solve your problems. You can also have them run your system remotely. This is actually one argument pro MySql in the never-ending bashing game between MySql and PostGreSql...
Most database-systems set up by scientific projects I've seen, have been using either Oracle or Microsoft systems. This is of course completely insane considering the need they have, and a total waste of money. Unfortunately many people read a little about databases on sites like /. and start to belive that they are setting up a large database.
After reading this thread, one can easily think that American express is running an averaged sized system with normal demands on security... The truth is that almost no school systems, museums, scientific projects etc. etc. ever need an enterprize solution. An example of the problem is an institut for Marin research in Colombia where they used Oracle. They paid $15.000 each year in licence fees to set up a database for their collections. They wanted to put it on the web and needed to pay $5.000 more. This is a simple task that Mysql, with all it's flaws, easily could manage, and without the need of an experinced Oracle techincian. There are Highschool Linux geeks in Colombia as well...
The overkill in usage of database systems around is probalby enrmous and a very good source of revenue for Oracle and Microsoft. Think about this when you are bashing the lack of advanced features in Mysql. Someone might actually belive you and buy an Oracle licence to run the member database for their local bridge club...
Guys,
Let me offer my view on the Bloomberg article. It is a huge success for the whole open source community that MySQL gets written about in a publication which is for non-techies only. It is an indication that open source development is not in vain - that open source is becoming a viable alternative even in the most conservative IT shops.
So in stead of arguing for and against this or that open source database, let's work together to become even stronger in the business world!
A key reason for MySQL's huge installed base is that Monty and David - the founders - focused on speed, reliability, and ease of management. That's why Bloomberg is writing about MySQL. And that is also the way to find paying customers who make it possible to hire more programmers and further develop the product.
I am sorry if this sounds like marketing speech. We at MySQL AB are working our butts off to conquer the business world. Now as we are doing so, it will benefit all open source databases. Will you help us?
Marten Mickos, CEO, MySQL AB
One argument not printed in the article (and I suppose the true real why most new developers choose MySQL) is speed.
Like it or not, MySQL is the world's fastest enterprise quality database. Many universities and ISP's host hundreds of MySQL databases all with downright zippy performance. All those 'features' that MS SQL and PostgreSQL have only tend to make for more slothy performance.
Sure Oracle may be almost as fast as MySQL but almost only counts in horseshoes and RPG's. If you can't afford a dedicated db server or want to improve existing performance without upgrading... then migrating to MySQL is the best choice as long as you don't need stored procedures or other 90% unnecessary features.
In short, you can't run a bank on MySQL but for everything else it seems to be the best tool for the job. If it's feature rich enough for Yahoo Finance then its feature rich enough for me.
all you slashdotties must be turning over in your graves. Whatever will you do when Slashdot itself abandons MySQL?
Unless they broke something I find your story difficult to believe. I used PostgresQL in 1998 (version 5.x) for the RDBMS for Racal Telecomms ISP configuration system. I built and installed the database from scratch in a day for Slowlaris 2.5.
Our experiences with PostgresSQL were largely positive for an open source database. For the scale of our project it was ideal and the database seems to have progressed in leaps and bounds since.
But IT depts will still go Oracle because it is a sought after skill on the jobs market and because their salesgirls wear short skirts and have big hooters and give good head (allegedly). Most managers prefer that to spotty geeks telling them how incredibly lame they are to use Oracle for the company time sheet system.
David
Being a developer of Java web applications myself, I always wonder why Firebird doesn't find any broader use.
I mean, in an commercial environment, there's always the reason to have someone to blame if you choose a closed-source solution like Oracle or DB2, so the managers refuse to accept Free Software or Open Source. Plus there are features in Oracle etc. still missing in the free alternatives.
But what about all the small, non-commercial projects? Firebird is really easy to install, it's scalable as hell and is, contrary to MySQL, a real database.
TPC results are posted by database vendors themselves. It is a really expensive procedure, because the compliance to the official rulebook has
to be meticulously documented. This is why you don't
see many posts from smaller vendors, even though their product is often faster. (The fastest db I am
aware of is kdb by kx systems (www.kx.com), by far)
A "RDBMS" that does not support very basic RDBMS functionality is not a threat to any of the big RDBMS vendors. No company that cares about its data would be storing it on MySQL.
Scanning through these posts, I even saw one ridiculous person say something about being tired of all of this "database pretentiousness"... as if demanding that the application that is storing your *data* - one of the most important assets of your corporation - actually supports *basic* RDBMS functionality.
So, go right ahead. Acuse people who actually manage databases for a living of being "pretentious", and store your data in a database that doesn't even support foreign key constraints, or stored procedures. Write all your logic into your PHP code, since you can't actually write it into the database itself.
Then, when your database becomes a totally corrupted nightmare, because you can't even enforce basic standards of relational integrity in MySQL, maybe you'll think about all the "pretentious" people who actually knew what they were doing, and think that maybe you should have listened to them.
I wish that journals writing about the benefits of free software would stop promoting low cost or cost savings as the primary, or even the only, benefit.
You really want to be able to "splice" your database into separate files by row, column or whole table, so that you can put those files into different partitions in order to minimize disk arm contention.
Two weeks ago I sat in a room full of US AirForce SysAdmins. Mostly they are a MS SQL Server shop. I mentioned MySQL and every SysAdmin, to the person, chuckled and cracked a smile. The manager turned to me and said, "We had one of those installed a few years ago."
Apparently, MySQL was a joke to them. Thats a pretty big institutional hurdle to jump.
From my own experiences MySQL does what it does very well. But lack of cascading updates/deletes and subselects are the big problems. SQL Server has plenty of its own quirks though(but you don't read about those on the side of the box).
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
> 1. Supports subselects
> 2. Supports views
> 3. Supports triggers
> 4. Supports stored procs
> 5. Does most the things that everyone takes for granted with a decent db server
Strange. Am I missing something, or am I just dumb? Firebird (open source version of Interbase from Borland) does all that, and does it well. It runs on Unix, Linux and Windoze (yes, some people need that), works very nice and fast, is reliable, costs exactly nothing, and I use it in quite a few real-world applications.
How come I never hear of it on Slashdot?
Have a look at http://sourceforge.net/projects/firebird/
Ciao,
Klaus
Free PC version of ChipWits at http://www.breueronline.de/klaus/chipwits/
MySQL isnt a competitor to these DBMSes, but instead it compliments them. Oracle and DB2 and the like are all geared towards complex, highly transactional systems where there's loads of updates going on which can't be allowed to collide.
MySQL on the other hand, is a system for storing tables and looking up information in them - and quickly. This has its uses, look at Slashcode and forums system such as vBulletin (which I happen to have the displeasure of customizing and maintaining on a site I go to... ugh what a fucking mess) - for automating websites, systems like Oracle are overkill. For eCommerce backends and data mining MySQL doesn't cut it. Pick which one you will based on what you want to accomplish but neither is a 'threat' to the other.
I feel most of this crowd will be quick to put down the things that have made MySQL popular, because they don't consider market evolution. But just like PCs eventually destroyed the mainframe business, and the web destroyed client-server development models, MySQL will continue to erode its niche into the multi-billion dollar database market.
My business decision was influenced by the fact that no other database can return queries as fast for this data size. If my data were 1000 times bigger, perhaps Oracle would scale better. Or if I had 1000 times the number of users. But this little business will make me enough to retire well before MySQL runs out of capacity.
Technical specs: Apache, Tomcat (via mod_webapp), MySQL. The customer is a government agency requiring archival of and reports generated from their 4 million clients' data. The hardware is semi-beefy Xeon SMP machines. All performance requirements derive from the need to serve 30 application views per second: there are approximately 250,000 target users.
Transactions: http://www.mysql.com/doc/en/ANSI_diff_Transactions .html
I guess having an equivilent feature and naming it someothing else confuses too many people.
Stored procedures are insecure and do not scale to well. The concept is to encapsulate the logic and make it easier for programmers to access the DB. This can just as easily be done with an ASP or PHP class or java bean and using any DB's getRows() function. The performance is FASTER this way because your scripts or programs do not have to wait for the DB to execue code and return results. Overall application performance in a multi user system is not just based upon the speed of the query, but on how quickly the DB connection is open and closed. Bottom line is that there is absolutely no need for stored procedures to exist and such a feature in MySQL would only add to bloat.
Subqueries: For the most part, a (self) join will be more efficient than a subquery and will perform the same task and return the same results.
Bottom line is that MySQL does EXACTLY as advertised, it stores data in a logical manner to be retrieved later. While it could be more robust, adding in features would only bloat it and ultimatley affect it's performance. In addition, the fact that you really cannot run arbitrary code on a MySQL database makes it much more secure than any DB which allows SP's and scripting of the DB.
... Governments are instituted among Men, deriving their just Powers from the Consent of the Governed...
When designing a database application the first decision is where the application logic should be stored. In a large database the choice is to store logic in the database or in the application. There are good reasons for both approaches, but mySQL limits you to strictly application logic. While this is not bad and makes most programmers happy, it's also one of the most common causes for inefficient database usage. Most programmers think more in loops than SQL and a loop is the kiss of death for a database. The one undeniable requirement of a database is the ability to filter and return only the data needed for a given operation. Since mySQL does not support sub queries, stored procedures, ref cursors, etc, it simply can't do this. The work around is to pull the required information and analyze it in the application. Again, this is a programming solution that has to be applied because the database is not up to the task. The argument against the big databases is that they offer too many things that folks don't use. This may be true, but the corollary is that there is a large pool of things that I can and will use. I would use mySQL in the same places I'd use MS Access for about the same reasons. This makes it a handy tool for database development and testing. However, I don't think it really qualifies it as an enterprise database or a realistic "threat" to Oracle, DB2, SQL Server, etc.
If there is a bug in package A, the corp would have monetary incentive + engineers to fix it. (This is hypothetical, so spare me real world scenarios...) If there's a bug in package B, what exactly is the incentive to get it fixed in a timely manner?
Um, hire somebody to fix it for you? At least with package B, you don't have to pay huge fees just to install and run it. In either case, you're gonna have to pay to get something fixed (although with package B, it is at least possible that you have someone in house who can do it).
It's not like there aren't companies and individuals out there to fix mySQL bugs, or add features.
Of course, maybe there are too many choices, and you don't know who to hire? I can sort of see that, I guess. But in other areas of business, multiple suppliers are usually seen as an advantage.
Use Real GPL Fast Storage System : RAM.
Prevayler
Whereas NT/2K/XP, SQLServer, ASP.Net, Java, C#, .Net, XML, HTML 4, etc., are Unicode to the bone, the last I checked poor PHP and MySQL were both still stuck in the legacy world of regional character encodings.
Have you tried using UTF-8, an encoding of a sequence of Unicode characters into a sequence of 8-bit bytes, with your PHP/MySQL design?
Will I retire or break 10K?
In the case of libmysql (C native-interface library of MySQL), developers are forced to pay so much money for using GPL code(libmysql) in their software as non-GPL state, plus their customers have to pay money for commercial-licensed MySQL server.
Bull. The libmysql client software is NOT GPL but rather Lesser GPL, which allows linking the client software against a proprietary application program. "A license is not required if: You include the MySQL client code in a commercial program. The client part of MySQL is licensed under the LGPL". Even then, MySQL with InnoDB is $400 per multi-processor machine, as opposed to MS SQL's $20,000 per processor for the unlimited-client license.
Microsoft doesn't require such license fee when you use OLE/DB etc. to get native access to SQL server.
Yes it does. Microsoft SQL Server is priced based either on the number of processors or on the number of machines that will access the database.
Will I retire or break 10K?
MySQL can't be a real threat until they handle stored procs (version 5?). MySQL is a great db, however... especially with phpMyAdmin. QQuick & easy to get a blog or /. type site started.
MySQL is Linux/KDE.
;)
ProgreSQL is FreeBSD/Gnome.
MySQL A Threat To The Big Database Vendors?
Nope. Not really.
Is the bug likely to generate fewer sales or not?
If such a bug causes loss of data or compromise of private information, and the story hits Com.com or one of the other tech news sites, and the product does not have a monopoly in the product space, you bet the IT people will do their best to avoid such a product for new installations.
Will I retire or break 10K?
Against Oracle?
Maybe when about a million things that are part of the SQL stanard make their way in. Last time I used MySQL, it couldn't do subselects.
First of all nothing in the original post said anyting about running MySQL/PHP on a Linux box. If the guy went in and pitched running it all on Linux w/ Apache it's no wonder he got laughed out the door if thei standard is MS Windows servers. (think about it, would you walk into a Solaris shop and suggest that their new billing system you are bidding to write for them should be using VB on SQL Server?)
;), tell them that they can still use their apps if they install a Linux server and their TCO will be less. Then point and laugh at the ASP deverlopers trying to figure out what they are supposed to do at the blinking cursor (wondering why everything is black and white and where's the icons?) when they are porting their ASP apps.
I've installed several PHP/MySQL based Open Source web applications on our Windows 2000 intranet server with no problems (I've then had to abstract out the DB calls so that I can move the data to our Oracle server since, apparently, most LAMP developers can't be bothered to architect their applications properly and have hard-coded MySQL function calls everywhere), surprisingly enough even running as a CGI they still execute faster than our ASP apps.
This could be a better way to migrate a company to Linux, get them hooked on PHP applications installed on their Windows servers. Then when Microsoft comes around for their yearly upgrade check
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
Just two weeks prior /. posted an article covering SourceForge's transition from MySQL to IBM's DB2. Would this have happened if MySQL was a contender or was in the process of becoming one in the near future?
If you searched for Linux or Java jobs 5 years ago you would have a similar ratio to that of MySQL versus Oracle. What is your point? In your world does new technology ever get developed and accepted?
I have used Interbase from Borland and Firebird is an excellent choice.
It is easy to set up and maintain and it is a full commercial implementation.
Yes, and it has the good stuff too (triggers, stored procs, views, etc.).
And, if you really need to pay someone you can always get Interbase from Borland directly.
NexuSys - Linux support by the best
word nigga
OSS is on a technical level developed with true competition as to what is best. But when it comes to integrating many of these systems, a lot is more about who has mindshare and momentum. PostGres && MySql were the original OSS databases. It took a long time and interesting projects for them to have momentum over dbm. For MySql, it was LAMP.
Postgres was the first truely decent OSS DB and that gives it its' mindshare. Sap and Firebird will come up in the future, but it will something interesting to fire ppl up on it.
Gee, how many times does a database software project fail solely because of the choice of database engine? I suspect that it is alot less then one may imagine. In most lousy database applications, I will bet that the fault was a terrible database design/implementation. Either there was total lack of normalization or if the time was taken to do a proper design then the implementation was a mess since it was done by developers who did not have a clue as to what a join was. Let's face it there are lots of IT departments that can cough up a lot of cash to buy a commercial database but can not commit to a first rate data modeler, DBA, Entreprize Data architect, or experienced developers trained in database design methodology. Lets face it, there are still lots of terrible shops where the idea of database design is throw a much of spreadsheets into a relational database. Yes, MYSQL is lacking a some features that are still in its development pipeline. Yes, Firebird/Interbase has been arround and works, but has come perhaps to late to embrace the Opensource tide for it to succeed. But who cares if Postgres vs MySql is the way to go. My point is this. Most organizations would be better off putting the money they blow on a over-featured commercial database and spending it the human resources they need regardless of the database chosen. There has been lots of bashing of MySQL because it does not have the Stored Procedure support of an Orcle or Sybase. But what does a Stored Procedure really do for you. It improves performance buy precompiling the database acceess and allows one to encapsulate the specifics of the database access allowing for future enhancments to the underlying database design without effecting the application. Gee, can't one do the samething using for example MySQL/Perl/DBI/Mod_Perl/Apache. Better yet using the Perl DBI one can largely take the choice of Database out of the equation. Stored procedures are often used to manipulate Normalized data into either a denormalize or Hierachical format. Want to manipulate data/text? Then, what better tool then Perl? Need a big boy database engine like Oracle down the road. Cutting over should not be a show stopper using the DBI. In reality however, both Sybase and especially Orcale stored procedure languages serve as a means for locking in the customer for 5/10 years into their database. Then Oracle can rape the customer for years on the licensing fees. Smart IT managers are well aware of this. MySql, Postgress and the other Open Source database can be used intelligently to break free from these traps. Open Source database could end up commodizing the database market. I think that was the true point of the Bloomberg Article.
MySQL is too simple and DBAs dont like that.
:-)
DBAs salaries and jobs are under risk when MySQL is used.
I would love to use an OODB instead of a RBDMS. I cant do that. But I can choose a RBDMS that everybody loves including myself.
Your post is 100% correct, as are the parent posts.
The MySql:Oracle::slingshot:M1 tank analogy is perfect. Your scenario is correct as well. They shouldn't be wasting money on Oracle for such a small job.
The bottom line is that MySql is a replacement for Access, not a real DBMS.
Some versions of MySQLGUI will crash if the database has a long text field with newlines. Scrolling doesn't work right. And about half the time, the program won't connect to the database because it's little state machine for connection is out of sync. None of this should be hard to fix. But this is the sort of thing that makes a good program look broken.
No loss can be demonstrated by anyone currently alive.
Compare the life of ANY African American today to what their life would be in West Africa if their ancestors hadn't been brought over.
Without InnoDB's betasoftware, does MySQL do:
-Transactions? No.
-Nested transactions? No.
-Savepoints in transactions? No.
-Triggers? No.
-Nested triggers? haha... No.
-User defined types? No.
-User defined functions? No.
-Views? No.
-Indexed views? Haha... No.
-Partitioned views (i.e. a view created from subviews retrieved from nodes in a cluster)? No.
-Subselects? No.
-Stored procedures? No.
-Role based security? No.
In other words: it's nice when you don't need all the stuff above, but trust me, every decent mission critical application does need some or all of the stuff above. So a thread to big database vendors?
No Fscking Way.
Never underestimate the relief of true separation of Religion and State.
And with a little work, MySQL can be made more ACID compliant. However, my big bitch is that it doesn't support foreign keys.
To be a RDBMS, I expect proper handling of keys. I know I can write the SQL to fudge this but does anyone know of an 'add-on' that might fix this prior to the next release?
This is my sig. There are many like it but this one is mine.
Does MySQL do foreign keys yet? I don't mean allow you to enter them, but rather does it enforce them?
Last time I played with MySQL it didn't... great DB that is
Yes, especially as the platform and the database are supposed to become one in the Windows "Longhorn" release, meaning that the file system runs on top of the database.
It would be fun to imagine that developers might plan to unite, say, PostgreSQL and ReiserFS in anticipation but unfortunately Strategy is not Open Source's strong point. Like the dithering between supporting Java on Linux, cloning Dotnet or doing something new, by the time any clarity emerges Linux-the-platform will have given away a lot of ground.
Please mod me down, I will say lots of bad things about MySQL (although all with explainaition).
Yes, this is a rant.
I have used a lot of relational databases in my life: Oracle, PostgreSQL, MS SQL and DB2 (presented in increasing order of preference)
Currently I am using that persistent system (I can call it database but never relational) called MySQL.
1st: MySQL is not fast. It is fast only if your SQL level is very low. A database with a decent optimizer and carefully created indexes will always be faster then you as programmer doing 2 queries and merging the results because you cannot use a sub-query to express your idea. So if all you want to do is basic SQL then MySQL maybe OK, but if you read Joe Celko's books on SQL, sorry, you cannot use them, please downgrade your knowledge and also your speed expectations. I have a colleague that says: "MySQL is faster then PostgreSQL, I have tested", by some coincidence the same colleague says: "I don't really know what the DISTINCT keyword really means".
2nd: MySQL stability is that great? If you try to use its most advanced SQL facilities (like the very advanced DISTINCT - yes I am being sarcastic) you might stuble into bugs, I have, with a simple SELECT DISTINCT with a blob involved (not even on the query, just on the table of the SELECT).
3rd: And the paid support (which the company where I work has)? After reporting the previous bug I spent one week convincing the support guy that it was indeed a bug, he several times come to me and said: "you are doing things in a not correct way, the correct way is mine". In all cases they were not correct and I lost lots of my time preparing cases to prove that he was wrong (and expaining basic SQL concepts like for what you can or cannot use a self-join)
4th. And the support for standards? Not only from a syntatic, but from a semantinc point of view they seem to disregard standards more than MS (MS which in the database world seems to be reasonably standards compliant). BTW, when discussing with their support about the non-standard compliance of some of their semantincs, they come with a response that was
5th. something like: "This is not a bug. As it is documented it is a feature. We know that its behaviour might be somewhat unintuitive in some situations". Is there anything more that need beeing said?
I am all in favour of Free Software and its philosophy, but if I had to choose between MS SQL and MySQL, I would choose the 1st one without blinking.
Also I believe that it would be better for the FS/OSS world that we have good thecnical products to show, that our development model is better. This is not the case in the database world. And if it is MySQL that gets the spotlight then it is clearly the worst kind of publicity, FS/OSS needs.
You kids crack me up. Take the worlds best database, now make it twice as good, now make it free. Will it be successfull?
No it wont.
You have to sell the database, there have to be people who know how to use it, it has to be implemented by several companies successfully.
Imagine a similar idea with a pacemaker:
Hi, we've got a $10,000.00 pacemaker that we know works for sure, or we have a $5.00 pacemaker that we think is twice as good, but hasen't really been adopted by alot of people, which do you want?
Not to mention the costs and problems of changing to a new system, when you have one that you know is working.
Another thing MySQL has going for it is documentation, something essential to a newbie coming to databases for the first time. Not just the online documentation, but do a google search for tutorials on php + database, and more likely than not, the database will be mysql. There are plenty of good ( and not so good ) books on mysql as well.
Theoretically, once the newbie has some experience under their belt, it shouldn't be hard to learn postgresql as well. They aren't the same, obviously, but the basic skills/concepts are transferable. However, once you've got something you know and like and which is working for you, how likely are you to go learn something else?
The point is that employers aren't advertising for people to use this technology, and the numbers aren't growing. It would be good if they did, but I suspect many employers are simply ignorant of the skills that they could use.
Here are the numbers for mysql on DICE over the past few months:
6/12: 52
7/25: 39
8/17: 49
I would be happy if the numbers were going up (there's a reason I searched for this term), but there's no indication of major growth that I can see. It's the usual chicken and egg situation.
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
1. Small, lite-duty engine mostly for embedded or small-footprint apps. Subset of lanugage of #2.
SQLite: http://www.hwaci.com/sw/sqlite/
2. Full language, but lacking performance tuning. Mostly for development and smaller shops.
Firebird: http://firebird.sourceforge.net/
3. "Big-iron" version that has full language and performance tuning features.
SAPDB (almost, but still not up to Oracle's standards): http://sapdb.org/
Erlang.org: wow
Hmm... I kinda missed your "with little or no application rewrites along the way" part, but with regard to scalability/ease/completeness of language support alone, my post above is still valid.
Your wish for such standards-compliance is unlikely to be granted anytime soon, though. As you know, the various database all use different procedural SQL language for their stored procedures and triggers, and in that area there seems to be no push for standardization whatsoever.
Erlang.org: wow
As I see it, MySQL is not much more than an SQL programmable datastructure, and that's also the way many people use it (and for which it is very well suited).
But MySQL still lacks the features that a *real* RDBMS should provide. Thank god it finally has transactions, but it still lacks views, subselects, foreign keys (as far as I know, though they are planned now for 4.something), pl/sql, good concurrency support (i.e. it has table-level locks), etc.
And RDBMS should not just provide insert and select, but data integrity, security (possibly through views), triggers (and a language to handle them) and scalability (which at this moment MySQL does support better than PostgreSQL, though I do expect PostgreSQL to be the better/more flexible here in the future)
If anyone is stupid enough to use Oracle to run his weblog, Oracle may lose a customer to MySQL there. But for the rest, I think PostgreSQL is the bigger threat.
The dirty secret of big databases is that most people don't know how to program them, how to configure them
This is correct.
and don't need most of the features
This is where you're wrong.
They do need the features - they just don't know they need them... so they implement the features themselves in the apps..
I think the main reason MySQL gets more hype than Postgres is because of the interfaces available. When I was dealing with that sort of crap (about 2 years ago) the Python interface to Postgres was very bare-bones, and almost unusable if you didn't know much SQL beyond a basic SELECT statement. The MySQL module for Python, on the other had, had all sorts of "Python-esque" ways to mess with the data without even knowing what an SQL statement is, and as I understand it, the MySQL interface in Perl was even friendlier to the SQL-unaware. The obvious drawback to the Perl interface though, is that then you have to program in Perl.
Best Slashdot comment ever
no, i couldn't help it. had to mention them at some point -- they get very little recognition in the OSS community, even though firebird (no longer interbase) is a sourceforge project, etc.
... and it does transactions correctly. it think the problem this user had (not the one i'm responding to) is a lack of understanding transactions: there's the careful way to do it, and then there's the rest.
... and A has updated a row, and B asks for it before A has commited, we have many options: refuse, read the change, read as it was before the change ... force to wait until commit or rollback occurs, then give latest version (whatever that may be) ...
... if A updates, B updates: refuse right away, tell him it's locked.
... but that's rare, all considered. the safest is to fail right away.
... but that's very risky, and so very rare ... bah.)
... consider firebird: as of php 4.2.0 (RC ... oh, 4) support for interbase/firebird hasn't given me any trouble. it's easy. as to c++ support, that exists too ... also quite easy. ... and unlike mysql, it does everything an RDBMS should do, correctly. i have no problem with postgres, except perhaps the backversions thing ... kinda worries me. both postgres and firebird, to my knowledge, support arrays as a datatype, although i've never had a use for them (not exactly 3rd normal form, if you ask me ...)
...
it's easy to use, multi-platform capable
if i have two transactions, A and B
even better is the case of A updating a row, and before it commits, B trying to update that same row (say, counting the number of times something has been updated, without using generators?) -- in that case, you can again: refuse, force to wait, say it worked, then fail one or the other, based on who commits first, etc.
but the safest way is this: A updates, B reads: give B the latest version -on his transaction-
on the first, that's fairly obvious, the second, however, takes reminding yourself of your options: does B get to think it worked, then fail randomly later if A commits? you could also wait around and -hope- A will rollback
(one case for hoping for rolling back would be the use of a temporary table, updating it, then discarding the changes, as part of some temporary process
by the way, for those who like mySQL because of PHP support
and no, i'm not on the firebird team -- i just used it, and fell in love with it
I've used Postgres in a dozen relational database-backed server projects in the last three years. It installs faster than MySQL, I can do a Postgres install in literally ten minutes to get a functioning basic configuration.
Sometimes, I believe the MySQL advocates are in some kind of strange parallel universe. Postgres is a real Oracle-killer at the low and medium end, and is a breeze to install and maintain.
People might have gotten scared off by the old
buggy Postgres implementations circa 1993 or so, but that code is long gone, the system was totally
rewritten and since 7.0 has been creeping up on
Oracle territory. MySQL by contrast, still lacks basic required stuff like ANSI syntax and tranactions.
Because it is appropriate and proper to black box the database from the front end developers.
Oh, I very definitely see your point.
MySQL gives you no protection from your front end developers, and its use should be restricted to situations where you do not need protection from your front end developers. It's a very different world-view.
They already moved from MySQL to Postgre a while ago, and now are moving from Postgre to IBM's DB2.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
clueless programmers like you is what seems
to make many data stores totally corrupt.
Of course MySQL is a threat to the big database vendors, Microsoft is evil!
1. Store user comments in a web site -- no need for ACID here?
...)
2. Storing user preferences that need to be queried at each page view
3. Storing cookies
4. Logging activities that you want to query/aggregate elegantly later
5. Store temporary data (example: in a wizard type web app, there was an upload file widget, and I stored the data in MySQL to keep the data persistent accross pages, and when the user clicked 'finish' it was sent to an oracle DB).
Store mailing list datas (email addresses, etc
6. Store access control information that need to be queried at each requests
7. Implement a special purpose search engine.
For any transaction intensive, ACID dependaent application you would be putting your job in your own shaky hands, opting for MYSQL. Have seen this personally at the rather large shop I work at.
I would stick to SQL Server, (this is a credible alternative since version 7 SP2) or the other normal Oracle/Postgres given budget/platform freedom.
I'm planning on creating a site that uses a database where users can post free text ads for merchandise for sale (already working without database at http://www.gothamcitywebmerchandise.com ) and will in the near future allow merchandise for sale with picture ads for free. At a later date, if volume is too high, I may need to charge a small bandwidth fee for placing the picture ad. This is a learning experience for me for gnu/linux apps. If I need to charge a small fee, can I use MySQL for the transactions? I envision paypal (which I know sucks, but what real alternatives are there?) or some other payment processor, and it needs to be automated, as I expect high volume if I am not profiting from the fees. Can I use MySQL for this type of application? Is the features that I'll probably need missing from MySQL, and I should start directly with Postgres? I am trying to hit the ground running, and want to start learning the database right away, but I don't want to waste time on the wrong one.
Thanks for any (practical, not advocacy) advice.
This article seems to have been sparked by Yahoo's consideration of mysql, but it fails to mention that Yahoo has run FreeBSD from the beginning. Talk about the "viability of open source," Yahoo is one of the most popular and highly trafficed web sites on the 'net and always has been.
But when it comes right down to it, MySQL is a niche player. It's niche, luckily, is the average consumer. It's a very well designed DB, but it was built for speed, not combat.
Don't pretend that it's something it isn't. Don't bash it for not being something it wasn't ever designed to be. Don't try and convince me that it's no good because it doesn't yet have features I don't need.
Oracle is a tank, MySQL is a sedan. I don't drive a tank. I don't need to. You may work where you need to drive a tank, but that doesn't make it any more appropriate for what I do. If you need that added benefits that only a tank can provide... well then I hope you can afford one. They cost a lot of money to own and to operate. MySQL is free, it works very well, it's surprisingly reliable, and it does what almost everybody needs.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
I guess what I am most curios about is how many times is Oracle, DB2, or MS SQL used when it really isn't necessary? Does any one have any ideas? From stories like mine, admittedly not very statistically significant, it seems that there are quite a few times one of the big ones is purchased, when it really is not necessary.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
> The specifications for the TPC benchmarks are
> freely available -- it's fairly easy to write a
> client application that follows one of the
> benchmark specs to test a specific database.
> contrib/pgbench in the PostgreSQL tree, for
> example, implements a "TPC-B-like" benchmark.
Yeah, but it takes a lot of time and equipment to run a full suite of benchmarks - especially if you want to know how it'll run on a 4,6, or 8-way SMP, with different io subsystems, with different schemas, different data characteristics, different tuning parameters, etc, etc.
And you need to run a variety of them - since any application worth its salt will need OLTP-oriented transactions as well as table scans, loads, unloads, etc.
Meanwhile, you get folks claiming that 'X' is faster than Oracle - and all they've done is compared a few queries on a development workstation.
And the irony is that the open source databases are probably the only ones that you can publish benchmarks for without prior vendor approval.
Does MySQL work well for your particular database applicaton? -- If so then use it.
The more robust and comparable that MySQL becomes to commercial database programs, the more MySQL will be used instead.
It looks like this is what's happening right now.
This can happen if you use the serializable transaction isolation level. It is not the default - you have to specify that isolation level for your transaction. And as far as I know, it is the only way to implement that isolation level while still allowing any kind of concurrency. I have never had to re-run a transaction with PostgreSQL, because I use the default transaction isolation level. You might want to read the relevant documentation.
I have seen the "re-run your transaction" message - using MS SQL. Yes, "real" databases do do this. Again, it depends on the transaction isolation level.
Most of your other points don't even apply to PostgreSQL. PostgreSQL has log-based transactions. It does not use one file per table (I can't remember how many files there were in my last PostgreSQL DB, but it wasn't many and certainly wasn't one-per-table). Others have commented on your other points (except XML) so I won't repeat them.
You might want to take another look at PostgreSQL. Don't assume that it is the same as MySQL (if that is where your criticisms are coming from).
I haven't tried MySQL so I really can't comment on it.
I used to think MySQL was fast and efficient. Then I started actually using the data for something other than photo albums and shopping carts. If you want to do some real data reporting in MySQL good friggin luck.
Recently, I was writing some automation to export data from MySQL to Oracle and found that the SIMPLEST outer join on two small tables 10K rows, returning less than 7K results takes a full minute to execute on a 1Ghz PIII. What a pathetic joke! Even if it wasn't tuned optimally and had to do full table scans, it shouldn't take that long - Oracle wouldn't even breathe hard with that kind of data set. MySQL has no stored procedure language, no view capability, no foreign keys, nothing but bare metal. I thought these trade-offs were for speed, but apparently not. It is a slow-no featured DOG with shitty JDBC drivers.
I have a high opinion of PostgreSQL because of it's object relational model and the fact that it *does* have a stored procedure language, foreign keys, and views, etc. But I haven't yet had the opportunity to test it's speed in a real production environment. It is on my list of things to do to test it with similar production data to see if it deserves the kudos I regularly heap upon it.
Bottom line is however, anybody trying to use MySQL in an enterprise is kidding themselves.
Trabalhos Prontos
Juiz de Fora IRC
Every major database on the market has a query cache (built in or optionnal). And that's because query cache is a good thing. Many web pages cannot be cached because they mix static and dynamic content. Here only a query cache can help. Also some queries are just plain slow to process no matter how good your database is, and there's no reason not to use a query cache here if the same query is run twice.
I'm talking about query results. Some queries don't benefit much from data cache. Think about computing the average of a column on 100 million rows, with a 50 GB table. Most likely the rows won't fit in any data cache (and hence require to read the whole damn table no matter what), but the query result (one float) will fit easely into any query cache along with the query.
My site for example does charts based on a lot of rows. It's long to compute and read only, and yet the result set is small. That's a perfect job for a query cache.
Also while a data cache can cache data, it still requires you to do the computation. If you use regular expressions and other computational intensive requests the data cache is far less efficient than a query cache.