MySQL A Threat To The Big Database Vendors? 477
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.
LAMP (Score:2, Redundant)
It's the ultimate Free Software combo... and it powers StumbleUpon just fine, thank you!
Re:LAMP (Score:2)
P less commonly means Perl and Python.
And L can sometimes mean FreeBSD.
But otherwise, Sun has J2EE, Microsoft has .NET, we've got LAMP.
right. (Score:2)
mysql/postgres have their place, but oracle is not running scared just yet.
Re:right. (Score:2)
Why don't they use dBase IV... (Score:2, Insightful)
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".
Criticize MySQL and get modded down (Score:5, Insightful)
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.
Re:Criticize MySQL and get modded down (Score:3, Interesting)
When I bash Apple (and I love to bash Apple) I get modded down accordingly. When I say that I have legitimate complaints about Apple, I don't get modded down. If you say something like "MySQL lacks certain functionalities such as a, b, c, and d and for certain uses of databases such as scenario X, it just doesn't cut the cake. In comparision, Database Y really does the job well" You're not gonna get modded down. You'll probably get modded up as informative, and inspire some interesting conversations about "Well, yes. MySQL doesn't do that, you're right. But I don't see how the scenario you described requires that functionality".
If something's informative and deserves modding up, it gets modded up. If something bashes a program with little more than "It's evil because I say it's evil" or "It doesn't have half a bazillion functionalities" and then just assume those functionalities are completely wide-spread knowledge (in which case you're being terribly redundant...) then it's really not worth slugging through, and should be modded down accordingly.
-Sara
Re:Criticize MySQL and get modded down (Score:3, Insightful)
Yes, it usually does. However, uninformative M$ bashing often gets modded up on slashdot too. (Not to say that the multitude of M$ problems shouldn't be mentioned, just that ignorant slanging doesn't add to the cause much at all)
Well, yes. MySQL doesn't do that, you're right
Yes, MySQL has problems. The biggest issue is often scalability - just because it will work fine on a small project doesn't mean that its going to scale to the enterprise level. A similar comment could be made of the M$ Access & the Jet DB - perfectly fine for a single user app, doesn't scale well at all.
In fact, while I think that MS Access provides a nice RAD environment for (very) small projects, I have no doubt that the future for MySQL and PostgreSQL is much brighter because of their open source nature. There are no artificial constraints on their functionality, in stark contrast to M$, who want you to upgrade to (& pay for) SQL Server as soon as possible. So I can see both MySQL and PostgreSQL improving over time much faster than M$, who want to tie improvements in functionality with a similarly improving revenue model.
Of course, when it comes to databases, really there is no competition bewteen Oracle and PostgreSQL. If you want the most frequently used small database program in the world, look no further than Microsoft Excel.
(Technically I think that last paragraph is a high level troll - but I'm sure alot of DB people would see the humour)
Michael
Re:Why don't they use dBase IV... (Score:4, Insightful)
You might not be kidding, but you also don't know what you're talking about.
MySQL is the greatest thing since sliced bread for those that find that it DOES THE JOB. MySQL has done everything I need it to for my applications and does it fast. I run several websites using MySQL and it works great. I wouldn't even THINK of using SQL Server, Oracle, or any commercial software instead. In fact, the MyPhpAdmin intetrace is much BETTER than what I had to deal with when I worked with SQL Server 6.5--the last version of SQL Server I've had the misfortune to use.
Many of the features that make the big commercial databases are bloat for many of us. I prefer not to use stored procedures--keep the data in the database and the program in the program. I don't like triggers, especially during the development process. I'd rather have a subroutine that does everything that needs to be done rather than rely on a database (and tie myself to it) to trigger certain actions. I'm not fond of database-enforced relationship constraints. I'd rather my code insert the right data than have the databse reject a transaction with an error because something went wrong.
Sure, if you are Citibank and have a dozen offices around the country that all write their own scripts that modify the same data underneath then you might need stored procedures, triggers, and constraints to make sure no-one messes up the data. But for 95% of the database applications, stored procedures, triggers, and even constraints are bloat. If I can SELECT, INSERT, DELETE, and UPDATE, MySQL serves my needs.
You also seem to be missing the point. The U.S. Government is already using MySQL successfully. It has never crashed (in the case cited by the article). Yahoo is already using it and is thinking about migrating the rest of the site to it. Last I checked, Yahoo is one of the highest-traffic site on the web. I don't think they'd make a decision like this without some real investigation. If MySQL is good enough to even be considered by Yahoo, it's definitely good enough for 99.9% of the websites out there--despite your well-informed, expert opinion. I personally believe Yahoo's decision has a little more weight than soem rant by an anonymous coward on Slashdot.
Oracle and SQL Server might have their place on 0.1% of the databse applications out there. But, believe me, they aren't going to be able to run a profitable business on that 0.1% of the database market. And the rest of the market CAN consider MySQL. Or, in the case of your relgion, PostgreSQL.
GPL of MySQL 4 is big obstacle for non-OSS dev (Score:5, Insightful)
(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.
How? (Score:2)
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.
libmysql is LGPL not GPL (Score:4, Informative)
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" [mysql.com]. Even then, MySQL with InnoDB is $400 per multi-processor machine [mysql.com], 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 [microsoft.com].
Not yet. (Score:3, Insightful)
Maybe someday. But not today.
Re:Not yet. (Score:5, Insightful)
You might have had a point if you'd mentioned that Oracle was more flexible than MySQL. MySQL doesn't have all the features that Oracle has. But if MySQL has the features that are needed for a given project/implementation, then it is a valid option.
hasn't crashed yet (Score:3, Interesting)
``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.
Re:hasn't crashed yet (Score:4, Insightful)
Re:hasn't crashed yet (Score:3, Insightful)
Maybe it's not "demanding" from a RDBMS point of view, but that's what almost all sites do -- read data from a database, and MySQL fits this niche perfectly.
S
Tomorrow's top story on MSNBC (Score:2, Flamebait)
Still couple of years away... (Score:2, Insightful)
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.
Re:Still couple of years away... (Score:2, Insightful)
Re:Still couple of years away... (Score:4, Interesting)
IMHO, views and stored procedures amount to short scripts, and were added to companies making databases at the right time (pre-boom) to make a new class of database that was term'd Enterprise but realy just meant hybrid DB engines with scripting support.
Well, we are talking about relational database management systems, not a "database file". An RDBMS is the middleware between you and the database file, and facilitates crazy, insane features like concurrency control, transactional control, and most importantly security. Both views and stored procedures are very important facets of security in any modern RDBMS as they allow you to hide the internals of your database, and to only provide applications the ability to have certain constrained "I/O windows" into your database (hell, my normal design norm is to only allow interactions with stored procs, which themselves only operate through constrained views). There is nothing gimmicky about these features, and they are crucial for an "enterprise" system.
Re:Still couple of years away... (Score:3, Insightful)
Re:Still couple of years away... (Score:3, Interesting)
True but (Score:3, Insightful)
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.
Still Some Roads to Conquer (Score:5, Insightful)
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
Comment removed (Score:4, Insightful)
Re:Still Some Roads to Conquer (Score:2)
Re:Still Some Roads to Conquer (Score:3, Insightful)
If I already have 5 SQL databases, I can deal with it with one admin. Add a MySQL database and a PostgreSQL database and an Oralce database and suddenly you need a specialist in each one.
Re:Still Some Roads to Conquer (Score:3, Interesting)
Pure unadultrated bullshit. Maybe next time you won't have to rely on lying to make a point. The ports of apache, php and mysql on windows are fantastic.
"If it's not well documented, and well known stuff(by more then open source folks), then it's not going to happen."
The apache, php, and mysql documentation is top notch. What do you find so objectionable about them? The php documentation is particularly awsome. As for well known let me present you with a few facts.
PHP is more popular then ASP. More people know php then ASP. It is also easier to learn then VB.
Apache is more popular then IIS. More people know apache then IIS.
Mysql is one of the most widely used databases in the world. The primary reason for that is the ease of use and maintenance. More people know mysql administration then MS sql or oracle. On top of that any DBA worth two cents can pick up mysql in a day.
"That company is going to have to hire a consultant to fix things if they need to add things to it "
I suppose when things break in oracle or ms sql the programs automatically fix themselves.
" Backing things up is important."
Both mysql and postgres offer live backup and replication.
Re:Still Some Roads to Conquer (Score:3, Insightful)
Maybe this is why MySQL isn't as popular for database(for things other then a website)?
If you are a real DBA, then having to use a SQL console or command line tools to administrate a database shouldn't be a problem. If you need to point and click to make a backup or create tables because SQL is too hard, then there is no way you can be a DBA. Besides, there is a good web based GUI, phpMyAdmin [phpwizard.net], that lets you do most things without knowing everything about SQL. There are also GUI interfaces [mysql.com] to MySQL.
Also, PHP more popular then ASP? Possibly. But name anyone who makes money running a huge website (Slashdot excluded, they don't make money) with MySQL. There may be some, but anyone who is doing serious business isn't going to be using MySQL.
That's complete FUD. Say, do you work for Microsoft or Oracle? I can say first hand that directNIC.com [directnic.com] uses MySQL for everything. They are a very popular domain registrar (sold over half a million domains) and are certainly making money. Many other companies use MySQL and not just for running websites. You should rethink your myths [bacarella.com].
Fantastic is such a subjective word. Let's just say they are good.
Apache is obviously not fantastic (see my previous posts for why I think that), but it works well for many people. PHP is a good and I personally really enjoy using it, but I certainly wouldn't call it fantastic, mainly due to its quirks and because the developers refuse to fix certain bugs. MySQL is fantastic. It is easy to use and does what it is designed to do very well.Re:Still Some Roads to Conquer (Score:2, Insightful)
had they gone with your solution they'd most probably have to permanently hire one person to support the MySQL database, and maybe permanently hire one person to support the PHP stuff.
and that's probably ten times the cost than the cost they've now made.
loz
Re:Still Some Roads to Conquer (Score:2)
Nowhere near as many fanboys as MySQL but it has transactions and a whole lot more.
Really Good Advertising (Score:2)
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.
Re:Really Good Advertising (Score:3, Insightful)
MySQL A threat, hah, tell me another one... (Score:2, Informative)
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..
Re:MySQL A threat, hah, tell me another one... (Score:3, Funny)
--scott
Hey scott, is your last name "tiger"?
Re: MySQL A threat, hah, tell me another one... (Score:2, Interesting)
I've done a number of smaller projects on MySQL w/ Perl or PHP, and MySQL is perfect for those projects. But, my last project was a rather complex db-driven site, and the client wanted to use MySQL and PHP (partially because their previous contractor had begun to build the site on that platform and they didn't want to completely ditch what they had before), and by the time I got done I was wishing for transactions (and views, triggers, and stored procedures).
And I'm with you on the "gonne ba in 4.whatever" thing . . . it's nice that they are in the works, but until they show up in a production version, they're useless to me.
Re:MySQL A threat, hah, tell me another one... (Score:5, Informative)
well, maybe not MySql, but PostgreSql do
Re:MySQL A threat, hah, tell me another one... (Score:2)
Well, sorry, but it is worthy. It's not a "full" database like you'd like for your work, but it's more than enough for a huge number of problems. It's too bad it doesn't work for you, or it doesn't work for one particular domain of problems you deal with. Just because it doesn't work for you doesn't mean it doesn't work well for lots of other people. There are a ton of small database projects (often websites) where MySQL not only is sufficient, but is superior to Oracle. And websites aren't the only potential domain -- Oracle, for instance, would be absurd to embed in an application (and there are a ton of crappy applications based around MS's JET database engine, and MySQL kicks JET's ass).
And yes, MySQL is a competitor. It's not a drop-in replacement for every Oracle installation, but there's a lot of new projects where MySQL is used where Oracle or another database may have been necessary otherwise. It's a pretty decent structured store for read-only data.
This is quite common when people suggest some free software may be a threat to some proprietary software, and then twenty people say, "X won't be a real competitor to Office (or Solaris, or Photoshop, etc) until it has feature Y", where Y is whatever feature they use. As though the world (or, rather, the marketplace) revolves solely around them, or as if the free software developers have a duty to seek that person's approval.
Re:MySQL A threat, hah, tell me another one... (Score:2, Informative)
1. It isn't just subselects - the list of *basic* stuff includes views, stored procedures, foreign keys, etc, etc. Note that we're not even getting close to the advanced features like parallelism, bitmap indexes, solid replication, etc, etc.
2. Product & tool selection is driven by a variety of factors - including internal consistency, vendor relationships, staff skill sets, etc. So, while it is true that there are projects simple enough for MySQL (especially embedded databases) - it is also true that most *custom* database applications deserve something better than what we were doing twenty years ago. And at the point in which you have Oracle, MySQL, and then need to install Postgresql - you will be regretting the time to learn a slightly different product, obstacles to reuse, and administrative complexity of having MySQL in the mix.
And lastly - the simplicity of MySQL is largely an illusion - since without transactions, subselects, views, etc you've simply moved the complexity from the database to the application layer. And while sometimes that is fine, the typical result is that simple tasks that could be done in a few lines of code or a few minutes in SQL instead take hours and hundreds of lines of application code.
Re:MySQL A threat, hah, tell me another one... (Score:2, Funny)
"MySQL Server does parse the FOREIGN KEY syntax in CREATE TABLE commands, but without further action being taken." (taken from
http://www.mysql.com/doc/en/ANSI_diff_Foreign_K
Re:MySQL A threat, hah, tell me another one... (Score:2)
MS SQL is probably about as easy to set up as MySQL -- MS deserves credit for packaging software for the masses -- but few other commercial offerings seem to come close. In an environment where professionals are born of amateurs (as opposed to specialized training), these shrink-wrapped databases will have a strong advantage. I don't think it's certain that this environment will come to pass (far from certain, really) -- but if it does, then Oracle does have something to worry about. Because then it's not just if MySQL is good enough now, but if it gets better fast enough to grow with the skills and responsibilities of those who have started out with it (again, it hasn't kept up so far, but when it does it will be before it actually matches Oracle feature-for-feature).
If you don't understand your problem... (Score:3, Insightful)
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.
Re:MySQL A threat, hah, tell me another one... (Score:2)
This definition mentions such concepts as tables, relations between those columns, joins, etc. RDBMS is not an elitist term, as far as I can see -- it's a description of a class of databases. Other kinds of database exist: bdb (file-based hash), ZODB [zope.org] (an object store), hierarchical databases, and others. MySQL isn't one of those -- it is a relational database. It has tables, it has joins (even if integrity isn't ensured), it has a query language (that is not imperative)... it isn't a terribly featureful example, it does not pass the ACID test, but it is a relational database. A lot of the features given aren't even part of the original concept of an RDBMS (stored procedures in particular).
If MySQL is not relational, then what is it?
It already is a threat... (Score:2)
(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
Firebird (Score:3, Informative)
> 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
fast, but what about transactions? (Score:2, Interesting)
Use InnoDB (Score:2, Informative)
Also, IIRC,
Simon
risk of "feature beast" (Score:2)
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.
dirty secret of big databases (Score:5, Insightful)
You're almost right... (Score:3, Insightful)
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..
The problem with both Open Source databases (Score:2, Insightful)
1) A lack of options for scalability with large databases.
2) A lack of replication capabilities.
Until both of these are met, in my option, both are not suitable for large, mission critical databases.
In situtations like those, for companies that matter, price is not relevant.
Re:The problem with both Open Source databases (Score:2)
support real-time failover. I can keep 2000
simultaneous conference attendees running
with barely a hiccup when I unplug the foreground
server and the failover box kicks in. I could
do it for 8000 with an 8-way box with more gigE
nics, but I don't have the customers yet.
It's never failed me yet.
In other news: Vi still no threat to MS Word (Score:4, Insightful)
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
Re:In other news: Vi still no threat to MS Word (Score:2)
Re:In other news: Vi still no threat to MS Word (Score:2)
Everyone reading Slashdot is. A half-million users and I don't see it failing.
As I said before, why use a truck when a bicycle will do the job?
Re:In other news: Vi still no threat to MS Word (Score:5, Interesting)
I finally gave up. I got it installed and mostly working, but I just had better things to do and I wasn't at all happy with the number of hand-tweeks that were required. I slapped MySQL in place and never turned back.
I think a lot of folks were in the same boat, but had even less patience for PostgreSQL's difficult installation.
Now, I understand the two are about the same, and both are available with the major Linux distributions. However, now PostgreSQL has to work its way out of the hole its in. Admins like me will be loath to give up the DB we know best in favor of one that burned us, even if it was long ago.
Re:In other news: Vi still no threat to MS Word (Score:2)
That's a good way to go about it - I would guess that it will help if you go to change databases at some point - you get wider compatability.
Same thing for people who basically recreate triggers and stored procs as PHP functions - they can re-use them with most any database, even if the new database supports those features.
Maybe in a few years there will be a shift away from including a lot of features in the db engine and towards small size and speed. I'm not holding my breath though...
Cheers,
Jim
To be fair... (Score:5, Insightful)
...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.)
Postgres already replacing Ora*le (Score:5, Interesting)
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)
Re:Postgres already replacing Ora*le (Score:2)
Have you considered SapDB?
They claim that they have an Oracle 7 compatible mode.
If yes, why have you choosen PostgreSQL?
Sure, in the low end (Score:2, Insightful)
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 [mysql.com]. It already does replication [mysql.com], 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.
Pick A DB That Suits Your Needs (Score:5, Insightful)
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.
The DBASE III of its time? (Score:4, Insightful)
Next in Slashdot (Score:2, Funny)
Linux: A Threat To The Big Operating Systems Vendors ?
and
Apache: A Threat to Commercial HTTP servers ?
Not for a while. (Score:4, Insightful)
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.
Re:Not for a while. (Score:5, Informative)
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.
That's a fairly vague (or rather, inaccurate) term, but if you mean write-ahead logging, then PostgreSQL has done this since version 7.1. Some of the additional enhancements to this feature (such as point in time recovery) are planned for the near future, likely 7.4
This sounds like a complete waste of time, IMHO. Since the database client shouldn't have any idea what the physical representation of the data is, it's not clear to me why this would be an important feature to have. Can you elaborate?
Oh? I haven't heard anything about this...
"Complete" support for SQL92/99 is pretty damn difficult (SQL92 is 650+ pages, SQL99 is 1200+). Nevertheless, PostgreSQL aims to support as much of the standard as possible.
Erm, PostgreSQL uses MVCC, the same concurrency control scheme used by Oracle. It allows for "better than row-level locking" (readers and writers never conflict; one writer only blocks another if they update/delete the same row). In what way is PostgreSQL deficient in this regard?
When exactly does this happen, and what's the exact error message?
Re:Not for a while. (Score:3, Interesting)
This statement indicates a profound ignorance of basic database design. The entire purpose of a relational database is to maintain n-dimensional structures! To put it crudely, each table describes one dimension, and a given database can therefore have as many dimensions as desired (within physical limits).
That's the reason why so many well-trained people spend their time babbling about normalization, first-, second-, third-normal form and so forth. Some people (I've worked with many) think that normalization is a fussy, over-theoretical waste of time, and start throwing out buzzwords, depending upon their age, such as "object-relational", "XML-database" and so forth.
"Right now postges sends a message to the application saying, this is locked retry transaction..."
That's pretty unlikely, given that Postgresql uses multiversion concurrency control - again, put crudely, two different instances, say one a read and one a write, are effectively not even looking at the same DB, but at two independent "virtual" copies of the "real" DB (yes, Postgresql people, I know that's not quite right. That's why I said "crude"). It's possible for a lock conflict to occur, but not likely. And there is a lock resolution mechanism, so it's even more unlikely that an error message will pop up.
Oracle is top heavy (Score:2, Insightful)
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.
MySQL is great... (Score:2, Insightful)
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.
Comparing MySql to Postresql (Score:2, Offtopic)
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.
Should be illegal (Score:2, Funny)
Whether MySQL or PostGres... (Score:3, Insightful)
--LinuxParanoid
Sorta OT question... (Score:3, Interesting)
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.
You've hit the nail on the head (Score:2)
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.
Re:Sorta OT question... (Score:3, Insightful)
For package A, it's not really clear that there is a monetary incentive to fix it. Is the bug likely to generate fewer sales or not? The company is motivated by profit only and has to consider the opportunity cost of fixing the bug -- not the needs of the consumer. Package B (almost) always has motiviated engineers and an incentive (whatever that incentive might be) to maximize the package's utility. Package B exists because this is true.
Re:Sorta OT question... (Score:2)
You have package a (closed product) and package b (open product) that are similar in features, blah blah blah.
Package a and package b have similar bugs. Because Package B is open source, any one of the users experiencing that bug has the ability to fix it. While this may or may not be you, and may or may not be the manufacturer or package b, if it's a pretty widespread bug, it can be fixed by anyone, and is likely to be fixed by someone.
Compare and contrast the recent SSL bug. When discovered, company a (Microsoft in this case)has not yet patched the bug (correct me if that's wrong), whereas the same bug, as found in Konqueror (open source) was patched in 90 minutes.
While you're right that Package B manufacturers may not have as much monetary incentive to fix the bug, any of the users can as well, though typically fixes are provided in a rapid manner for high profile bugs in open source projects. For less common bugs (read: something that only you are experiencing), you might not ever get a fix at all, but then again, that goes for the closed source product as well.
Hope I've helped,
-9mm-
Re:Sorta OT question... (Score:2)
times for mature, popular open source projects like
mysql are typically quite short, so if you do it well
the first time, your patch can be integrated into the
release in short order.
One way of implementing it is to hire a professional
to make it do what you like. In reality, you can
get timely fixes for open source software, but you can't
get timely fixes for popular closed-source software.
This is because your money matters much, much
more, in the development of an open source
project than it does to a very profitable company
which is focussing on other markets at the time.
Especially when said company is large and
beaurocratic, and implements some horrendously
heavy-weight process, like Unified.
Being rich does, however, allow you to be stupid.
I can't argue with that.
Re:Sorta OT question... (Score:2)
I understand what you're saying, thanks.
What about clusters with distributed data? (Score:2)
MySQL is important for society. (Score:2, Insightful)
Standard MySQL disclaimer on slashdot (Score:5, Informative)
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*
Re:Standard MySQL disclaimer on slashdot (Score:3, Interesting)
But in this case forget hotbackups unless your willing to buy the tool for InnoDB (it is NOT open source).
BWP
What MySQL is... (Score:3, Insightful)
GPL doesn't impair consultants? (Score:2)
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.
Haven't we discussed this before? (Score:3, Interesting)
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.
Postgresql great substitute for Oracle Workgroup (Score:2, Interesting)
My poor experiences with a large MySQL db (Score:3, Insightful)
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.
Where are the jobs? (Score:3, Interesting)
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.
Re:Where are the jobs? (Score:3)
Another reason to use something like Oracle....vendor support.
I'm a big fan of open source software solutions, and I'm glad to see MySQL getting some use in the real world, but don't expect the world to drop what it's using and switch just because it's free and cool.
Head-in-the-sand journalism (Score:2, Informative)
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.
Many byers missled by this kind of discussions (Score:5, Insightful)
Success of Open Source (Score:5, Interesting)
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
Re:challenge? (Score:3, Insightful)
If it was on something that needed replication, or writes were the common case I could see a problem. But I doubt either is true in this case. Instead it looks like it's being used for an application tht it will handle well.
Yahoo is only being smart; the high end databases
comsume a lot of resources and shouldn't be used where they aren't needed. It would be foolish to run the entire company on a single vendor's software.
Re:challenge? (Score:5, Interesting)
I disagree, every test I've ever done or read in the last 3 years, postgres is as fast or faster than MySQL (using reasonable sized data not "100 test records"). Do you have a link to a benchmark on recent versions of each (without magic 3rd party patches)?
Replication (Score:2, Informative)
That's a weakness PostgreSQL (which doesn't do any replication at all) should fix in a future release.
Re:challenge? (Score:3, Insightful)
You don't even know what their requirements are! Don't bash something until you see the requirements and environment it will be in. mySQL tends to favor read-intensive activities but is a little weak on write-intensive and transaction stuff.
Perhaps their needs are mostly reading. Maybe some other system dumps the data into mySQL once every midnight, and people query on it all day with little writing.
The point is that you are prematurely dismissing something without looking into specifics.
It is rarely X is always bad and Y is always good. Things have various strong points and weakpoints.
You are acting like a PHB.
Re:challenge? (Score:3, Informative)
Agreed. I use MySQL in a few different production environments, and it works great -- speed is good (even on old, old hardware) and the flexibility is excellent (different formats on a per-table basis). However, I find the SQL implementation somewhat lacking.
UNION [mysql.com] support is a little late -- why did it take until 4.0.0 to implement? Furthermore, the lack of subselects [mysql.com] makes everyday activities such as multi-table UPDATEs [mysql.com] a little arcane. (Read the "it can't be done this way" comments on the bottom to see what I mean. AFAIK the only solution is to create a new table, do an INSERT
MySQL also lacks triggers and views -- views are kind of handy, but if given subselects, can usually be done without. Triggers, though, give one a way to enforce logic (say, relational integrity), which would be very nice to have.
Oh well. I really would like to have my cake, but I guess I'll settle for eating it...
Re:MySQL great for small databases (Score:2)
Are you spreading mysql-supporting FUD ?
Here is how to install PostgreSQL on Windows:
http://www.ca.postgresql.org/docs/faq-mswin.htm
Re:mysql is a threat to the commerical db vendors (Score:3, Interesting)
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.