Slashdot Mirror
Why Not MySQL?
Deepak Jagannath wrote to us with a piece that talks about why a Web site shouldn't use MySQL for critical RDBMS. Do people agree or disagree?
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Well, I certainly learned something from the article;
The company I work for just underwent a major expansion. My boss wants to amalgamate several (somewhat) related databases into one (most of the DB's have redundant information) Until now, it was no big deal to have two (or three) people in different departments entering the records into separate peices of software.
I felt that a SQL server would fit the bill - it's an industry standard, and lots of software will operate as a front-end (it's even possible to use a web client as a front-end, which is important, because some of the data will end up on our web page.)
Until now, my choice had been MySQL - I know lots of web sites that use it, so it must be good, right?
This is the first time that I've found information that tells me exactly what the drawbacks are - and it seems that MySQL (while fine for some applications) would be ill-suited for our application (record-locking is a must - table locking isn't good enough for us.)
So yes, they are saying something new (at least to me.)
The article seems to state very clearly that the reason to not use MySQL has to do with ACID. But it also states that this doesn't preclude it from use, only that you should consider the value of transactions, etc when choosing a database. If you read the follow on comments from the article you will see that he recommends two open source products PostgreSQL and Interbase. I think he did a slight disservice to himself by using Oracle as an example instead of one of the open source products. But I wonder about his claims that MySQL misrepresents itself on it's website and in documentation. That is where the real debate should focus. Is MySQL misrepresenting itself?
It's simply an answer to their most FAQ:
"Why don't you guys implement ACS on MySQL instead of PostgreSQL?"
I think they accomplished that definitively.
I'm sure if they wanted to be polite, they would have said "Well, there certainly are LOTS of nice things you can do with MySQL..", but that's NOT what they're trying to accomplish.
The idea behind a microkernel is that you implement as little as possible in the kernel and do everything else in userspace servers. So the filesystem, the security model, the tcp/ip stack: it's all servers, and they deal with the kernel by passing messages. But that means at the very least twice as many syscalls (or 4x if it's bad) as a monolithic kernel would take. Not cool.
A server doesn't need intensive graphics, but it does need a fast tcp/ip stack and a good filesystem. Doing these in a microkernel is still going to be slow. Implementing them efficiently (as in reducing syscalls, not to say that everything needs to be in the kernel) would mean putting them into the kernel, at which point you don't really have a microkernel anymore.
Here's how this issue can come up: I worked at a company who needed a replacement for FileMaker Pro. They used it for their customer database of about 20,000 customer records and 40,000 tech support records. The company hired from inside itself based on the wrong qualifications: skills in Perl and HTML, not SQL. They bought Oracle, ran it on an expensive high-MHz machine, and it was an intranet webserver for their new customer database. We didn't use a single transaction. Not one stored procedure. The only triggers were trying to emulate "auto_increment" (we were appalled that Oracle didn't have an auto_increment feature for a key column). Even that didn't work properly. No relationships were stored or specified. It was all done from client side (perl scripts). In essense, cheap managers hired amature database programmers to save on salary and wound up with an expensive, bunglescrewed program. It worked though, still works, but it might as well have been done with MySQL (or a kindred program). The support level agreement with Oracle didn't help much since the database programmers were inexperienced. I should know, I was one of them
and is being cleaned up and readied for cvs use. It has all the good aspects, yes, but why was is listed with the pay solutions in you post?
While it is true that microkernels have performance problems in some circumstances, they have superior performance in others. Massively parallel systems tend to use message-based OS, although there is a penalty for use with one processor. But it really works well as you add more processors. The Tandem Guardian OS gets 99+% of for each added processor, well over 100 processors. Try that with a symmetric multi-processing non-microkernel OS.
The message passing, which was unnecessary for a single CPU, suddenly becomes much more efficient in a parallel system. It also helps out fault tolerance (which is why Tandem developed it in the first place).
In addition to single processor efficiency, there other disadvantages with a message-based systems (which probably contributes to the relative scarcity of knowledge about Tandem systems). Just doing a straight port of an application used to lead to poor performance because of different performance tradeoffs (cheap operations on UNIX were expensive on Guardian, and vice versa). Tandem eventually got past that by designing more sophisticated middle-ware.
Look, we're all happy you got into MIT, its a pretty impressive feat for someone like you. But please don't think because you took one undergraduate systems class that you know jack shit about deploying OSes in the real world.
The fact that NT is a microkernel design hardly makes it better than linux (even ignoring the fact that they compromised their design by moving more and more things into the microkernel to improve performance. Looks like microkernels might not be such a great idea after all). Linux runs on 10 or 20 different platforms, including non-mainstream ports. NT5 runs on ONE. Excellent way to make your point, that.
A well designed modular kernel gets the organizational benifits of a microkernel design, without the speed problems. Your argument that Linux is poorly designed seems to be entirely based on the fact that it is not a microkernel. Please take a look at the actual source code, and preferably some real world experience (although that is no doubt 3 years away for you) before you make ridiculous comments like that.
There is one way to read your message: ... I am an IT manager .. Have installed linux from floppies"
... now I became an IT manager and i make $10K ... I have big bollocks"
" Bollocks
This would not proove however that 99% of IT managers are not sheep (and the initial poster wasn't talking about exceptions). Its a NULL comment.
There is the other way:
" I used to install linux from floppies
which contains no ambiguities and prooves what the initial poster said true.
Both ways the initial post is not dropped to invalidness.
Flaming for my spelling is most welcome.
The prices on Oracle's web page list:
Oracle 8i, perpetual license (site license): $750
That doesn't seem like so much cash if the license lets you install it on any machine in your organization.
Anyway, what exactly is the difference between Oracle 8 and 8i?
It certainly depends a lot of the circumstances. I found the article, though accurate factual, to be silly as a general case.
We use MySQL for several client sites, and it is an excellent tool. It's fast, it's cheap, and it supports the basic attributes of a SQL database. We don't need or use transactions on those sites! Wow, what a concept, you can program an application that works around this limitation!
The ACID test is a nice idea. I don't believe failure to meet it is something that rules out a tool. It just means I would not expect the system to be a transaction-dependant system. It would have to be mostly read-only, and the writes to it would have to be structured atomically.
We found Postgres to be OK, but somewhat "troublesome". A lot of strange errors (which I don't think we *ever* debugged), so unfortunately it's MySQL or Oracle for us these days.
Oh, and need I say MS SQL sucks? Don't get me started on how buggy that thing is.
Sorry for the Anon post but I'm at the office.
We currently use MySQL on easy.to and server 2 - 3 Million, yes Million, requests per day. The MySQL server also serves as the User database for the e-mail server.
There are very few updates to the database itself, and in the 2 years we have been running it we have only had one instance where it failed, and even then we only lost a few Last_Hit_Times as we log all transactions.
If we were to implement something that required more than a few updates per minute, we would look into PostgresSQL or Sybase but as it stands now MySQL is the hands down winner.
One instance where MySQL looses badly to Postgress is in transactions per second. On a decent Postgress machine Postgress can do hundreds of TPS, while I've been trying to get MySQL to do just one transaction for the last two years :)
As a developer who has worked with both, there are several differences twixt the two. Support for LOBs is much better in 8.1.5; with certain optional models you can create full-text databases, and search them with an extended form of SQL; significantly improved high availability features; and more. I read somewhere that Oracle was considering calling 8.1 a version 9.0, but didn't because IT managers tend to be reluctant to upgrade to a major revision.
There's a chart on the MySQL site that compares MySQL against Oracle 8.0.5; if the comparison was between MySQL and 8.1.5 (or the most current version, 8.1.6), there would be almost no grey dots (indicating a feature doesn't exist;) there would be some more check marks (indicating the feature exists in some non-standard way;) and a whole bunch more stars (meaning the feature is fully supported.) If they went the extra step of adding features that are in Oracle but not in MySQL (like full text indexing and searching), there would be a lot of grey dots on the MySql side.
8i is a suite of products built on top of the "regular" Oracle database, most recently 8.1.5 or 8.1.6.
As other posters have mentioned, 8i might offer other additional features, but the major feature as I see it is the Aurora Virtual Machine, a Java VM embedded in process in the database. In particular, 8i provides an Enterprise JavaBeans container. (Sounds cool, but Oracle's EJB implementation is pretty weak, trust me, stay away from it for now.) 8i also provides the capablity of creating Java Stored Procedures--stored procedures implemented in Java rather than PL/SQL, which offers a lot more power and flexiblity.
By the way, for everyone on /. who's always knocking Java, you'll note that it is the sandboxed architecture of the Java VM that makes it possible for Oracle to build a VM right into the database without fear of corruption. You can't do this in C (or Perl), at least not without adding a great deal of custom "sandboxing" (security, and more) code.
Oh, I'm not advocating the use of MySQL at all, nor excusing it. I'm saying that for people who want to hack a database to hold say... lyrics, or the tour dates for their band, it works. It's not an RDBMS, and it's not something I'd trust anything of remote importance to me.
Remember, most websites suck. This includes database backed sites, and as far as I can tell, that's the most common use of MySQL. I've never seen anybody running anything of importance off a MySQL db.
----------------------------
Nobody would care if there was a little corruption, and realistically it wouldn't matter.
As for my argument that most people don't know how Oracle works, perhaps I wasn't clear enough. I'm saying that most people a) can't afford Oracle, and b) if they could, wouldn't know how to use it. I'm not talking about real companies. At work, I use Solid and Oracle, depending on the task. They work for their respective purposes. I'm not saying these people who like MySQL for odd reasons are *RIGHT*. I'm trying to explain the rationale. You're right, good developers *do* continue learning forever. But be honest and think about every 'developer' you've ever met. Were a majority of them good? Didn't think so.
Again, I repeat myself... I don't agree with the majority opinion, but I do believe I can explain it.
----------------------------
The fact is that for the majority of database backed sites, cost is far more important than functionality when it comes to databases. MySQL is cheap in almost every sense of the word. It costs nothing to use, administration is incredibly simple, and there's nothing particularly confusing about it.
A lot of people, even given the funds to purchase a DB like Oracle, don't know how it works. Thus MySQL works well enough for them. They don't care about the lack of stored procedures because they've never used them before. They don't care about the high-load write performance problems because they won't have load.
----------------------------
In this debate over which database is best, i find it shocking, that people don't got a clue, as to what this discussion is about.
People keep saying "xxx is better than yyy", and the hang on to that statement, more than they would hang on to there life, in the worst imaginable situation.
I have said it before, and i'll say it again. It's all about CHOICE.
That we can CHOOSE to use xxx, or yyy or something else.
It's about CHOOSING the right tool, for the job.
It's saying that MySQL is a good solution, to many of the jobs, but it's also saying that Oracle, will be betetr for SOME jobs, while Sybase, will be better for others, and again MySQL will be better for some problems etc.
In our world, i would have thought that people would have understodd, that xx is betetr than yy, dosn't exist.
It's just a question about choosing the right tool for the job.
You wouldn't use a screwdriver, to dig a whole in you yard, would you?
And, car x isn't better than car y. It's a matter of what needs the car is to cover.
A Ferari isn't better than a Ford. Because it's 2 diferent cars, covering 2 different needs.
With that said, i belive the author of the "article" is far off, and dosn't quite know what he is talking about.
He comes up, with some VERY far out examples, as to why different features are demanded. Also he talks, like it is the job of the RDBMS, to omplement security measures to prevent the whole serevr, form NOT going down, which just shows how little the author knows about the topic.
It isn't the job of a RDBMS, to give DISK level security, thats what you would use RAID systems for.
Also, he clearly dosn't understand what needs he have.
As far as i have read, openACS, is a sort of messagebort, which in NO situations, would require Transactions, or high disk security.
He could be using MySQL, just fine. He barks at MySQL, for not implementing different security measures, while those measures, are to be covered by other products hardware/software.
I belive that anybody with just the smallest amount of knowledge in servers, will agree with me, when i say that a server, should in 99% of the cases, use some form of RAID. So if he's running a Dual 500 Mhz server, with Mirrored(or DUAL Mirror) RAID 1 disk system, then he can easily spill coffee in one of the harddrives, without causing the server to go down.
etc. I don't wanna waste more time, on this subject, because it's clear that the author, don't have the required knowledge, to justify he's barking at MySQL.
Open-source...Since when does openspurce, prevent you from using the sourcecode in commercial things? The website clearly states, that the sourcecode is ONLY available if it is for educational or non-commercial research.
Don't go blaming this guy's ignorance on slashdot, there's nothing special about this forum that gave this guy any standing in the world of technical competence. If he were one of the slashdot crew (Taco, Hemos, etc) then you'd be right but he's just a guy like you and me. The value of this place is that everybody can have a voice. If he's wrong, I expect people to shoot him down just as happened. Not everybody instantly believes something just because somebody on slashdot said it, this is a meritocracy and you have to prove yourself.
-E
Send mail here if you want to reach me.
Borland/Inprise said it was mostly-SQL92 compliant.
<p>Interbase also used a postgres-like server model, with many server processes communicating via IPC. They recently switched to the single threaded process model similar to Sybase (you can configure your Sybase server to use only one process and still get reasonable performance).</p>
<p>Right now, there are lots of free DBMSes to choose from, but none can serve all needs.</p>
The problem is that many open-source developers choose MySQL. Linux administrators that hate it are constantly forced to install it to obtain required functionality.
Also notice that MySQL hasn't made it into Red Hat (or Caldera?). They also don't use shared libraries, their redistribution license isn't GPL or BSD like everybody else, and they just do things differently.
You have a situation where those that hate it are forced to hate it more, and those who love it grow more infatuated by the moment.
Not good for the community.
What do I hate about MySQL? Let me count the ways:
Basically, if you want a SQL interface to Windows Notepad, MySQL is for you.
From a functionality standpoint, Postgres has fantastic integration with Red Hat at the moment if you want an open-source database. If you need scalability, use the free Sybase and upgrade to the commercial version when you have the need and the money.
When you need to use a subquery, you need to use a subquery. If they aren't available, you've got to take several steps to emulate them.
Just imagine if someone built a Linux distribution like MySQL built their database. "fsck is too hard to implement, so we are leaving it out. We didn't have time to implement all the options to ls. Shared libraries don't perform well, so we don't use them, and we don't like glibc.
Oh, wait, that's Slackware!
PostgreSQL is under an Open Source license too. So the cost is the same. Now why would I then choose MySQL over PostgreSQL?
I think it's more a case of people not yet clue-ing up to the fact that PostgreSQL is actually the best free DB at the moment.
--
Simon
Which is in fact exactly the service we received. I don't expect, nor am I surprised, when I contact an author of an open source package about a bug to receive either no response or a response several weeks later. In a production environment that would be suicide.
So in answer to your question, people use Harlequin instead of gs because they are buying a service, not a program, and that service includes immediate problem resolution, and people that will speak to them there and now, not when they have the time to get around to the problem. It's not significantly faster (when it works) but it's significantly faster (when it doesn't work).
People will pay a lot for absence of grief. We did.
MySQL seems to be pretty much the default choice for people (who aren't companies) building a database-driven website. Can someone explain to me why? Unlike Postgres, it isn't a real RDBMS as the article explains, it isn't that much faster and sometimes it's slower, and it's not Open Source. What's behind its popularity?
I'm not trying to be provocative; I really don't know the answer!
--
Xenu loves you!
OK...I knew someone was going to say this, but it is unfair.
Usually, when slashdot is down, it appears to be having network problems, or the web server isn't responding. How often do you see SQL errors?
MySQL does the job, if the job is something MySQL is suited to. I use it for simple database applications, but wouldn't use it to store customer info.
--
The transaction and journaling stuff is being worked on now because we need it for Slashdot and Freshmeat, as well as some other stuff. press release here
MySQL is really fast, but it's not safe enough for everyone's data. If you're looking for a database with all the bells and whistles, and with a much nicer license than MySQL, look at PostgreSQL. Release candidates for version 7.0 are out and in testing, commercial support is offered by PostgreSQL Inc., PostgreSQL documentation is very extensive, and the community support (mailing lists, usenet) is very active. A very quick rundown of some of the features of PostgreSQL is available here (of course there's much more to a database engine than will fit in an HTML table).
--
Isn't part of the problem that Oracle, DB/2, Interbase, etc. actually work pretty good for people? By which I mean, if you have the money, there is NO reason to choose MySQL over them. This is not Apache vs. buggy bloated IIS or Linux vs. buggy bloated Win2000. This is like a Dodge Neon vs. a Miata. Most of the other open source products can say "we're cheap AND we're better". But not MySQL.
Another point is that an RDBMS is not like a webserver or an OS. You can't just tack extra feature onto the side of it to make it better/more competitive. Implementing something like rollbacks or transactions or subqueries (all important things lacking in MySQL) is going to touch every part of the code. And I don't think those kind of changes get done very well in a Bazaar environment.
Linux *can* work with a microkernel.
:)
It's faster the way it is now.
No one wants to change it, and its already on a *lot* of platforms, with special ports for smaller devices.
The last thing we need is a "Linux/NetBSD Platform Pissing War". I tend to only use a few hardware platforms, and they're all supported on both platforms, to my knowledge.
Mentioning NT as an example of good design is amusing. A Microkernel and a castrated version of VMS makes a portable operating system that no sane person would want to code for. Oh well...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Pardon me, are you referring to what I wrote about Word? Hey, I only tried to avoid *two* style flaws on that one...
...and I don't see a flamewar yet, perhaps because my point was, most software can't be all things to all people. Any time there is an implementation choice, someone won't like it. And if you add a checkbox to switch between them, someone won't like it because there are too many checkboxes. And if you arrange them on separate tabs, some people will find it too confusing. And if you...
(also, if you check, my post was moderated as "Funny", amongst other things. If I'm ever being *entirely* serious, I might put a disclaimer at the top, saying so...)
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Wow, reasons why we don't like MySQL here:
- It isn't really Open Source, it's only free
- They don't know what they're talking about on the obscure technical issues that we like.
- Most people could use it just fine, but that's not the point!
- Okay, sure, its fast, but our database is safer!
- Why does everyone have to use MySQL anyhow, hmm?
This sounds like a case of sour grapes, pure and simple. One database is not going to be for everyone. Oracle is expensive, MySQL isn't robust enough for some people, and PostGreSQL is slow (compared to MySQL, for some common operations).
So, my advice. If money is tight, don't use Oracle. If data integrity is your utmost concern, don't use MySQL. If speed is an issue for your little database on your overworked computer, don't use PostGreSQL.
...And if you live in the real world, don't whine about how software application X is better than popular software application Y for reasons that many people don't care about, because you will be flamed to a crisp, especially on Slashdot. Just admit that software X has a place in the world, and some people, maybe even many people might want to use it, but they are other people, doing other things.
Example:
Microsoft Word is a popular word processor. But it is not robust enough for some people's needs. 95% of people might be able to do their job just fine having it crash and autorecover their documents, but for the 5% who are working on mission-critical data, or get their documents eaten, this isn't good enough. They would rather waste their time working on free solutions with bad Word DOC File Import/Export routines. For those who care about proper formatting and ease of use, however, Word's stranglehold on the market makes it a more useful product for now.
Notice that I didn't say "Word has no place in the market", or even argue that "Microsoft didn't know what it was doing when they made Word!", but rather showed some strengths and weaknesses, and let you decide which category applies...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
No one ever said that MySQL was supposed to be a high-end RDBMS. It does what it does, and if that suits your needs, then so be it. If you need all the things the author whines about, then go buy yourself Oracle or Informix or whatever.
MySQL does everything *I* need quite well and I've never had any issues with it. Yeah, sure - transactions and stored procedures would be nice. But I know enough that if I needed those features, that I wouldn't be using MySQL...
That's like saying Word doesn't do spreadsheets. Use the right tool for the job.
You can download most of the Oracle products for personal/development work too...
If you want to be sure that you'll get an answer to your support request, you pay for it, just like with a proprietary app.
For mySQL, from the source:
https://www.mysql.com/license.htmy
Or, from a consultant:
http://mysql.com/consultants_search.htmy
And, similarly, for PostgreSQL:
http://www.pgsql.com/support.html
Of course, expecting good results on any business-critical system without a backup & recovery plan or competent staff is a bit naive, anyway.
The only real ommission in this article was that they didn't mention that MySQL is proprietary software -- it is NOT Free software ("Open Source" tm) by any stretch of the imagination. I don't know how many responses I've seen to the recent ZDNet article which cite MySQL as an example of "Open Source". These people should get their facts straight before they start making public statements on behalf of the Free software community.
* Actually, you can now do this with Perl so MySQL has become even more irrelevant.
If what you want is raw, fast storage, use a filesystem. If you want to share it among multiple boxes, use NFS. If you want simple reliability against simplistic failure, use mirroring. Want a SQL interface to it all? Use MySQL.
The main reason people use MySQL is that its the quickest, easiest way of making your data SQL accessible.
People rave about the performance, but most of the time the performance is only useful to excuse quick and dirty programming, poor db design or poor system architecture. The real benefit is that it stores your data somewhere where you can import, export, and query it easily. That's all alot of people need, certainly, it's all I need for 90% of what I do on the web.
-----
Bollocks.
You appear not to work in the very large e-commerce business. You assume that people that do are sheep because, well, _you_ can do your stuff fine with other products. You assume that because people do not buy the functionally best product they buy it because they are sheep.
I do not work designing very large e-commerce sites. I do work in a position where I see the RFPs and architecture requirements for these sites, and I have worked with most of the smaller products such as MySQL, PostgreSQL and so on.
Believe me, these tools are not even close to cutting it. Sure, many of those Oracle shops could (technically) use Sybase, MS-SQL, Informix and so on, but support contracts required for these sites are very demanding - engineers on site within hours, *CODE FIXED* within hours. Yes, Oracle will recompile Oracle and ship you a fixed binary within 24hours of a bug report - you just have to pay...
And yes, I am an IT manager, and yes I can write programs and put machines together, and yes I have installed Linux from floppies - does that make me not a sheep?
The 'no-one was ever fired for...' problem is alive and well, but it is not the explanation for every instance of a (oh horror) closed source commercial product dominating a nich market. Think about it.
-----
What are you smoking?
Postgres has all the regular GRANT options any RDBMS has, in addition to its Host Based Authentication in pg_hba.conf which allows you to trust, deny, ident, use kerberos or a regular password for any database it's in charge of!
Nor are you if you are using Oracle to learn. :-)
I use Postgres. I'm not claiming to learn SQL through it. I don't think any RDBMS actually uses 100% SQL '92. It's kinda like ANSI C. Yeah they'll take the statements, though grudgingly so. :-)
That's easy: if a Slashdot comment goes missing -- who gives a toss?
If a customer order goes missing -- well, it could be an important one, it could be money in the bank, lost.
Slashdot needs the speed, but not the performance; critical applications need the reliability, and are prepared to sacrifice performance. Easy.
--
You didn't know? Dot Slash is the leader of Hell's Grannies.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Look on MySQL's site and you will see that they actually intend to not support transactions because of performance issues.
This is probably why MySQL is used for websites whereas Oracle is used by BIG companies to handle their B2B operations.
And IMHO it is far more difficult to write an operating system than to write a RDBMS, and I don't see why modularity is not possible for a RDBMS (I work for eXcelon, leader in Object databases)...
Juju
Black holes occur when God divides by zero.
Almost the whole article can be summed up in one sentence:
"Because MySQL doesn't have transactions or journalling"
The rest of it is just the author making the assumption that *everyone* needs these things. I don't think that's particularly true. Decide for yourself.
There's a bit at the end about "oh yeah, and no subqueries, stored procedures, triggers, foreign key constraints, and only table locking" These are the things I'd like to see discussed myself. They seem like reasonable features that could be added without changing the purpose of MySQL: to be blindingly fast on a lot of data.
MySQL is like driving your car at 150MPH. Yeah, it goes fast, but accident protection is small. Sometimes you need that, though.
Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
Just because it doesn't have a 'vendor' doesn't mean its not supported. There are people who are just as knowledgeable about MySQL as others are about MS SQL Server or Oracle. Get your %99.999999 uptime contracts from them.
Major industry support? Like thousands of sites using it? I don't think that it can realistically be argued that MySQL is anything but fast and stable.
The big question is: Do you need transactions? If you do (and granted, most systems that involve money are going to want them) then MySQL won't work for you. If you don't, it will be fast, flexible, and free.
Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
Before everyone starts attacking MySQL, and citing Oracle's technical merits, we should probably note one thing. First and foremost, Oracle has hideously high pricing. Currently, my company is looking into Oracle licenses to replace our PostgreSQL setup and the nice fellow at Oracle tells me about a "great deal" in which I'll be paying per clock cycle. I.e. 500mhz means 500 * (rate). This is since of course, web sites only use one user to access the database, making licensing fairly cheap. PostgreSQL on the other hand is probably the most "free" of the major RDBMS, provides next to all of Oracle's features, plus some unique features like 'snapshoting' as opposed to row or table locking, sequences and more.
All in all PostgreSQL, speed considerations aside, is a worthy option for people considering Oracle. The only reason most people consider Oracle is because of it's reputation. People hear "Oracle" and they believe you're taking your data seriously.
For speed, MySQL's only advantage is SELECT speed, as INSERT's are quite slow, in comparison. If you're running a website that's fairly non-interactive (like mine : Punknews.org) You'll be happier with MySQL for speed, but if you're dealing with a lot of user-inputted Data, PostgreSQL will make up for the SELECT speed with a much faster, multi-threaded and non-table locking INSERT and UPDATE.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
I've recently had the task of creating an in-house database driven app. By splitting it into a three tier system with a layer between the DBM (initially MySQL) and the web code, I have the option of swapping out SQL servers with only a fraction of the effort of rewriting the whole system for a new database.
It may not run as blazing fast as an app tied directly to the DBM, but I consider not being tied to a specific DBM to be a Very Good Thing. Does anyone else think this is a good idea?
Hell yes!
I'm in the process of building a data-collection and reporting application -- with database independence a requirement. MySQL fit the bill for the initial implementation for several reasons:
While I'd love to have transactions and subqueries available to me, in the final analysis, my application doesn't need them (as far as most of my processes are concerned, there's no such thing as an RDBMS -- most processes are talking CORBA to a database frontend, and the frontend handles queuing DBMS requests itself). Why? Because neither SQL nor ODBC/JDBC are truly database independent.
In the long run, I'll be supporting Oracle, DB2, even MS SQL Server ... but for now MySQL is good enough.
We call it art because we have names for the things we understand.
field=> \h alter table
Command: ALTER TABLE
Description: Modifies table properties
Syntax:
ALTER TABLE table [ * ]
ADD [ COLUMN ] column type
ALTER TABLE table [ * ]
ALTER [ COLUMN ] column { SET DEFAULT value | DROP DEFAULT }
ALTER TABLE table [ * ]
RENAME [ COLUMN ] column TO newcolumn
ALTER TABLE table
RENAME TO newtable
Seriously, anyone who is basing their PostgreSQL experience on anything older than 6.5.3 needs to run, not walk, to their nearest ftp client and download the newest 7.0 release candidate.
PostgreSQL flat rocks, and it gets better every day. It may not beat MySQL for raw speed on simple selects, but it has sped up significantly in the latest releases, and it has a whole raft of features that MySQL will probably _never_ have.
Plus, PostgreSQL is released under a BSD style license. To those of us who value libertad that's quite valuable.
Yes, there's a good reason for it -- virtually all IT managers are mindless sheep. It's the old "no one was ever fired for buying IBM/Microsoft/Oracle" principle. Most of them will never have evaluated all their options. They will instead have taken the attitude "I know Oracle can do the job, so we'll use that". There may well be other that can do the job just as well, but don't expect the majority of companies to even look at them.
I'm not trying to put Oracle down here. I think they have a great product (although I've always preferred Informix), but the fact that everyone else uses it is no reason to do so yourself. That's the reasoning that ended up in widespread use of NT for tasks it's simply not suited for. Use the right tool for the job. If you need a fast database that works well for 95% of applications, use MySQL. If you need guaranteed data integrity, then use Oracle / Informix / Sybase / PostgreSQL whatever.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Why not? If you have a Porsche, it's a perfectly valid tool for the job. A friend of mine gets some very odd looks because his vastly performance enhanced Lancia Montecarlo has a towball on the back. The point here is that if you don't already own a car, a Porsche shouldn't be your first choice when looking to buy something to tow a caravan. If you already have one, though, sticking a towball on the back is by far the easiest solution.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
This sounds like an application that could be better handled by LDAP instead of an SQL database.
I have a suspicion that the people who safely use MySQL would be better off using LDAP, because their applications are heavily oriented towards reads, and could benefit from replication. For things like a shopping cart, a hybrid solution using LDAP for the catalog and an RDBMS for storing orders seems best.
Wil
--
LNXS:
Wil
wiki
Although Ben Adida is correct in every fact about MySQL (lack of subqueries, poor ACID support, no foreign keys), his conclusion is a bit overstated.
The full RDBMS model is not needed by everyone. This is clearly the case for Slashdot and many other sites and companies that I know use MySQL. If you need transaction support, please don't be bitter than MySQL doesn't support it. It doesn't claim to.
Yes the speed of MySQL is nice, but the SQL interface is the selling point for me. I can model and access data more consistently from project to project because I don't have to worry about how low level issues (directory structures, multiple users, etc).
Of course, you miss the fact that you can already know SQL (and know it quite "properly", thank you, not that I know what in the world you mean by that) and still think MySQL is quite a nice tool.
It's an RDBMS without a lot of overhead, which lets me deploy a site and leave it open to an "Oracle upgrade" at a later point.
To me, the important thing is, the system uses a RDBMS that I can access via Perl DBI and Java JDBC. Given that, porting the system should be very simple from the perspective of the application (little to no code changes).
It's a strange world -- let's keep it that way
Not anymore, AFAIK:
ALTER TABLE blah ADD COLUMN blerh char(16);
Or did you mean something completely different?
(Another thing, of course, is deleting columns from existing tables...)
No, the MySQL docs state that the lack of things like transactions and triggers makes MySQL around 3 or 4 times faster, even when you don't use those features.
So adding features is not always a win, and that's why you got alternatives when implementing databases:
- Speed daemon, but lacking advanced features (MySQL);
- [all intermediate solutions];
- Feature rich, but slow for simple queries (Oracle for example).
From the user point of vue, choose the database that suit your needs.And be sure of what you need, MySQL docs gives some real life examples where you can avoid using transactions by using auto_increment fields, conditional updates, etc.
I could go on and on about both sides here, but let it suffice to say that there are no absolutes in software, only tradeoffs. MySQL lacks certain features of other DBMS's, but in many cases it may be sufficient to implement these features, such as transactions, rollbacks, etc., in application software rather than spending 100k/yr. on Oracle. However, beyond a certain point, the cost of implementing and maintaining these safeguards may exceed the cost of a DBMS that already includes them.
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
Are we commenting on a page that has its own built in comment system?
** Martin
While "the best tool for the job is the one that works" is a good thing to work by, remember one little thing. A tool may seem like it's working until one critical point of failure. Kind of like using a 7/16 inch socket on an 11mm nut. Yea, it'll work most of the time, until you hit that one soft nut that you end up stripping. Then you sit there all pissed off that you didn't use the 11mm like you should have.
And this is exactly what the article was about. Being sure to evaluate the tools you use properly and safegaurding your valuable critical data as best you possibly can!
** Martin
I agree that the lack of transaction support is a great weakness with MySQL, but there are several other things that are important for programming convenience.
If you want to create and maintain databases, you'll certainly appreciate a few things that I think are annoying with MySQL (for a more complete list, I suggest having a look at their own compatibility documentation):
The first one is the one I've found most annoying. It's a very nice thing to have when putting stuff in temporary tables. I recall a different version of their document, where the gist of their argument against SELECT INTO basically was that it wasn't standard SQL. Okay, fine.
The second is also a bugger, and that
doesn't really help in those cases you can't.
Case sensitive string matching is faster than case insensitive string matching, so I'm actually surprised that they didn't make that the constraint instead of the opposite. I'd also like to be able to do this without storing stuff as "BINARY".
As an argument against '--' style comments without requiring a following space, the MySQL team claims that
The reason that is a problem is of course that one can say something like !payment! and have the value inserted instead of that (meaning: 1-!payment! will become 1--1 if !payment! evaluates to -1). This could be solved if comments were interpreted before other things, like they probably should.
As for stored procedures and triggers, I just find them practical.
I'm satisfied with one thing, at least, and that's the tone of the documentation, which has been improved a bit since the last time I looked. It's slightly less arrogant.
Yet I won't even consider recommending the use of MySQL to anyone who wants a database for any serious work, for the reasons mentioned in the article, the reasons mentioned above, and the incompatibilities not mentioned here, but in their own documentation.
Details, please. The fact that there are a lot of programmers interested in working on the kernel means that it's possible to experiment with major changes in private side-branches to improve performance and functionality and to fold in those that work, rather than avoiding them for fear of breaking things. Just because earlier versions were sub-optimal and can be improved through major changes, doesn't mean that those earlier versions were bad.
"Hobbyists"? Please take time to learn how Linux development really works.
Linus explicitly rejected micro-kernels as beign inefficient - which they are. The design of NT pays lip-service to the micro-kernel concept, but it really isn't a micro-kernel OS. Even the GDI is part of the kernel since NT 4.0.
Oh, I agree. But why drag Linux into this?
I'm guilty of having developped a complex website with MySQL, and to have been above its limits. Now I'm in some trouble. That being said ...
MySQL is indeed a perfect database for 90% of the sites out there. And in the 10% of the rest, it's the perfect tool for 50% of the job.
Example? Do you need ACID to store user comments? I don't think so. Do you need Oracle to store logs that you wan't to query and agglomerate quickly? Certainly not. Do you need transactions to store access control list for HTTP authentification? Hardly ever! Would you want to spend $20k on a quad-proc, 512MB, raid enabled server just to be able to conveniently store dozens of thousands of user cookies? You must be joking.
All this is what MySQL does best and that other database will do poorly. I don't see, in these really life, heavily tested cases, where it fails in any way to fulfill the need.
HTH.
This will not work, obviously, for applications such as financials, where you need to query and update very often. But that's really not MySQL's target.
Case sensitive string matching is faster than case insensitive string matching, so I'm actually surprised that they didn't make that the constraint instead of the opposite.
No it's not: it's just a matter of a different hash function (for hash tables) or comparison (for trees), and an added 0.000001% per row when there is no index. It's really lost in the noise, anyway.
Same here. A long time ago, Monty logged into my machine and tracked the crash up to a weird unofficial patch I had applied to the Linux kernel ... duh!!! I did'nt even remember it was there in the first place ... I feel very silly in retrospect.
Yeah, but MySQL does client/server, Berkely DB does not.
Neither MySQL nor Berkeley DB is a substitute for a real SQL database. Berkeley DB at least has a solid foundation that could be extended to become a full SQL database, should someone write the necessary code. MySQL, on the other hand, has fundamental deficiencies that are hard to correct.
I fail to see how Berkeley DB is any better than MySQL. MySQL's ISAM (and new MyISAM) storage structure is very well tested and very reliable - it's been in development for almost 20 years now! MySQL weakness is exclusively in its SQL frontend. It seems to be rather straightforward to extend, and it's programmed rather cleanly from what I've seen of the code (yes, I've looked at it). It also uses standard Posix threads, which is why it is very portable.
I realize it's fashionable to dump on proprietary software, but at least get it right when you do.
What hasn't yet been widely discussed is something that I would have expected the Slashdot community to care deeply about: the license. It's not open source. It's not even close. It's neither free as in beer, nor as in speech. Why does mySQL get a pass on this?
I used it only briefly, and then moved to postgresql.
Part of it was the source code licensing issue, since postgres is free software (bsd license) and mysql isn't.
The other part is that while I was learning RDBMS's, I asked around about a couple of different ones, (I knew I wasn't using oracle both for the license and cost issues), and everybody seemed to have the same opinion - mysql is really fast, but it can't do this, can't do this, etc. etc. etc. and proceeded to spit out a long list of things that you had to work around with mysql in order to get the job done.
On the other hand, I've been using postgres quite happily for quite some time. For my applications, there isn't a serious speed difference between mysql and postgres, (in fact sometimes I think there is no difference) and it lets me march to the beat of my own drummer rather than building sometimes ugly constructs to get around the lack of features in mysql.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
Actually PostgreSQL 7.0 (of which atleast Release Candidate 2 is out) supports foreign keys.. Of course, earlier it was possible to emulate them with triggers, which you cannot do with mySQL.
Now, as you've been answered, that isn't a problem. A real problem is that you cannot delete a column from a table.. Who designs the tables with the 'right' technique (plannin etc) anyway, it's more fun to do it in command line :).
You've seen wrong. There are users (and groups) in Postgres, and you need to specifically grant access to the tables you create. However, I've not been able to limit the capability of creating new databases.. Kinda sucks, one can't give anonymous access to the table.
Just look at /. . You've seen it, you know what I mean. I mean, there cannot be any other explanation for the seemingly random moderations, except database corruption. Why else would a comment presenting misinformation or even lies be operated up, and a witful comment down (Camel rules)?
I've had problems with oracle crashing and tried to use the oracle support, for which we pay about $10,000/year.
I ended spending about three hours on the phone, in between waiting on hold and talking to the clueless tech support person. After three weeks of calling and pestering them to fix the problem, they finally came back with a work around that required me to disable a small but significant piece of functionality of the DB to stop it from crashing.
In contrast, I've had problems with mysql three times. Each time ended up being triggered by bad SQL code on my part. Regardless, I always had a response within half a day and a patch and an explanation within two days (usually within a day!). I repeat: I invariably had a patch to address my specific problem within two days of reporting it. And I don't pay the mysql folks squat.
I'll take the mysql support any day.
Just remember. All software sucks; just some sucks more than others.
--
The $750 license fee you saw, is for 1 named user inside your organization. This is definately not a site license. This does NOT cover internet use. If you have 100 employees using the application, the fee is $75,000. For an internet application, for Intel, the price is $100 X sum of CPU speeds. I.E. For a 2 processor, 500mhz system, the price is $100 X 1000, or $100K. A risc system uses the same model, at $150 X sum of CPU speeds. 8I is simply the current version of Oracle. Oracle was going from 8.0, to 8.1, but renamed to 8i to jump on the internet bandwagon.
??? There is no "LOCK" command in SQL. Is this an MS Access thing?
Just junk food for thought...
the attitude "I know Oracle can do the job, so we'll use that"
Well, duh. Dunno where you work, but where I work we have plenty enough to do without evaluating which is the "perfect" database for our applications. Oracle works: fine, use that. Now, how are we going to get this all done in two months? How are we going to get the FR list approved? Is there a third-party toolkit available that handles both DOM and XML?
Informix? UPDATE TableA SET FieldA = (SELECT FieldB * 1.05 FROM TableA) won't work -- can't update the same table you're selecting from. Bit of a problem, that...
Just junk food for thought...
Postgresql 7.0 (which is now up to Beta 5, will have support for foreign keys, and more goodies.
Wrong, it's up to 7.0RC5.
--
> MySQL has no stored procedures. Absolute lie. It can load .so objects and has a known api
Learn what a stored procedure is before shooting your mouth off. Astonishing, what kind of doublethink passes for technical competence on slashdot these days.
I've finally had it: until slashdot gets article moderation, I am not coming back.
> OTOH, take the article's argument and flip it on its head: a *real* enterprise RDBMS, like Oracle, will *never* be as fast as MySQL for web applications, precisely because it's worrying about transactions and rollback
Final answer? Would you like to call a friend?
(Ok I promise I'll never use that gag again)
First off, MySQL only supports table-level locking, which means every last update to the table has to be serialized. Can you imagine if amazon had to serialize all its orders? Or a payroll system that had to process every paycheck sequentially on payday?
Secondly, in a real database, transaction logging can be turned off at the database level. And rollback/commit overhead simply doesn't happen if you don't enter a transaction in your update in the first place.
I've finally had it: until slashdot gets article moderation, I am not coming back.
MySQL has no triggers or foreign key constraints
Right. Because nobody needs them. They obfuscate the code and are only essential in theoretical discussions about RDBMSs.
I've haven't heard such horseshit in ages, and again moderated "insightful", likely owing to the wonderful job done at HTML formatting the post rather than actual thought that entered into it. I'll give you a trivial example: timestamping. An author updates a document in storage, and the change is timestamped by a trigger, and perhaps an author worklog is timestamped as well. Whether from a client application in perl or VB or python or a direct SQL query, this triggered update gets done and done right. And that's a trivial example. Your evidence seems to be "I don't use it, therefore no one else needs it." It's the same reason linux doesn't have a programmatic transactional system to update the goddam passwd files in a 30,000 employee system -- because Joe's Web Design And Auto Body doesn't need it.
Oh but that can be done at the application level, right? Some of us prefer to declare what we want and let the system generate the code properly. If I wanted to do everything at the application level, I'd use a damn tape-driven turing machine.
I've finally had it: until slashdot gets article moderation, I am not coming back.
One of the comments on the page poopooed the importance of transactional integrity, claiming that commercial databases didn't support commit and rollback before 1993 or so.
That's just plain wrong. I was using Oracle 5.0 on a MS-DOS environment in 1990, and even that had commit and rollback implemented.
If tits were wings it'd be flying around.
"Believe me, these tools are not even close to cutting it. Sure, many of those Oracle shops could (technically) use Sybase, MS-SQL, Informix and so on, but support contracts required for these sites are very demanding - engineers on site within hours, *CODE FIXED* within hours. Yes, Oracle will recompile Oracle and ship you a fixed binary within 24hours of a bug report - you just have to pay..."
Would I have to pay more or less for this than for someone else to fix it?
-rozzin.
If the differences in SQL servers are small, I won't have to change my middle layer much to switch. And if an SQL server is missing features (MySQL), a middle layer can transparently implement them for me.
It worked for me, anyway.
Ita erat quando hic adveni.
MySQL just released a very nice book detailing its assorted innards with plenty of in-depth coverage. I've yet to find a book anywhere on PostgreSQL (though one is being written). Online docs are nice, but I need more info before switching from a known (no matter how feature-poor) to an unknown. One book would make a world of difference.
Ita erat quando hic adveni.
It may not run as blazing fast as an app tied directly to the DBM, but I consider not being tied to a specific DBM to be a Very Good Thing. Does anyone else think this is a good idea?
Ita erat quando hic adveni.
I am doing mission-critical stuff with mySQL. It started when I created the company's elabourate e-commerce web site, moving it from SQL Server on Windows to mySQL under Linux. When that proved to provide superior performance, we are now moving our contact management system (under test at this very moment) to mySQL.
I really don't understand this oddly religious love for ACID. Yes, you need it if you're a bank and must coordinate double-entry accounting transactions. But darn few things in the world really require double-entry accounting.
What we most assuredly need is a database that hangs together, working with minimal maintenance and bother, one that a single person can easily maintain without reading 10,000 pages of documentation.
If there is a power outage, the UPS fails, and our server dies, we might well have bits and pieces of a sales order in our database. We can handle that, because I set a flag in the main sales order file saying "this isn't done, ignore it", and when everyting's done, I set the flag to "looks OK, let's do it". In one sense, I'd really rather have some evidence of the order in our database, because then we can call the customer, apologise, and ask her or him to re-enter the order. Far better than leaving her or him in doubt.
Other than that, I see no compelling advantage to using a database with ACID. You might argue that my company could have afforded Oracle, and you would have been right. But I'd used mySQL on databases used for all sorts of stuff on my web site, and it had never let me down. I already knew the APIs and how to administrate a server, so I was ready to rock and roll on the new application. If I'd had to use Oracle or Postgres, it would have taken me a week or two of precious development time to get comfortable with the tool. This might have been acceptable if we weren't running on web time nowadays.
The bottom line is that I'm inclined to defend mySQL from its formalist detractors. We've used it, and in the month or so of hard use we've given it, it hasn't let us down yet. I might add that everyone loves the application, its responsiveness and my ability to make changes rapidly and efficiently. This is all because I used an environment I already knew well.
I should give a caveat based on the nature of financial transactions. I suspect that the original poster's database did not use double-entry bookkeeping principles. If you do, I'd argue for transactions based on the complexity of updates. But for a single-entry database with simple updates, mySQL will work just fine.
My system uses mySQL to connect to a Microsoft SQL Server system running an accounting program to do the double-entry stuff.
D
----
Let's see: by my calculations 99.99999% uptime (which the industry would call "seven nines" uptime) would correspond to 3.1536 seconds of downtime per year.
The industry SOTA for Unix machines in a high-availability configuration (HP MC/Serviceguard, Sun Solstice HA, IBM HACMP, etc) is about four nines, and is moving to five, but only as end-to-end certified solution stacks that go all the way from environment (power, cooling, earthquake, etc) up through the application.
Tandem and IBM may be able to claim seven nines with their proprietary big iron, and maybe VAXclusters can get close, but I doubt that they'd guarantee it, and if they do they would never agree to liquidated damages so the "guarantee" wouldn't be worth the paper it's printed on.
Bottom line: when your system goes down at 3 am you will be on the hook to figure out how to work around the problem. You cannot count on any vendor to bail you out. Again: you're on your own. If it turns out that the problem is due to a bug in the database (which is unlikely - it's probably flight crew error) then maybe they'll fix it, maybe not. But my experience with Oracle and Sybase is that they're no more or less helpful than the community around pgsql and mysql. (OK, in Oracle's case, probably less). Each product has plenty of technical features that make them more appropriate for large-scale OLTP than mysql and pgsql, but having someone to call ain't one of them.
I'd also point out that phplib has a nice abstract database interface that wraps the pg_ functions with ones that will work with both mysql and pgsql (and others). I've seen a couple of cases recently (bookmarker, webcalendar) where apps which were written using phplib and mysql were easily ported to pgsql.
You should read up on their versioning stuff 'cause that ALPHA doesn't mean what you think it does.
--hunter
RateVegas.com - Vegas Reviews
The OpenACS project refuses to break with the important principles of the ACID test.
I mean, I hear Acid test, I think of the Electric Kool-Aid variety. What I end up with is this image of a bunch of hackers all flipped outta their gorges, with a couple of guys from OpenACS just shaking their head that the MySQL guys can't handle the overstimulation...
(c:
Your Brain + EEG + LEGO Robots = Brainstorms
The slashdot under load behavior I've observed goes like this:
1 - Click on something
2 - Long hang (up to 30 seconds)
3 - Network light starts flashing on the front of my machine (fairly quick DSL connection)
4 - IE spikes the CPU rendering the page. (Netscape 4 just hangs for a long time here with small CPU spikes.)
5 - Page appears
So, the drag seems to be either the database or the PL script which renders the page. Apache is filling the network pipe, and rendering on the client end is quick with IE or Mozilla.
One thing to note is that Slashdot stories pretty much go from 0 to 200 comments in one hour. That's quite a few updates locking the mySQL tables, during which time all SELECTS are blocked. (That is, if I understand the critique of mySQL correctly.)
This is probably an oversimplistic view of how slashdot works, and I know I could get the code and look to see where the hotspots are. But, from the outside, the DB layer looks to be the slow spot.
--
Business. Numbers. Money. People. Computer World.
So from your statement I guess you suffer from the well known acute lack of ability to read syndrome. Go read the fsck^H^H^Hine manual and than make statements about something you do not understand.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
One more ignorant idiot that thinks that he/she knows everything... Sigh....
10th time in a row: Mysql has arbitrary string lock. If you want lock on a record than do an application level lock on a string with a generated record name. Read the fscking manual... And it has had it for years...
Sigh...Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
MySQL has no stored procedures. Absolute lie. It can load .so objects and has a known api. Yes you cannot do a macro define and store it. You can do something that is better - place a code on the server to do the job
MySQL only has table-level locking. I am getting sick of shouting. Mysql has arbitrary string locking, has had it for years, it even has non-blocking mode (you can stall on such lock or wait an arbitrary number of seconds). Go RTFM
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
MySQL is the database powering MultiMania, one of the largest content and hosting sites in France. Our user database has 400,000 records and most of the other tables are of similar scale. MySQL has a superb track record here - very little downtime, perfect integration with the rest of our platform (Apache, PHP), and as near to zero administration as one could wish for.
Nevertheless, I happen to agree with most of the comments in Ben Adida's article, expect, that is, for the accusations of dishonesty on the part of the MySQL team in the follow-up.
MySQL doesn't have those properties which Adida deems "critical". It isn't a "real" RDBMS. All true. But neither does it claim to be anything more than it actually is; a database system that is designed with "speed, robustness and ease of use" as primary goals. And its cake *does* have a relational icing, which makes it extremely useful for a variety of tasks that do not require a full-fledged relational database.
As usual, the proper question is whether the tool is suitable for the task, and black-and-white distinctions such as "critical" vs. "non-critical" data are of little use in such assessments. If you are handling billing records, then you definitely don't want to entrust that data to MySQL, for precisely the reasons outlined in Adida's article. Likewise if your project involves complex relational data structures. Otherwise, most database-driven Web applications can largely benefit from MySQL's ease of use, and will get done faster, run faster, and scale better.
And of course, there isn't any law that an information system can't use both MySQL *and* a slower, more powerful product such as PostgreSQL or Oracle, entrusting different types of data to one or the other as appropriate.
IMHO and as far as I can tell from reading between the lines of the story on OpenACS' site, the real reason OpenACS isn't using MySQL is that ACS was written for Oracle, and makes use of stored procedures, which MySQL doesn't provide. PostgreSQL is more similar to Oracle in terms of features, so would be a more 'natural' candidate for porting a system originally based on Oracle. If it had been written for (say) mSQL, it would have been ported to MySQL.
I would say that Adida rationalizes after the fact the motivations for choosing PostgreSQL (contingent, historical constraints) as noble architectural principles - something of a "sour grapes" attitude, again IHMO.
Nobody's mentioned yet that Oracle is a VERY non-standard SQL Syntax?
Given two bad choices, I look for alternatives.
I personally would never recommend Oracle to any organization that didn't need a 1TB database.
- Overpriced (purchse *and* TCO).
- Non-Standard (hard to replace with newer tech)
- Slow Connections, Odd restrictions:
* Queries returning more than 1 row from a view/join that has more than 1 LONG [BLOB] will take at least 1000x longer than if just one row is returned.
* It has to be a view/join because only 1 LONG is allowed per table definition.
* For CHAR/VARCHAR types '' is equivalent to NULL
* INNER and OUTER joins will have the syntax changed to (+) and (-) for no appent reason.
* SUB-QUERIES are only allowed as a clause:
- select a, b, (sub-query), q where a = 'apple' is not allowed.
* DATE types/functions are not consistantly stored. (no fix yet).
Every other RDBMS (PostgreSql, Sybase SQL Anywhere, etc) is quite suitable for the small/medium sized data sets in use and if one flakes you can move to a different one fairly easily).
As a professional IT consultant working for one of the top names in the software industry I am working on a detailed report into the "open source" phenomenon (thanks to various people for pointing out that it is not freeware per se) as started by Linus Torvalds with his Linux operating system some six years ago. I browse this forum for insights into the Linux user and developer communities.
Allow me to correct you a bit further. "Open Source" is essentially a marketing program (on practical grounds rather then idealogical) for "free software". Richard Stallman started the free software movement when he started the GNU Project in 1984 with the aim of creating a freely-distributable reimplementation of Unix.
Linus Torvalds significantly popularized free software with Linux (which he started in 1991). Linus provided the last missing piece of the hitherto incomplete GNU system -- the kernel. It's a critical component, but bear in mind that without the prior work of the GNU project, Linux wouldn't be where it is today.
The "Open Source" movement was created in response to Netscape's announcement in January 1998 that they would release the source code to their browser. The relabeling has been very effective, as can be seen in events of the past two years. Netscape's source code release has been viewed by some as less successful, but Mozilla is alive and well, and has made very significant progress since the original source code release. Jury's still out on this one; my personal belief is that Netscape will be making a comeback in the browser marked based on the Mozilla efforts.
Anyway, my question is, is there a fully-featured open source RDBMS out there? Your help is appreciated.
You might want to check out PostgreSQL. It's an object-oriented RDBMS with SQL support as well as transactional integrity. It used to be considered only suitable for academic use, but much work has been done in the last 5 years, and from what I've heard it's one of the most solid free databases out there...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I fail to see how Berkeley DB is any better than MySQL.
Berkeley DB already supports transactions and ACID properties. MySQL doesn't. That makes Berkeley DB more solid at the low level. It doesn't support the high level. That's why neither is a complete substitute for Oracle.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
This is very good news, although I didn't see any mention of transactions and journalling in that press release, only database replication. (Of course, to do proper replication, you should have distributed transactions...)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
My mistake; I intended to include a note that free software existed long before RMS made it into a cause. (Much like Open Source software existed long before that name was coined.)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
So how feasible is it to combine MySQLs SQL parsing and query processing with Berkeley DBs storage layer?
As I mentioned in another posting, I've been wondering this for a while now. You would obviously have to start with the MySQL version that was released under the GPL; I believe that Sleepycat allows free redistribution of the Berkeley DB code if the source code of the application is distributed, as the GPL would require. This may mean that Sleepycat would allow Berkeley DB to be distributed under the GPL? (Might be worth asking them...)
As for how hard it is, I have no idea. I don't know how clean the interface is between the frontend and the backend, or if there's even a clear boundary at all. Berkeley DB has a clean interface, but I don't know if it would be easy to plug it into MySQL.
Still, it might be worth a try...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
That link has nothing to say about client/server. The real answer is that Berkeley DB doesn't do client/server operations natively because that's at a higher level than Berkeley DB is designed for. It's intended as an embedded database, usage of which is determined by the application it's embedded into. It's not designed as a generic database server.
It's straightforward to make an application that is a TCP/IP server frontend for a Berkeley DB database backend. I've done exactly that, and it works fine. In fact, the code that I wrote for this purpose has been in use at a regional ISP for over 50,000 users to handle authentication information for RADIUS and Email...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I would never trust the master copy of any critical data to MySQL. It's a nice little database, simple and very fast. However, without transactions or journalling, there's no way to trust completely that the data is safe. I would use MySQL as a high-speed cache, but not as a master repository; you may need to rebuild the database at any time if it becomes corrupted.
Berkeley DB is one of my favorite databases, because it is also small and fast. Unlike MySQL, it does support ACID properties, transactions, journalling and rollback, etc. However, it doesn't support a schema layer or a SQL processor. It's designed for embedded applications.
Neither MySQL nor Berkeley DB is a substitute for a real SQL database. Berkeley DB at least has a solid foundation that could be extended to become a full SQL database, should someone write the necessary code. MySQL, on the other hand, has fundamental deficiencies that are hard to correct. (On the bright side, that's why MySQL is really fast.)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Transactions are a specific feature to ensure consistency when multiple updates need to happen atomically. The requirement for transactions is driven by the task you are trying to solve. If your task doesn't need multiple updates to happen atomically, you don't need transactional support. Even if your task does require transactions, having them built into your database is only one of many options for implementing them. The transactional needs of most web applications are very simple and can often be much more efficiently implemented in the application code on top of a database that does not have transactional support.
I suspect most web sites actually get more reliability out of MySQL than they would out of Oracle (and better performance to boot). MySQL is much easier to configure, it's a much smaller and simpler software system, and it has very straightforward logging facilities that you can use for replication and recovery. All of those properties remove a lot of the risks that really cause data loss.
That isn't to say that Oracle or some other transactional database is never the right choice. For the applications those databases are designed for, business and financial data, their feature set are appropriate and their poor bang-for-the-buck is less important. On the other hand, for really high performance web applications, even MySQL is way too slow, and developers have to roll their own.
I think the database situation is far from good, either in the commercial world or in the open source world. I suspect SQL itself is in part to blame for this state of affairs. Ultimately, relief will likely come from a paradigm shift, perhaps to more API-centric approaches (like MetaKit) or to persistent object stores.
Transactions also don't come in a single flavor, they come in different levels with different guarantees.
And while "if the transaction didn't complete, immediately undo everything" is nice, it's often unnecessary. Many applications can be implemented by adding information into the database and activating it with an update to a single row in a single table (which is atomic in most databases even without transactions). The main area where that doesn't work is if you do global operations on tables, like taking a financial total; but that need doesn't usually arise in systems like ACS.
The transactional problems most web based sites have to solve are much simpler than the transactional problems that an enterprise level financial database has to solve. OTOH, performance and cost matter a lot more for the web site.
As for the Western movie analogy, it's a good one. If you aren't quick enough against a good opponent, you're dead. It's better to take your chances and draw quickly even if you can't hit as accurately. The same is true for a lot of business decisions.
While i've been playing with MySQL in order to learn SQL, I still just don't have enough trust in it to actually think to one day use it or recommend it's use in any critical environmnet where it could actually effect outcomes or incomes.
What's the ad say? 96% of the top 50 e-commerce sites use Oracle? That's 46 of them. There must be a reason for it... I'll trust their decisions and not try to reinvent the wheel. If it's not broke, don't fix it.
Yes, MySQL has a blazingly fast engine, but at the expense of so many other features.
PostgreSQL. Open Source and reliable.
PHP has a beautiful interface for connecting with Postgres :)
:)
On php.net, go to the quick ref and start looking at all the functions that start with the prefix "pg_"
It's the same basic idea as mySQL connections: use pg_connect to open a connection, pg_exec to do a query, and pg_result (and its many cousins) to get back the results.
My opinion only, IANAL.
MOO;IANAL.
There used to be a picture linked here.
It took several long minutes before I recognised that "rederick" == "rhetoric". :)
This speling flame, including obligatory misspelling, is now complete. There's nothing to see here, move along.
Your right to not believe: Americans United for Separation of Church and
One thing I didn't like about Postgres, was that there was no concept of users and passwords in it. Am I going to let X users share my machine in an environment where everyone can see everyone else's tables? I think not.
I'd like to add to this...
When designing a commercial database system for a mission critical project, you want create code that can be extended later. If you use a database that will insure data integrity, then there is no need for you to mix in what will become a bunch of cumbersome legacy code.
Otherwise, by mixing your data management code with your applications, you run the risk of some numbnut screwing your data integrity while implementing some dumbass feature.
I agree that time spent implementing what the database could and should provide is time wasted. For 9 out of 10 programmers, I'm sure they understand their client better than the folks at Oracle, and I'm sure Oracle understands database issues much better than they do. Focus on your strength. Those hours coding new database features can spent working on the actual application -- tweaking the interface, optimizing queries, anything to help the client.
There are still alot of programmers that think that they can and should write everything. Wake up. The computing world is rapidly becoming more and more complicated; you will be doing your self and your clients a favor by reusing as much code as possible
I said it at length on the ACS site, and I'll summarize it here:
If it supports a reasonable implementation of Dr. Codd's relational model based on predicate logic, it is relational.
MySQL is relational.
Next issue.
--------
Bill Gates Is My Evil Twin.
I would be more interested in Postgresql except there is this really irritating postbot that with deadly regularity pops up and says in a colorless monotone, "Use Postgresql. It tastes good. It is better for you."
What's curious is that the bot never seems to talk about its actual real-world projects using Postgresql. I would love to hear more about that, actually. It's only from comparing our experiences that we learn how to do our work better.
-------
Bill Gates Is My Evil Twin.
This sounds reasonable until you apply actual experience to it. Most databases in most circumstances are primarily read-oriented. If I were to put very broad numbers on it I would say 80% read, 10% write and 10% processor-bound. There may be a few very active tables where writes dominate (for example, a cookies table for a web site or a state table in a logistics app), but this tends to be limited to one limited area of the database. In general, such active tables will always be in memory anyway (or should be to the extent possible, if you can't manage to add more memory perhaps a redesign is in order since the cost of going to disk especially for frequent writes is prohibitive compared to in-memory access). Data integrity features such as SQL COMMIT/ROLLBACK on table writes may be indicated when the risk of data loss is high, but don't forget that you pay a performance and overhead price for having these features active. That is to say, data integrity features are desirable but not at an indefinite cost. It is important to remember that in databases, as in all programming, nothing functions in complete isolation. The presence or absence of a given feature does not trump every other consideration, and besides that, sound design generally is the most important, least understood factor within your control for making any database work properly. -------
Bill Gates Is My Evil Twin.
I worked for a open source academic database Predator with the following freatures
transactional support
support for large volumes
cost-based optimizers
complex data types
and the list goes on
you can actually preview it on the web with the tutorial
the version out right now is for nt and we will have an linux/solaris port out by 05/01/00
Reading this whole thread makes it sound like MySQL simply loses data every now and then so you cant trust it (It doesn't). Moreover, it sounds like databases which support foreign keys and transactions don't lose data so you can trust them (Which aint the case either). If you don't trap application level errors in your code, neither database will give you much of what your looking for. I really believe this whole thing boils down to the quality of the programmers in front of the database.
I've seen a non transactional database move 2 million dollars of product a day. I also saw that same database seize up the factory due to bad programming. And it was the direct result of some new guy who decided that everything had to be rewritten with transactions. Bad programming is a much bigger culprit than ACIDity anyday. Same goes for bad DBA skills. Ever had a DBA outright LOSE a transaction log?? Or blow away a mission-critical database trying to setup replication? (Which MS SQL 6.5 made very easy to do, and its supposedly ACIDic).
On the other hand, I've seen a complete manufacturing execution system written in Excel VBA... and it worked for the most part. It was a maintenance nightmare, but it worked. I think those guys would have been taking a step up with MySQL.
Give me high quality programmers and functional tools anyday. Beats the hell out of excellent tools and lousy programmers.
The difference between Oracle8 and Oracle8i is that Oracle8 is actually Oracle 8.0.x and Oracle8i is Oracle 8.1.x and anything newer. It's a silly marketing ploy. Even if you're not doing internet stuff, 8i is markedly superior (to 8) in just about any way you could name.
WebDB is unrelated to the change from 8 to 8i. WebDB is also a huge steaming pile of fecal matter that deserves to languish in obscurity.
I think the ArsDigita folks would be a little more convincing if they considered intermediate solutions instead of the extreme ends of the spectrum. I'd (personally) never trust MySQL with on-line transaction processing, or anything involving non-trivial amounts of money. On the other hand, I wouldn't seriously consider a massive system like Oracle unless I was dealing with vast numbers of transactions or large amounts of money. On the gripping hand, most of my DB experience has been with middle-of-the-road systems like Sybase and (ghod help me) MS SQL, which may not provide the full power and reliability of Oracle, but much more flexibility and stability than MySQL. It's a matter of fitting the needs of your project. Now, I am considering using MySQL for a personal project involving web page generation; I might consider Postgres after reading some of the remarks here.
--
Weblogging Considered Harmful:
Free-gratis, as opposed to free-libre, of course.
--
Weblogging Considered Harmful:
Oh look, a Mac luser.
Bye, then.
So how feasible is it to combine MySQLs SQL parsing and query processing with Berkeley DBs storage layer?
For all the (very valid) faults MySQL has, it is still a great database. The real answer to the question of whether MySQL is a good database, though, is another question -- what are you trying to do with your data?
Early on at Napster, Inc., we discovered that MySQL was quite the capable database; it was easy to install, easy to move around, and easy to administer. Permissions were simple to understand and manipulate, and for basic data storage, you just can't beat its ease of use. However, MySQL's shortcomings really constrain it to a narrow audience -- low- to middle-end systems.
IMHO, the biggest shortcoming of MySQL is table-level locking. Foreign keys, stored procedures, etc, those are arguably good things to have, but at the basic, essential level, they're extras. Table-locking will now and forever keep MySQL from ever being a high-end database solution.
You can throw hardware at MySQL, but only to a point. Eventually you will find that millions of rows, and either inadequate keying or over-keying will hurt you considerably. If you key inadequately, you limit your searching capabilities (or incur large search times over non-keyed data). If you over-key, you'll incur a performance hit with every update, insert, or delete. And this is where table-locking hurts you too; the table is locked while the indexes update.
And let's not forget the lack of supported replication and redundancy. If the daemon dies, it's gone -- go reload it. Replication? Not supported, so your best bet is to copy the table files somewhere else. Of course, copying the table files locks them too, and all your clients' writes and updates will block. (Yes, I know about the MySQL clustering stuff. Kludgy, and not terribly reliable. Definitely not proven.)
Sure, it's free software, I'm not complaining. Just pointing out the facts.
For tables with millions and millions of rows, there comes a point (very quickly in fact) when throwing gigahertz around just won't solve MySQL's problems.
In MySQL's defense, of course, you have INSERT and REPLACE DELAYED, so from the client side you can continue on without blocking. Eventually, though, you'll have to pay the piper, and for a table whose transactions are largely SELECTs peppered by a (relatively) smallish number of UPDATEs, INSERTs and DELETEs, your client's SELECTs will block when that delayed thread wakes up to dump down the data.
Even better, in the latest alpha vers there is the concurrent_insert business. Unfortunately, in our testing the only alpha version that DIDN'T crash under our kind of load was the version right before concurrent_inserts were implemented (3.23.7 has it, but 3.23.6 is the most recent alpha that won't core dump). I suspect this functionality might be to blame.
All that said and done, MySQL might still be the right database for you! It's really just a question of using the right tool for the right job.
MySQL has interfaces into almost every language, and as a developer of MySQL-aware software, I have to say I really, really like mysql++. As long as you're not doing anything transaction-intensive or operating over millions of rows, MySQL is a rock-solid choice.
Unfortunately, for Napster, Inc., it just wasn't.
- Subqueries:
- Stored Procedures... you wrote: The only overhead for stored procedures is when you create and save them. After that the code is stored 'compiled' and optimised by the database engine. True. But that doesn't include the overhead already in the database which allows the stored procedures to be loaded, processed, and used. From my rather limited reading of the tests comparing Oracle, etc. to MySQL, I believe (perhaps wrongly ?) that this subsystem is what boggs down the bigger RDBMS's in terms of single CPU speed. I would love someone more expert than me to verify/disprove that belief, by the way.
-
I guess my main point should have been, don't dismiss MySQL if you don't need the horsepower and don't have the time or money to waste on in-house staff to support your bigger fatter RDBMS.I completely forgot to mention this -- which is my pet peeve about MySQL by the way. I hope that the MySQL development team reads /., because the lack of sub-selects is in my mind the single major reason to avoid MySQL as an option.
Being an expert at flatfile-style DBMS is a useful trait. However, you should try some real RDB programming -- your life will be much easier, and you will be a happier individual.Well, gotcha there. I use Oracle about 40% of the time, SQL Server about 20% of the time, and MySQL about 40% of the time. So I am a) fairly happy, b) expert at flatfile and somewhat expert at RDBMS databases, and c) knowledgable enough to use the right tool for the job.
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
The soapbox I always climb on is that all of those features are still available, just not at the RDBMS level. Between 1985 and 1996 (roughly), I was writing client server applications with tools not nearly as powerful as we have today -- to work with ISAM, dBase/Foxpro, and B-Trieve type tables. I've created modules that did database replication, transactions, server-internal processes called by client apps (doing the same kinds of things that stored procedures and triggers), and I would wager that all of my code which did those kinds of things looks a hell of a lot like the code which does those things inside Oracle, DB-2, Informix, etc.
In more simple terms, here's the progression inside the database:
- A certain type of data request is made for which a trigger has been set
- When the "trigger" is pulled, i.e., that type of data request is made, code within the database is launched
- Code within the database performs some useful function, which may include actions which cause other triggers to be fired, etc.
- Code within the database returns values as defined by the trigger/stored procedure.
Okay, (as an example), you want to do the same thing with a web server enabled with PHP and a MySQL back end? Here goes:- PHP code on the web server tests for a certain type of data request.
- When that data request is made, the web server calls another PHP module which has been programmed to do the same thing the stored procedure did.
- This new code performs some useful action, which may include calling other modules to do useful functions
- These functions interact with the database, doing the same things their stored procedure counterparts would do, an return data/return codes to the calling program.
What are the differences?- First, PHP is obviously not as fast as the PL/C code inside an Oracle database, etc.
- Second I (the programmer) have to work a little bit harder to make things work efficiently, and
- very importantly, I only incur the processing overhead for "stored procedures", in the specific application modules that need it -- not throughout the database.
Which is why MySQL is my database of choice when I have one for damn near every project I do, including some large, enterprise size data sets. The key is, knowing when the other features of Oracle, SQL Server, etc. are more critical to the client than outright blazing speed for the majority of the database work to be done....Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
It's not Open Source, but you can try Cache` from Intersystems It can talk SQL, and stored procedures are written in M. It's used extensively in the medical industry (where I work). They license by concurrent user, not sure about pricing though.
I don't know what kind of shop /you/ work in, but where I'm pounding the keys if data is revocably lost, you'd best start looking for a new job.
Blar.
Might be a dumb question, but I seriously don't know.. I've just gotten into using PHP w/ MySQL, but am curious as to how PHP interfaces with PostGres.. a search on google proved unhelpful, as nearly everything I turned up was in a foreign language.
Does anyone out there know of any websites that cover this topic better? A search for postgres on php.net turns up nothing.
BilldaCat
The lesson of all of this is:
1) Know your requirements.
2) Know what the database solutions available can handle.
3) See if they match up.
There's really not much more to say.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Exactly. It all depends on what you need.
I don't know if most people can get by on MySQL, that's a statement that'd take some thought to evaluate. But we certainly need to know what we require for a project before shelling out $$$$ and time.
Arguing over general superiority does nothing - but functional necessity is another thing entirely.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
But now moot, since they just released the sucker. :-) Seriously, I just spaced out on the release candidate versions. The real point, of course, was that PostgreSQL really, truly has foreign keys.
Well, except for partial matches. I'm sure that's a bummer for somebody out there, but not me...
Babar
I think other people have found the MySQL side of the story less than completely frank. A big reason for this is their infamous benchmark collection, where they compare apples and oranges. (To drag this metaphor out a bit, they also seem to suggest that since their apples are sweeter than most oranges that it's okay that they are a poor source of vitamin C since most foods are a poor source of vitamin C...)
Babar
Glad you mentioned this stuff. There are many problems here.
So, what do you really think these prove? Not much in my book. OK, here's one: if you take a database that doesn't do transactions and compare it with one that does, then certain transaction-related tests are going to favor the former. Wow. Like that's big news.
Babar
Well, as the article referenced by this thread suggests, some of "the fancy stuff" missing in MySQL includes real triggers and things that would actually speed up many MySQL web apps.
More importantly, you don't have to buy Oracle to get ACID; just get PostgreSQL instead. Open-source, and with a pH value only a fraction of a unit away from pure ACIDity.
Moderators: this post is only redundant if you assume that people have read the article; that's all I'll say.
Babar
Ah, I think I've had an insight.
It might be the case that some people don't appreciate the difference between declarative programming, where you just state the desired result, and procedural programming, where you have to do much more of the work yourself.
The whole relational model of databases, as described by people like Chris Date, is a nice fit for declarative programming. In reality, things are not so nice, and they involve some very ugly things like the dark corners of SQL. BUT you should never have to go in and try to figure out how to do stuff like row-locking.
This is not only because you might well screw it up, but because your problem involves coming up with an appropriate design for your database, not worrying about how little fiddly things actually get implemented. Yeah, that's an ideal, and it doesn't get reached very often, but you don't go out and design a system that's going to require a bunch of non-declarative code just to get things up to speed.
Go ahead and implement your own row-locks or transaction logs. Nobody is stopping you. But don't go claiming that your need to hack doesn't expose a weakness in the system.
Babar
This is true for PostgreSQL versions 6.5.x and below.
Postgresql 7.0 (which is now up to Beta 5, will have support for foreign keys, and more goodies.
Babar
True, but their attitude bothers me. They point out the shortcomings, and basically suggest no one use it, when in fact mysql is a great database for it's intended usage. They can't seem to understand that MySQL fits a niche that no other database does which is why the MySQL folks have made feature compromises for performance.
Do these people think they are really telling people something new? I'm really somewhat offended by the attitude they use, like MySQL is fooling people or lying about what their product does. It's meant to be fast and simple. Period. It's not meant to handle data integrity, transactions, and other advanced features. They seem to feel that this is a fault whereas most people will agree that this is a feature because when you don't need all that stuff and you really just want something fast to do queries (like a dynamic web page...), MySQL is the hands down winner.
Not duh!
Sometimes it can't be fixed, if the problem is a fundemental implementation problem.
Besides, as a developer, I would rather be developing my app, not rewriting a database.
Oracle 8i is available for Linux, and while it is commercial, it does have a good reputation.
-- Error: Cannot find file REALITY.SYS - Universe halted, please reboot!
More cult of greenspun rederick. Of course MySQL is good enough for most sites out there. I wouldn't run TerraServer off of it, but things like phorum and so on don't do bad by it. /. runs it, and /. is high volume. However, if the database were to corrupt tomorrow, I hope they have thier dump files on hand. My company uses Informix for some of their newer products, but they are trying to get to straight SQL controlled remotely. Why, you may ask? Because independence means adaptibility. But Oracle is great for its features, which include a very powerful internal scripting system. It is nice that you can check data integrity as a given with the system. That said, It may not be that important to you. If not, then run MySQL. It's good enough for 90% of the tasks put in front of it. May I also remind you that Phillip used to work for Oracle, and as such may be a bit biased. Why do I keep mentioning him? This article is written by an arsDigita affiliate. The same stances are taken against perl and apache, and for AOLServer and TCL. Not that there's anything wrong with that, and everyone IS welcome to his/her own opinion, but this sometimes rises to the level of cultism with Phillip's crew.
Lowmag.net
I work for a relatively small insurance company who has done some work with mySQL. We have a web site from which our field agents run reports written in Perl. Typically the database will have around 150,000+ records
It is fast. Very fast. mySQL does exactly what I need it to do, spit back data quickly for those agents on dialup internet connections.
In the 384 days (and counting) that we've had mySQL up and running, there has never been a corruption or crash. So yes, it is a stable and reliable database.
The important thing is that it works for us. If you are selling stuff online, maybe you should look at something else, say PostgreSQL.
-------
Hecubas
MySql is _not_ OpenSource
I guess if you don't consider the GPL to be an open source license, then your statement makes sense. While TcX doesn't release the current-stable series under the GPL, they release older generations under the GPL. You can get MySQL 3.20.32a under the GPL right now. When 3.23.x becomes the official stable series, I'll bet you'll see 3.21.33 be GPLed.
TcX has been developing MySQL for years without "raising the price." Even if they did, so what? You still get the source, and they still publish older stable versions under the GPL.
As for PostgreSQL... Until it becomes *stable*, *fast*, and supports *outer joins* I find it an unworkable solution.
-JF
MrJoy.com -- Because coding is FUN!
If we were to implement something that required more than a few updates per minute, we would look into PostgresSQL or Sybase but as it stands now MySQL is the hands down winner.
My company's benchmarks indicate that MySQL is faster for inserts than DB2 (widely regarded as being a bloody fast database) by a factor of 30x. Higher if you want to avoid table corruption in DB2. (we had to turn journaling off to get the best performance)
-JF
MrJoy.com -- Because coding is FUN!
This sounds like an application that could be better handled by LDAP instead of an SQL database.
Hogwash.
I have a suspicion that the people who safely use MySQL would be better off using LDAP, because their applications are heavily oriented towards reads
Actually, our application is heavily oriented towards *writes* which is why we use MySQL. 30x faster for our situation than the best alternative. (DB2)
We did use LDAP at one point, but performance and scalability were non-existent. We had to scramble to move to MySQL when we started getting around 50,000 page views/day -- the LDAP system couldn't handle it. Now, with MySQL we handle 2,000,000 page views a day, with several products instead of the one product we had at the time. (web based e-mail client)
-JF
MrJoy.com -- Because coding is FUN!
yeah, but how much does mySQL slow down if you want to avoid table corruption? oh wait, unlike DB2, you can't avoid it.
I've NEVER seen unrecoverable table corruption in MySQL. In the DB2 instance, a table would be completely obliterated if the script accessing the table crashed before it disconnected the database handle. Oops. No ability to recover AT ALL, thanks to the fact that turning the journal off is what caused the instability.
Fast and decently reliable is good enough for some tasks, but for almost all non-web, and a good bit of web applications, MySQL is a square peg in a round hole.
I agree that for many non-web tasks MySQL is not well suited. At least for so-called "enterprise level" stuff. MySQL can be used to fill smaller niches even in that arena though.
I've only ever been involved in one web application where MySQL was not well suited, and that application classified as a traditional "data mining" type application.
-JF
MrJoy.com -- Because coding is FUN!
I hope MySQL doesn't try to become just another RDBMS - we have plenty. What we need is different tools for different jobs.
There are no "real" opensource RDBMS's. In fact, there are very few that are worth considering even in the commercial arena. I would not consider running any serious project on anything other than Oracle, Interbase, Sybase, Cache, SQLServer. (I think MS Jet might pass the acid test, but it is single user.)
I thought you could get support for your commercial software package from the vendor...?
Sybase is probably right up your alley. All the power of an enterprise RDBMS (it absolutely DOMINATES all of Wall St. and other Financial Svcs. companies) and it is a lot easier to configure, administrate and program than Oracle (much, much, much easier.) After all, Sybase and MS SQLServer used to be one and the same product
Yes, I have used it... unfortunately. SQL Server was a horrible product through to version 6.5, when it was based on Sybase. For version 7.0, it was pretty much rewritten from the ground up, and it's now orders of magnitude better.
I can't think of a single reason to use Sybase over almost any other RDBMS... It's very buggy, for instance there's no ODBC drivers available that actually work properly.
This is not to put down all things Sybase--Sybase IQ, on the other hand, is wonderful. It's a DB for data warehousing which has stellar performance.
- No subselects
- No updates or deletes on a query with a join
- No views
This means that if you want to delete/update in one table based on information in another, there is no option but to do it programmatically (rather than with just a fixed series of SQL statements). Another example of this problem is that MySQL doesn't let you insert into the same table you're selecting from, again requiring fiddly and time-consuming workarounds that just shouldn't be necessary.Despite it's many short-comings, MySQL fills an important niche--there are no other DB servers I know that provide reasonable SQL capabilities while compromising on 'ACIDity'. Yet this compromise is actually ideal in many situations... Take Slashdot for instance, where the occassional lost comment is acceptable for an enormous speed increase. It does mean being more careful with your coding to not end up with orphaned records, but on the other hand the inefficiency of Oracle/SQL Server/etc in having to check for transactions, triggers, referential integrity, etc on every update is not always ideal.
I do find the Open Source/Free Software community's infatuation with MySQL most perplexing though (like the authors of this article). It's neither free speech nor free beer (unless you use it for no commercial purpose--even if you just consult you have to purchase it).
My dream database for non-critical systems (like running web discussion boards!) would take the same design premises as MySQL, but provide the same power and flexibility as MS Access and SQL Server. Yes, I said the M word! MS's databases provide almost no obstruction to using SQL any way you like... Updates and deletes can be done on pretty much any query where it makes logical sense (e.g. not on a group by!), and complex selects can be written with highly nested views and easy to write VBA user-defined functions. Furthermore, their linkage with very easy-to-use OLAP tools (OLAP Services and Excel PivotTables) is extremely useful when you want to get stuff out of your DB, rather than just put it in.
Just cause its free doesn't mean its any good. And just cuase its not free doesn't mean it sucks.
Hell, MS SQL has supported transactions forever... I can't belive MySQL has never gotten around to it... it's barely even a database, its more a data repository that uses a SQL like interface. Not to mention by not supporting transactions it fails to support those Open Standards that those of you around here seem to love so much.
DrLunch.com The site that tells you what's for lunch!
I'm a happy user of MySql for various purposes, including use for small e-commerce solutions. I am aware of what it lacks (its creators are, too) and I agree with the document in the sense that in most enterprise environments it does not provide the required features (I consider the lack of real atomicity the major problem); though, it may be also true that some of such features may not be needed in certain situations, for instance when critical data is written by a single source and accessed by many, that happens very often (but it is just an example). The TCO of MySql is so low that you can always rely on it until you need something different without fear of having made the wrong investment.
If you want a database that comes close to SQLServer or Oracle, and is free, use Postgres. MySQL just needs to realize that speed isn't all
that great. It will just become a mess of data all that much quicker without some very important consistency features.
I find it funny that the same argument is made by Java zealots when they try and convert people to using Java from the trusty C++ systems they currently have implemented.
Speed IS important. Not for some applications, I agree. But for a web site werving millions of customers a month? Speed is key.
One thing I'm surprised no one mentions is PostgreSQL's 8K rowlimit. Yes, you can hack around it pretty easily, but it's one more problem and one more headache that no one should have to deal with. I'm not a big fan of MySQL, but if you're comparing the two databases that's a definite issue that should be taken into consideration.
While your notional HTML snippet is undoubtedly correct in many cases, it doesn't represent the article under discussion. The author clearly states he likes Postgres, which is both free and ACID-complete.
(Sound of grinding metal as entire global economy screeches to halt.)
The problem with Freshmeat, there is to many connections try to connect at one time. This is configuration issue, and problem with freshmeat. Not with MySQL.
gezus..
There's something to iron out here: "critical" is not the same as "large". Keeping my credit card number safe is critical, but if no transaction/isolation problems are going to occur, then there's no reason not to keep it in MySQL. If your database is large *then* you can't afford the time between "transactions" (and if you don't even have transactions and your lowest level locking is per-table, *then* you're screwed). Of course, with size comes criticality anyway - if slashdot goes down then there are a lot of disappointed people around, but frankly my karma isn't worth worrying about ;8)
.|` Clouds cross the black moonlight,
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
The value of ACID is quite clear and if I were you I would not be in such a hurry to assume that posters have not understood them. Their real value is in making it simpler to code robust software by allowing the programmer to assume that Oracle's programmers have already taken care of the reliability. It is not the only way of ensuring reliability nor obviously the best. If a database application does not require constant additions the way a stock control system might for instance the advantages are much diminished and a little care can be a valid substitute. Likewise if the ratio between reads and writes is different or write operations are relatively simple similar things apply. There are plenty of cases of web sites abandoning Oracle in favour of MySQL effectively because the latter doesn't have transactions because of the speed differentials. Ever wondered why the database companies are not keen on benchmarks? Speed, cost and ease of administration are important considerations in many missions you know.
By the way have you ever tried to configure an Oracle Parallel Server failover system? Have you ever s
One of my problems with postgres (and this may be outdated knowledge) is the lack of ability to add a column to a running table.
Is this still the case?
Give a man a match, you keep him warm for an evening.
Light him on fire, he's warm for the rest of his life
Sorry, but having transaction support must slow down select performance and update performance outside a transaction. Here's why.
Assume several other users have started transactions, have updated various records, but have not yet committed or rolled back.
Concurrently, you have read the "before" version of some of the records that have been changed and possible committed. Until you have completed, the database must keep old versions of anything you might read until you have finished, and you must read old versions of anything in an uncommitted transaction. Even if nobody does use transactions, the fact that somebody might causes considerable complications and the code must be slower.
If you can trust your UPS, power supply, and disk cache, writes are much faster than if you must commit everything to disk (must also disable write cache on the disk itself) before returning success. It gets considerably slower if you do the write sequence so that the disk is in a consistent state no matter when you pull the plug.
thats way old man. like a poster stated, run not walk to your nearest ftp and get a 7.0 RC. The latest versions have full create user, type support. Including grant permissions like oracle. none of this 'mysqladmin reload' stuff, which is pretty stupid on a production machine.
-ryan
When I first looked at MySQL the claim was that by leaving out the features you gain speed. So if you have a DB with many queries but few updates, MySQL is the choice.
I have used MySQL in mission critical enviroments. The time frame was short but MySQL performed admirably. (even though I had to set up my own replication schemes.)
Predestination was doomed from the start.
How "micro" is a "microkernel" that includes a graphics subsystem?
"All people are saying that the earth is flat so it must be true!"
This is some positive evidence for Oracle, but not more.
Yeah, that's why nobody here would ever go close to some lame, unsupported OS like Linux. Without somebody like Microsoft or Sun there with support 24x7x365 to help when I have a problem, it's just not worth the risk. And I surely wouldn't want to pay someone other than the guys who produce the software to support it, even if they are possibly better able to and more willing.
load "linux",8,1
Here we go again with the my-tool-is-better-than-your-tool syndrome. I need to make up some T-shirts that say "the best tool for the job is the one that works". And yes, this is in reference to software, not with an arrow pointing down
I'm just getting tired of seeing the same debate over and over again. That's WHY we have MySQL, PostgreSQL, Oracle, Interbase... - THEY GIVE US CHOICES!
</RANT>
LOAD "SIG",8,1
LOADING...
READY.
RUN
The article was suppose to explain why not to use MySQL, but in my estimation, failed miserably. IMHO, MySQL has excellent performance based off it's advertised features. If you need ACID, buy Oracle. But, basically, don't buy a Honda Civic and complain that it doesn't have side impact air bags and 4 wheel disc anti-lock brakes, when they never advertised that it does. MySQL and Oracle are two completely different system, so don't waste our time comparing them.
In the last 10 years of database admin, mainly on Sybase and MS SQL Server the number one cause of problems requiring me to spend ages mucking around with systems is out of control logs generated by the transaction processing features (commit/rollback).
None of these systems ever used any of these logs. No transactions were ever rolled back. The entire effect of the TP system was to regularly make the database system fall over.
Now if you really need TP you gotta have it and you have to do the admin and that's life. For those jobs something like MySQL is not suited.
But if you want blindingly fast read, minimum admin, low cost and resource use MySQL is an excellent product and you will never have to truncate a log to free up disk space.
I'm kind of interested in Interbase as a product between the simplicity/low cost of MySQL and features/bloat/benefit/cost of Oracle and the like though.
all software has flaws and if you understand the software and pick the appropriate peice for your needs then everything works fine
Correct! These are some very important flaws. If you're not too worried about the integrity of your data or ease of programming, then you shouldn't use MySQL. *However* this is a bit like saying that if you're not too worried about stability you should use Win95! (Yeah, right)
...
Yes, I know I ramble and my spelling isn't quite up to scratch. If you wish to complain,
I am amazed how popular MySQL is considering its feature set and its license. I have used many commercial databases and have been using Postgres for about five years. I also have a fair number of clients using MySQL. In five years of heavy use I have yet to get any corrupted data in postgres. This says a lot because I have fixed a multitude of corrupt tables in MySQL. Could have transactions fixed these problems, in some cases yes. One thing that bugs me more than anything in MySQL is the lack of the Sequence. This is a very useful feature that almost all RDBMS have. The lack of transactions and sequences has pretty much kept me away from MySQL. I also am currently using postgres with a piece of medical software that we sell. This data is absolutly critical. After five years of stabilty with postgres I decided it was up to the task. This product has been in use for one year with no problems. I would have never trusted MySQL with this data. MySQL is a very good piece of software and has its place, but I am glad articles like this are pointing out its downfalls. I have found a lot of people just using MySQL due to its hype when in reality they need somthing with transactions.
how about this -- "So-and-so just wrote us with this piece about how you shouldn't use Debian on a production server. Discuss.
And remember, please refrain from making naughty comments, since it makes us seem like an AOL chatroom, and that's not what the shareholders are looking for out of you. Thanks."
i rule.
If you change anything in a table it is locked by the DB engine. If you do anything like an update, insert, or delete you have locked the table blocking any other update insert or delete until it is complete.
If at first you don't succeed, skydiving is not for you.
No mistake. It is a common misunderstanding. A DB engine must lock at the very least the record to be able to make sure that when it is being changed it isn't read at the same time and corrupt data is produced. MySQL locks on a per table basis. Sybase locks on a per "block" (can't remember the tech term) basis, I think PostgresSQL locks on a per record.
Any way the more granular the lock the more activity a table can have.
If at first you don't succeed, skydiving is not for you.
Read the article. Only one write to a table can be made at a time, i.e. table level locking. There are no stored proceadures and quite a few other things missing that actually improve performance. Yea for reading MySQL is faster but for a lot of writes to the the same table it will perform worse than some other DBs, PostgresSQL. I have a feeling that on very active stories that MySQL may be the reason for the slowdown, because there are to many people trying to post which yeilds too many writes which yeilds contention!
If at first you don't succeed, skydiving is not for you.
MySQL is a light-weight, one-step-up-from-flat-files database, but that doesn't necessarily make it a bad one. Most RDBMSs were built with the enterprise market in mind, for which ACID is a requirement. However, ACID may not be required *at all* when all you need is a fast data store for your web application server:
/.'s DB be slow and unreliable (since this comment, despite my best efforts, will never be critical data :-), but OTOH, make sure that the most frequent action (i.e. generating the discussion page with this comment and a few hundred others) is fast as hell. Which it won't be (or, actually, it won't be as fast as it can be) if you are worrying about things like atomicity, rollback, etc, etc...
In a Web environment, speed is (almost always) what matters. To get speed, you have to optimize for the most common operation: e.g. let my inserting this comment into
OTOH, take the article's argument and flip it on its head: a *real* enterprise RDBMS, like Oracle, will *never* be as fast as MySQL for web applications, precisely because it's worrying about transactions and rollback. And, although, I am not a big fan of MySQL, atomicity *can* be rigged on to a non-ACID-able RDBMS from the application end. E.g.: you can keep an array in Java/Perl/PHP that tells the application which DB tables are being written to, so read operations can *choose* to come back and try the read a few cycles later or instead opt to ignore atomicity (which is perfectly good for the web).
engineers never lie; we just approximate the truth.
Personally, I'm an Oracle weenie, but Oracle is expensive.
On the other hand, how critical is it that you don't lose data?
So we've heard why not to use mysql...any of the Slashdot team want to tell us what they like about it, how it performs for them, and why they chose it?
Which just shows you can't trust benchmarks, particularly benchmarks posted by vendors. I've used both on real datasets, and my experience is that if you have more than trivial joins in your database (and I've never seen a real database without some non-trivial joins), Postgres will eat MySQL for breakfast.
I'm old enough to remember when discussions on Slashdot were well informed.
There is a database which is free, which has high performance, which is reliable, which runs very well on Linux, which is reasonably easy to secure, which supports proper transactions with proper commits and rollbacks, which has a genuinely open-source license.
It's called PostgreSQL. It outperforms MySQL on just about any test you care to name. Get it.
I'm old enough to remember when discussions on Slashdot were well informed.
That's like replying to "This C compiler doesn'r recognize functions that return a void *, how bogus!" with "No, d00d, it lets you do something better, load in FORTRAN modules!" It's an irrelevant non sequitor.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Sorry, MySQL, for the pot-shot but I was so wrapped up in the spirit of the event! =)
BTW, to the very un-enlightened person that made a derogatory comment towards triggers and referential integrity:
BWAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
You know not of what you speak.
I do alot of middleware work (you know, interfacing to data stores) and it is people like you that get their grubby hands on table/database definitions that make my life a living hell.
Oh, and even though I do prefer PostgreSQL I'm not below mentioning that it does not natively support referential integrity! At least, not in the lastest non-beta version (I am eagerly awaiting a stable release of PGSQL 7.0) Sure, you can (and I do) get referential integrity via the PGSQL trigger and loadable modules facilities but it would be SOOO nice to not have my foreign key constraints ignored outright! (Instead I have to create special triggers. = )
--
You can be an atheist and still not want to succumb to some weird cross-over sheep disease -- AC
While your notional HTML snippet is undoubtedly correct in many cases, it doesn't represent the article under discussion. The author clearly states he likes Postgres, which is both free and ACID-complete.
and:
You've totally missed the point. God knows why this is classed as funny, but it's the sort of open source evangleism whilst ignoring the facts that gives us a bad name.
To both of you, 'crosseyed & painless' and 'meadowsp', I say: It's funny, laugh.
I've run into this on many occasion:
me: I need a unix type box to do testing.
suit: We can't afford another sparc box.
me: we can install linux on that spare machine right there.
suit: Linux is bad. It doesn't cost enough money to be a good product.
Same thing has happened to me with regard to other things such as sendmail, and apache.
If this has never happened to either of you, that's great. But most of us don't have such open-minded powers that be. It's happened to me, and it's obviously happened to the moderator.
I posted it because the suit mentality is funny to laugh at. Get a sense of humour.
If it's free, it can't be any good. Let's buy MSSQL7.
</APPAREL>
I'm sure there is going to be a lot of slamming of the "mySQL is quick and it rocks on site X" variety. But the points raised are valid. There are certain things that are required for RDBMS to be worthy of the name. One such element is transactions, when maintaining critical data it is paramount to ensure that an adverse changes can be removed when the change is found to be invalid. There are others but in most of the systems I've worked in this has been the key requirement, to bunch up a load of calls which are interspursed with coding logic and at the point where you reach a magic if statement that determines that something has changed and now the request is invalid to remove all traces of that request.
"It isn't enough to be quick, you have to be accurate" as many a Western movie has pointed out. mySQL is a fine system for maintaining data that can be the right choices in certain instances. But don't go betting the company on it handling your business logic.An Eye for an Eye will make the whole world blind - Gandhi
Postgresql 7.0 RC2 is out!
A UK ISP has used MySQL in a mission critical application - but you can't say which one.
There's lots wrong with the article - but you can't be bothered to explain.
There's lots right with MySQL: in fact a whole list of uncontentious points.
Why did you spend 32 lines of typing-effort on your post?
Try this: if you are running a large database with lots of updates to
information, where the content of those updates can depend upon the
results of previous queries, and where you care about the meaningfulness
of the data, then MySQL isn't even an option.
Charles
I've been writing about this product for a long time now, and the article is a subset of my gripes with MySQL. I don't care to be redundant, but I can add a few thoughts.
The MySQL supporters, in my experience, tend to be folks who don't have much knowledge of RDBMS technology, so to them, MySQL seems to be fast and good. Most of the rabid supporters will claim that MySQL isn't intended to be as good as Oracle, and that's fine, but if you bother to read their documentation, you'll find that they compare MySQL to Oracle quite often. They used to even brag that MySQL was half as fast as Oracle, which shouldn't be too difficult to achieve when we consider that Oracle actually logs transactions.
MySQL seems to fill a niche that a lot of people like. It's "good enough" to do what they want (even if it takes a little more work), they can get it free (even though maybe they should pay the $200 or whatever), and they don't know enough about RDBMS to know what they're missing.
A good example is subselects. I see so many people saying "but I don't need subselects". Of course you don't; you can write scads of code to do the same thing. I just have better things to do with my time.
And, of course, there's "but MySQL is so fast". Really? See how fast this is: "delete from table1 where key in (select key from table2)". Oops. Not fast at all when you have to do two queries, hope those tables aren't large. This is a common operation.
But my biggest problem with MySQL is the lack of stored procedures, triggers, and views. I know that the first two are nontrivial. All three of these are absolutely necessary for real security. (by the way, "column level security" is bogus, you need "row level security", and MySQL doesn't provide it) I think most people get around this problem by making their application 3-tiered, and putting the "security" in the middle layer (i.e. the PHP, Perl, or whatever code).
I want to stress this to MySQL zealots: I can create a database in Oracle that you have command line (read: SQL) access to, and you will be unable to do anything more than you can do with the pretty gui front-end. To put it in more practical terms (and this is a bad example, but it works) I could make a database that acted as a back end to an ecommerce site. You, the customer, could go into that database and view items in the product table, and actually create an order (in the orders and orders_items tables) that would be valid. You would be unable to set your own prices. You would be unable to see other people's information. Only your own. You can't do anything like this in MySQL.
It gets better. After an application is built like that (from the database up) adding a new front-end becomes trivial, because the application's core logic resides in the database and doesn't need to be rewritten.
An ecommerce example is lame in this case, because your customers don't get individual database logins, etc. But there are plenty of corporate applications where everybody does have their own login, and they should be allowed to change information that "belongs" to them, often with limitations on the change, while being able only to view or perhaps not view other people's information
Let's say we have an employee table. I should be able to view all my information, and update some of it (such as home address). I shouldn't be able to view other people's information, or perhaps I can view their name or department.
This is easy to implement in a database with true triggers, stored procedures, and views. Impossible in MySQL.
MySQL also is not free software and doesn't even fall under ESR's more "lenient" open source guidelines. It reminds me of Netscape (pre-Mozilla): widely accepted as the world's greatest browser by open source advocates even though it was a very proprietary piece of code. At least MySQL comes with source, and it's cheap.
Sorry if this sounds like a rant, it really isn't. I just want MySQL advocates to understand that it really isn't a good RDBMS, which is what the MySQL (TcX) folks make it out to be.
I actually use it in a project that I inherited, but going forward, new development will be pgsql.
-Michael
Do you have ESP?
Anyway, my question is, is there a fully-featured open source RDBMS out there? Your help is appreciated
What you are looking for is Interbase.
If you want a database that comes close to SQLServer or Oracle, and is free, use Postgres.
Actually, you should use Interbase. PostgreSQL is a SQL layered on Postgres. It doesn't implement nearly as full a subset of the ANSI SQL standard as Interbase does, for example: select-driven inserts. PostgreSQL is also fairly large and complicated to use, and has a lot of non-SQL features.
BTW, why is everyone so gung-ho about Oracle as a substitute? I'd hate to think all of /. are fools of the marketing dept at Oracle. Sybase is a much better option to Oracle so many more situations... Sure the company has/had problems internally, but it's still a better product that's faster and with less overhead and doesn't crash nearly as much.
my $.02...
I used to use Postgres for my website. Now I use MySQL. Why did I switch?
Well, in the beginning, I had no idea about RDBMs, so I asked people who might know. They told me to use Postgres, so I did. But handling BLOBs in Postgres sucks big time. So I created a class of virtual BLOBs in their own tables. My project went up hundreds of lines for stuff that shouldn't.
Then, being better informed about things I wanted, I had a look at other RDBMs, and found MySQL. Now my project is down to the real important stuff, needs no more locking (I needed locking for those multi-table virtual BLOBs in Postgres), and works much faster, and I must say, more reliable for me.
Your mileage may vary. Its always a question if Right Tool for the Right Job[TM].
Having used all 3 I'd say it was pretty much a case of using the DB that is most suitable for your application and environment.
Mysql - speed, especially when running on older hardware, I switched some systems from Postgresql to Mysql some time back and the increase in speed was significant.
Postgresql - solid and reliable, does precisely what it says it will.
Oracle - nice if you can afford it and the system to run it on, it would be my choice for bigger systems and/or critical data.
It is a pretty broad and sweeping statement to say you shouldn't use MySQL for *any* website.
If your project is small enough, it will probably be sufficient. Even Access is a reasonable solution for many problems.
Anyone who says you should use Oracle for everything is probably an Oracle consultant/developer who want you to hire them. Or Oracle, who wants you to buy your software.
Dana
Sounds like MYSQL is no more than 5 unix commands+SQL interptreter. sYou can make your own relational DBMS from the following commands and be on par with MySQL: sort, grep, cat, join, and cut.
But as to the article is right. It is very lacking for a RDBMS. But I still use it everywhere, when appropriate. Otherwise I use Postgre.
You've obviously never done anything complicated with MySQL or reloaded your database (dump and import). In the database of MP3 file locations that used to be graze.bovine.net, there would routinely be duplicate entries in unique tables as well as pure garbage that looked like half deleted records. None of this ever prevented the spider from working, but need require a lot of work to keep a usable backup.
Postgres is, IMO, a superior database. I've been using it for many years now --in one application it was a fallback database for a bank (when DB/2 on our ES/9000 failed).
It is included with many Linux distributions, including RedHat 6.x.
Sourceforge has recently added support for PostgreSQL in their project/source control system.
Is anyone willing to post some benchmarks matching performance and features of MySQL, PostgreSQL, DB/2, Oracle, SQL Server/Sybase?
This is a joke, right? I've seen many RDBMS's come right back up, without data corruption, after power loss/UPS failure/hardware failure. Naturally, in a mission-critical environment, you need backup systems, but both mirroring and replication are also vulnerable in the absence of logged rollback functionality.
No of course not, the IT-managers usually want to spend a lot of money and how should you do that with a free Unix box and MySQL?
Oops... sorry. I had thought I was speaking to a professional.
The difference between theory and practice is that, in theory, there is no difference between theory and practice.
The Jagannath article is totally correct. Look at it this way: lots of us are deeply critical of Microsoft and a great deal of our criticsm revolves around their provision of applications such as Access that appear to the casual user to be high-quality products, but in reality cut so many corners that they are unfit for any meaningful task. For example, workgroups (or even larger organizations) try to create multiuser, networked applications in Access and they usually fail miserably due to the lack of the necessary underlying features for implementing such a project.
It is much the same with MySQL. The article does not merely make vague, general criticsms but starts by explaining the basic features required of a true DBMS, then shows how MySQL either does not attempt to support them or, even worse, claims to support some of them but does not do a thorough, adequate implementation.
In the end, it is your data. If you want to sacrifice speed for reliability and integrity, go for it.
Anti: MySql sucks! How dare they call it a database ... it doesn't do X. If I post flamebait to slashdot, I want to have a guarantee it gets there.
Pro: You mean databases are needed for more than shopping carts and messageboards?
I don't know if it's good for you, but probably you should take a look at Zope.
--
Industrial space for lease in Flatlandia.
If you are a student, or just want to learn more about it, you can receive a free copy of DB2. Heck, even download the latest beta.
Wheeeee
I've used MySQL in a "mission critical" position dealing with a datbase of over 20 million records. It also grows by about 20,000 records a day.
This particular system is still used by a large UK ISP to calculate on-line charges and consequently needs to be reliable. It is. It is also more accurate than a well known telco when it comes to calculating charges.
It stays up, doesnt get corrupted, run out of extents or rely on a 90 UKP/hour support person
to come and attend to it every month.
Every single point made in the article is questionable. If I could be arsed I would write a response...but nowadays I let people get on doing their own thing rather than try to persude them otherwise. If the world wants to run windows, MSSQL or whatever let it. When it all comes tumbling down, I and all of the other Linux users in the world still smirking over 'ILOVEYOU', will still be tapping away and feeling content.
In a nutshell, Mysql:
Is really fast,
Is very very stable,
Has excellent repair tools should anything go wrong,
Is totally reliable.
OK it doesnt implement full SQL but so what ?
When you write a system in perl/c/php you get around these minor problems and end up with queries that run about 100-200% faster than the oracle equivs. Subqueries ? Pah!
I'm not against oracle/informix/sybasen't write- off MySQL just because its free. It works and in my experience is a lot less hassle than running oracle.
Veg
It seems like Dude's biggest gripe is that MySQL is claiming to be an RDBMS when it's not, but I've never found the documentation on the MySQL web site to be
particularly misleading and always thought that they are quite open about the areas that MySQL is lacking.
It could be that it's the users who mislead themselves. Some people may think "Oh! It uses SQL! It must be an RDBMS!" and then proceed to tell others about how fast their web site runs with it.
Yet another case of rtfm.
If you don't have the time to look it up, here is a brief definition for you:
Most of this thread can be divided up into two categories neatly:
What some people neglect to do before posting their comments is ask themselves two questions: It rocks for whom/what? It sucks for whom/what?
To begin with, Ben Adida never claimed that MySQL sucked for everyone/everything. His point was, they were getting tired of being asked the same question over and over again: Why does ACS not use MySQL, when everybody else and his sister seem to be using it? His answer to that is very simple. For the kind of stuff that OpenACS and ArsDigita do, MySQL is an alternative to Oracle like Photoshop is an alternative to PostgreSQL.
Ben never said MySQL wouldn't work for YOU.
To repeat, Ben is not trying to convince you that you shouldn't be using MySQL for your project, because he doesn't know what your project is. All he is saying, he has darn good reasons not to use MySQL for his project. Why do people feel they have to take issue with that, if they don't even know what OpenACS is trying to accomplish. Why don't they shut down their computer and take a break to read a few books on axiology for a change?
Let me get this straight. PostgreSQL has more features and has a more open/free license than MySQL (which isn't really FREE at all). The *only* advantage that MySQL has is a speed advantage, which can be mitigated by using faster hardware or doing better tuning. Right?
So WHY is MySQL getting so much support from the free software community? There is certainly a place for a free lightweight database product, but MySQL is NOT free. PostgreSQL is. This seems pretty significant.
Why does the so-called free software community have such a hard time picking a favorite here? I'm genuinely curious, but my stuff is running on Oracle, so I'm not exacly emotionally invested in either product.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
I don't know much about databases but slashdot seems to work every time I visit it...
You can't visit very often.
To my mind Oracle has a limited niche just like MySQL does. (I've only actually used Oracle and MySQL, so I'll just talk about those)
One of the nice things about MySQL is that the learning curve is very shallow. So you don't have to be a DBA to use it. You don't have to learn PL/SQL. If newbie to web design wants to do some cool things on the Internet with a database, MySQL will get you there very quickly.
Maybe the wizards who use the big guns find that lame, but I think it kicks ass. Why do we have to insist people use a pile driver to crack walnuts? Sure big/busy websites with mission critical database queries will be happier with Oracle. But that's a small market compared to the millions of small businesses and individuals who just need a website.
Are those folks just SOL? Do you really want them to pay for an Oracle license? And that's not the only cost. Even marginal programmers can learn to get nice things done with MySQL. Oracle isn't like that (yes, I've used both). Doing your website with Oracle cost A LOT more than doing it with MySQL. The cost difference is trivial to a fortune 500 business, but it would kill a struggling company that just wants to get on the web.
I want the Web to be all over the place and I want the cost of entry to be low. MySQL makes that happen. Oracle is a barrier to entry.
Jon Sullivan
Jon Sullivan
www.jonsullivan.com
Why do IT people have to insist that the only use for a database is "frontline applications"? This is so limited. MySQL is a fantastic entry level database.
MySQL/PHP lets me do very rapid development. Oracle lets me do very reliable things, but at a higher cost.
The big market for me are the millions of small businesses and individuals who just need a website.
Are those folks just SOL? Do you really want them to pay for an Oracle license? And that's not the only cost. Even marginal programmers can learn to get nice things done with MySQL. Oracle isn't like that (yes, I've used both). Doing your website with Oracle cost A LOT more than doing it with MySQL. The cost difference is trivial to a fortune 500 business, but it would kill a struggling company that just wants to get on the web.
Jon Sullivan
Jon Sullivan
www.jonsullivan.com
Philip Greenspun has complained about the speed of Oracle in some SQL transactions as compared to that of a script to grind over the data. This goes to show that there is a large overhead in using a RDBMS.
Learn the lesson, use the tool most suited for the job, but do not go around saying that a thing is something that it is patently not.
I found SQL for Web Nerds an useful resource in learning SQL.
Anonymous Coward:
Raw cod annoy sumo | Amorous? Candy now!
How about Slashdot? Not that important eh?
Slashdot: Sad Sloth | Dash Lots
The decription of this article is completly misleading. This article is about why these people don't use MySQL on their site, not about why no one should use MySQL.
Prevent email address forgery. Publish SPF records for y
Amen.
Prevent email address forgery. Publish SPF records for y
It seems like Dude's biggest gripe is that MySQL is claiming to be an RDBMS when it's not, but I've never found the documentation on the MySQL web site to be particularly misleading and always thought that they are quite open about the areas that MySQL is lacking.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
At least two other people got what I was saying, despite my complete lack of use of those stupid fucking emoticons. If you have to use an emoticon to convey the context of what you were saying, you're not a very good writer. If you need them to tell you where someone's being facetious or joking, you're not a very bright reader, either.
I really couldn't have been more obvious, since I was taking my numbers right from the slashdot FAQ.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Everyone knows mysql isn't a real RDBMS and no one in his right mind would use it for a real web site. In fact, we don't really know if it would scale to a large web site capable of serving, say, 600,000 to 800,000 pages on a busy week day (Or less on weekends.) The only people we know who are actively using MySQL are little old ladies storing recipes.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Declaration: I use mysql and am happy with what it does
Question: What is it about mysql that does not fit the RDBMS definition?
Looking it up on a couple sites (foldoc tech. glossary) and an unsuccessful search for Cobb's original designs.. There didn't seem to include anything that mysql didn't support. Maybe mysql doesn't support the full set of SQL92 specs, but nothing but revisionism makes that what RDBMS is.
It seems as if it were more of a value judgement... 'Apache 1.0 isn't a REAL webserver, it doesn't support HTTP/1.1'... Maybe, maybe not, you tell me, and I would like citings, not personal reflections..
I think we have a good grasp of what mysql does and does not do (for the most part). I am not trying to make it out to be [insert other db]'s equal.
A Few More Details (quoted from the article)
Instead of performing one complex query that is entirely processed on the database end, MySQL users have to perform 2 or more serial queries that each must go over inter-process or network communication between the app and the database. This significantly reduces the speed advantages of MySQL.
If a series of DB actions need to be performed in a block, MySQL requires each SQL statement to be sent from the app, again in a serial manner, again over IPC or network.
Data invariants must be maintained by application-level code, which requires building carefully-planned abstractions to guarantee integrity (for every means of accessing your DB), and even more unnecessary back-and-forth communication between the app and the database.
Only one user can write to a table at the same time. For web usage, that falls under the category of "pathetic."
Is this a good or bad time to point out that slashdot uses mySQL? This article seems to avoid the real point, all software has flaws and if you understand the software and pick the appropriate peice for your needs then everything works fine. MySQL is not exactly the most advance peice DB software on the face of the earth but what it does it does well.
How do you know it's not the hardware or bandwidth? Or the fact that posting comments relies on perl scripts, which eat CPU time?
Basically, the issue comes down to this question. Which is more "critical" in your application? The article itself and several other posters have hinted at what I'm about to say.
For basic data retrieval (ie, lots of select queries but few updates), mySQL is fine. What updates are done are probably done by only a few people, who know what they're doing, and can restore a backup if something goes catastrophically wrong. I work with this kind of stuff all the time. Someone's got mostly-static data (we get updates a couple times a year) that should go on a web page. For this, mySQL works perfectly.
For regular updates of non-critical data, mySQL is still fine. An example here is Slashdot itself. I doubt anybody would cry too much if TrollMastah's latest lyrical attempt was lost. People insert and update just as often as they select, but if something hangs halfway through, there simply isn't much being lost. This data doesn't have much intrinsic value.
For banking or other financial transactions, or important scientific research, you may very well want something more robust, like Oracle. No one wants to potentially lose tons of cash, or weeks of labor/study/analysis. If the data's truly critical, you can't afford to play around with it! You wouldn't trust a fly-by-night courier service to take those documents across town, even if they did it for free, would you? Neither should you trust an RDBMS that handles your data that way. You simply can't afford a misstep. A mistake like that might be able to cover the cost of the RDBMS itself. What's peace of mind worth to you?
Constitutionally Correct
I'd like to try out Oracle through their free development program, except their FTP server is totally inadequate(downloads at a whopping 4K/sec max.). As they say "if you can't show competence in your field of expertise, who am I to trust you?". Please Oracle, beef up your servers, the public is watching.
Furthermore, the fact that you cannot nest subqueries drastically reduces the purported speed gains -- because you have to break long queries into several small ones, and parse them at the client end rather than have the DB handle all the parameters and returning a simple result set to you. The lack of stored procedures is rather pathetic in my mind. Stored procedures offer a lot of flexibility that can benefit most development teams. The lack of foreign key constraints is laughable -- this means that you need to rely on interfaces to restrict the data being entered into the database, and in my experience this will inevitably lead to piss-poor database integrity (I'm not saying it's impossible to maintain the integrity here, just a hell of a lot harder). And finally, table level locking. Only one user can write to a table at a time. *ICK* Imagine an interactive system online that requires users inputting data (say something like turbotax). Using MySQL you are limited to one person entering / modifying data at a single time by the database. This is not a good thing if you are expecting many simultaneous users, because you will start having "transactions" queue up, and before long the whole system will hang. There is a reason most database systems use row level locking (and some drop it down further).
I would have to fully support this article, MySQL (while a great product) is not a RDBMS. It does not provide methods for ensuring data integrity thus should not be used in any situation that requires the information in the database to be "secure".
Furthermore, the fact that you cannot nest subqueries drastically reduces the purported speed gains -- because you have to break long queries into several small ones, and parse them at the client end rather than have the DB handle all the parameters and returning a simple result set to you. The lack of stored procedures is rather pathetic in my mind. Stored procedures offer a lot of flexibility that can benefit most development teams. The lack of foreign key constraints is laughable -- this means that you need to rely on interfaces to restrict the data being entered into the database, and in my experience this will inevitably lead to piss-poor database integrity (I'm not saying it's impossible to maintain the integrity here, just a hell of a lot harder). And finally, table level locking. Only one user can write to a table at a time. *ICK* Imagine an interactive system online that requires users inputting data (say something like turbotax). Using MySQL you are limited to one person entering / modifying data at a single time by the database. This is not a good thing if you are expecting many simultaneous users, because you will start having "transactions" queue up, and before long the whole system will hang. There is a reason most database systems use row level locking (and some drop it down further).
I would have to fully support this article, MySQL (while a great product) is not a RDBMS. It does not provide methods for ensuring data integrity thus should not be used in any situation that requires the information in the database to be "secure".
I just wanted to clarify the above comment a little to avoid some common misunderstandings:
Older MySQL versions are released under the GPL license and this effectively makes MySQL open source. Newer MySQL versions, even if its available in source and free for most usage, are not compliant with the Open Source definition. We, the MySQL developers, wanted to have a license that would give us the same commercial benefits the GPL gives to a library, Unfortunately, there is no such license for client/server programs. We did the next best thing and let the MySQL Unix version be free as long as the media it is distributed on is redistributeable. All in-house, including commercial, usage is free. We don't mind if people say that we are not strictly open source, but we would appreciate if the people that criticize the current license would at least agree that we have a very decent license that is very close to the open source spirit.
The intention of our license is to ensure that we can have a group of developers spend full time improving MySQL and also give free support on our mailing lists without having to compromise our development time with work on the side on other projects (Note that the money we get for MySQL licenses and support is the only funding we have for this!)
"Is this a good or bad time to point out that slashdot uses mySQL? "
I'd be interested to hear an opinion from the /. people here. I don't know much about databases but slashdot seems to work every time I visit it...
Finally someone has shouted The Emporer has no clothes. MySql is _not_ OpenSource. The developers need to be convinced that opensource is the way to go. Till then, they look like the local heroin pushers, giving out free samples, but sure to raise the price real soon now. Stick with Postgresql, it _is_ Opensource.
I said more systems than FreeBSD, I meant NetBSD. While I'm certain that all of you realized what I meant, I look foward to the 10 replies correcting this... :)
Alex
Something that kills me from some of this software is that their wasn't enough research. The Linux kernel was HEAVILY criticized (the Tennenbaum thread) because it was obsolete... this also applies to mySQL, and both criticisms are correct!
But Linux and mySQL are fast and popular. Windows 9x is popular too, your point? NT's IIS scores well on benchmarks and is fast, your point?
Popularity and speed are no excuse for correctness. Linux went through several MAJOR revisions (until 2.2 I would argue) to compensate for a bad initial design.
No disrespect for Linus, it was an impressive one man operations, and all the hobbyists did an impressive job, but there is no exuse for writing incorrect code.
We CONSTANTLY criticize Microsoft for intentionally doing things in a dumb way. Why do we do the same?
Operating System theory has solved many of the problems plaguing Linux, and solved them 10+ years before Linux was began. All the "modern" work on the Microkernel, etc, and we still don't have it? Even NT has a microkernel architecture, and they were able to support 4 platforms with minimal effort, they dropped to one for marketing, not technical reasons.
Linux supports many platforms, but at what cost? Each port seems to be such a big deal that we make a big deal out of it. If Linux had moved to a microkernel, it would be on more platforms than FreeBSD, but I digress.
In my architecture class (forget product development, and undergraduate class) we discussed atomic operations and how to provide for them. This was a very difficult thing and took a lot of time to work out. In fact, real solutions weren't really available until the late 70s.
HOWEVER, there is no excuse for pushing a database in the late 90s/early 00s without atomic operations.
Speed is NOT important. Processing power is SO cheap that saving cycles is irrelevant, especially for a constant different. There is no order of growth problem, it might take 2-3 times as long, that's irrelevant, but more horsepower.
Benchmarks that show less than an order of magnitude difference are irrelevant. If you need 3 times the power, get a 4 processor system. Do NOT sacrifice correctness to save money.
If you are doing REAL database work you need the atomic transactions and transaction rollbacks.
If I am running a bank, I need to make certain that the money is taking out of account 1 and placed in account 2 at the same time. It is not okay to remove it from 1 and if it crashes, oh well, it disappears.
In Slashdot's case, maybe it's okay, who cares if a post or two are lost. But if you are running a real site dealing with e-commerce, etc., you need to worry about it. Perhaps for discussion forums this doesn't matter, but for anything more serious, it does.
I find it interesting that there are so many obvious mistakes made in free software. The GNU stuff is solid, but that is written by academics who want correctness before anything else. RMS didn't care if EMACS was 10 times as big and 1/4 the speed if it worked all the time. mySQL takes the Microsoft approach: "yeah, it isn't correct, but few people will see the problems so they don't matter."
That's absurd.
Furthermore, this constant comparison to Microsoft products needs to stop... NOW.
It is not relavent if Linux based systems are more reliable than Windows 98. EVERYTHING is more reliable than Windows 98. (but Windows 98 is a market leader, waah, waah, waah) So what? Windows 98 is used for the ease of use and available applications.
Linux to compete on the desktop needs to beat them.
For Linux to win on the server (not Web servers, REAL servers) market, it needs to be better than the competition.
Being better than NT/IIS will allow Linux/Apache to fight in the low end, not MS. However, running a Linux system is as complicated as a Sun system. So why use Linux instead of Sun? If your only reason is cost or availability of source code that you've disputed the "Cathedral and the Bazarre" arguement.
If the reason is that it is free (like RMS argues for) than you've made a wonderful personal decision, but STOP TRYING to argue that businesses should make it, they don't care about freedom, they exist to make profits.
I think that the slashdot community (although I hope it is limited to here and not the rest of the OSS/FS community) needs a REAL wakeup call.
Instead of comparing yourself to mediocre systems, start doing things right. Instead of suggesting that you are good enough (the way MS does), aim to be correct. Instead of championing the uneducated hacker mentality, do a LITTLE research. You don't need a Ph.D, but you can read 5-10 articles on the system design by academics before you design your system, can't you? Invest 10-50 hours in research and do things RIGHT, instead of wrong.
If your persist in doing things wrong, then continue comparing yourself to Microsoft. Microsoft and some of the OSS stuff follow the same mantra: get it done, mostly working, and who cares if it is correct.
This MAY produce large gains in the marketplace, but it guarantees that we will join Microsoft in holding back the computer industry.
Alex
There is a lot more to the data path than just the database. Even though Oracle has a load of constraints and checks available, it can't check everything. So what ends up happening is the database checks some things and the scripts check the rest. That makes two sources of logic that can be out of sync and cause bugs. The company that used Oracle was plauged by corrupt data - not because of Oracle, but in spite of it. In addition, this style leads to lots of SQL hardcoded in the scripts, which becomes difficult to maintain when you've got 800 scripts. (Despite the article's claim to the contrary, even Oracle can fall victim to hardware failures. I've seen it happen)
The company I currently work for uses MySQL. There are no consistency checks AT ALL in the database, and that's fine, because we built a simple to use abstraction layer between the scripts and the database. Our scripts no longer have SQL, and the homegrown abstraction layer (DataModel.pm) is fully responsible for all the consistency checks. So far this has worked beautifully, and we have been able to build an equally complex system with far fewer programers and admins because of MySQL's simplicity.
Oracle is a fine product. Personally I can't justify the price or the complexity.
In the end, though it's all about how YOU design YOUR system. You must take into account the tools you're using. Choosing MySQL over Oracle will not in and of itself be a problem.
In this case, there is a TIMESTAMP datatype - a datetime column that auto-updates on a write to that row. This is simpler to use than triggers and works just as well.
Why do it this way? It works, it's simple, and it's fast.
If you meant a programmers interface, well, isn't that what flock() is for?
This is getting old. Please try being more creative.
Anyway, my question is, is there a fully-featured open source RDBMS out there?
PostgerSQL
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
...entirely on what "critical" means for your particular case. If your definition of "critical" doesnt require transactions and all the fancy stuff, but does require very good performance, then MySQL is great. If your do require full ACID, then you'll just have to pay the price of one of the bigger players.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Seth
$5 / month hosted VPS on linux = awesome!
So, why do I think Oracle is the best choice for an RDBMS? Oracle may be proprietary, but it hasn't fallen into the kind of rut that MS has in terms of quality. This is largely because it has lots of competition (Sybase, Informix, etc). Oracle has been developed and refined over many many years to the quality product it is now. Plus, it's documented to the point where it's almost a standard, with books on administration and PL/SQL programming published by just about every computer publishing house there is (including even open-source advocate O'Reilly).
Open source database servers like MySQL simply aren't old enough to be at the level that Oracle is now. This is not to say that it shouldn't be used by anybody. Applications where data integrity isn't critical (like this very forum) were made to run MySQL, and I think they should from a philosophical perspective. However, I'm certainly not going to put my workplace's warehouse management server on it. I admit I haven't tried PostgreSQL, but I have the feeling it's not quite Oracle, either, though I understand it's better then MySQL.
I guess what I mean to say is, if you are building a serious system that will affect lots of people's lives (not just noodling with something at home), put quality and practicality above philosophical or theoretical considerations. Open software is better in theory, and many times it is better in practice... but not all the time.
+++
+++
NO CARRIER
The article in question is quite bad. It appears as if it is trying to make a point just by throwing about the term "atomicity" and quoting someone else. The implications made by the author are that MySQL is likely to lose data or be inconsistent. That is completely false.
Using MySQL is like using any other database engine in AUTO COMMIT mode. For heavy read requirements or simplistic data models, the fact that you cannot package multiple database accesses in a single transaction is irrelevant--you simply do not need to.
The one assertion that is true is that MySQL is not an enterprise database engine. It neither claims to be one nor strives to be one. But that hardly renders it, as he calls it, a file system with a SQL front end.
It seems to me that the design of MySQL follows what Richard Gabriel calls the "New Jersey approach". He writes: The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
Read the whole thing: http://www.jwz.org/doc/worse-is-better. html
I'm new to the whole database scene. I've been using Postgres for a while, but I've been using it to do the things for which this article says MySQL should be used...
I'm very interested in this, however, because I am about to implement a large, complex database for a project I'm working on this summer/fall. So, I'd truly appreciate it if someone would quickly explain some of these terms:
ACID
atomicity
commit/rollback
transaction
Thanks.
Why do we get emotionally attached to the tool that we used for the last job? Why do we suddenly hate tools that we passed over because they didn't support the features that we required for the last job? Everybody needs to step back a few if you ask me.
It is more stable than Oracle, the fastest thing for transaction processing, and more secure then any *BSD. It scales very well. For example when IBM switched from 32 bit to 64 bit processors nobody outside of IBM new till they annouced it, not a single app was broke. What's the down side?
Nate Custer
"The poet presents his thoughts festively, on the carriage of rhythm; usually because they could not walk" Nietzsche
Locus had a particularly clean API for this.
If a program terminates abnormally (via kill or abort, a system crashes, or communications with a remote file system are lost, the file reverts to its last committed version.
These are nice file semantics to put under UNIX programs. Unmodified programs that work on files as units work fine, and if they crash, files are not corrupted. This covers most UNIX applications. Advanced applications can use commit and revert to manage clean updates to files being actively updated. It's efficient, too, because the new and old versions share unmodified disk blocks. Opening a file, appending some data, and closing the file is both cheap and atomic.
This is a successful, proven concept, but one that hasn't been seen yet in the open source world. Somebody should pick up on this concept.
The lead developer on Locus, Popek, tried a startup, Locus Computing Corporation, in the 1980s, to market the whole Locus system, but it had too much stuff in it that the UNIX community didn't think they needed back then, like heterogeneous clustering, and also had its own networking protocols. Good idea, but about 10-15 years too early.
If you're not doing transactions at all, which is common, some dumb database like Jet is probably sufficient.
MySQL is somewhere in the middle. That's is the problem. It looks superficially like a transaction-oriented database, but isn't. The open source community needs a real transaction oriented database to play in the mission-critical server world, and MySQL doesn't seem to be there yet.
I am glad someone took the time to put the word out. I looked to MySQL for writing an Intranet Recently
I read the documentation..
No triggers
No Stored procedures
No row level locking.
The list goes on not to mention the data integrity and speed (speed is not much of an issue when you throw this thing under enough load)
My point is I needed almost all of these features because the company is going to track VERY expensive monetary transactions using this thing so for a Free and pretty damn competent RDBMS I chose PostgreSQL because it has a whole lot of cool things and from the ground up I feel it is designed to be a winner and given some more time I think it will reach a very ripe enterprise level and just all around kick arse.
I Really think MySQL is cool for the quick and dirty and its a nice little product...
But bottom line if your an application writier who uses SQL as a back end and you have half a clue you would not choose MySQL anyways.
I've been using mSQL for quite some time, and only recently moved to MySQL cause it has better text field handling capabilities... But I only use linux at work, and we rarely have time to research stuff for ourselves...
So does anyone have benchmarks that can prove this? Real enchmarks with explanations and pros & cons and lessons learned? MS vs Linux style benchmarks are not what I'm looking for...
TIA
--
Peace,
Lord Omlette
AOL IM: jeanlucpikachu
[o]_O
Hey there, everyone. Does anyone know about an existing Open Source Object Oriented Database? Something like the SmallTalk database from Gemstone or an open source LDAP server? The project that I am working can benefit from the reading speed of LDAP database, during the development stage we have being using Netscape LDAP server but these guys want $2.5 dollars per entry in the database license fee. Well, our use does not justify such high prices. We use this database in order to store caching information where there can be thousands of entries per single user and the entries can be removed at some point.
:P) or an Open Source LDAP server around?
When I called up Netscape sales office they did not even understand the question at first. It seems they do not have a licensing type that covers our type of use, so they just said we have to pay for each entry anyway even if it is the same user that makes it and even if these entries are not permanent.
So, is there an Open Source Object Oriented Database (OOOODB?
You can't handle the truth.
MySQL is a great solution for displaying information on a web page, but I can't imagine ising it for more than that. Without transactions, it would be risky to use it for anything more. Who needs more risk?
http://www.tpc.org/new_result/ttperf.idc
:)
WHy isn't MySQL in this list? because it doesn't have transactions. Transactions are the most vital part of a database system that is used in critical environments. Why? because you ABSOLUTELY have to be sure some action is completed correctly OR if there was a failure, has rolled back to its initial state before the (serie of) transactions were executed.
O, and the database system on top of the performance list is a beta.
--
Never underestimate the relief of true separation of Religion and State.
I wouldn't want to put a really mission-critial database online on websites anyway, no matter what database engine is behind it.
I've seen a lot of companies putting big $$$ into putting their data online, even though they don't get more than 5 visitors a day who actually use that data...
most online store have huge, complicated database structures, even if they're only selling nothing more than just golf balls -- training people to actually understand such databases costs even more than buying the software and hardware.
don't forget... the web is merely a toy :)
Ricardo.
So you are saying that ignorance is an excuse for not delivering a system that fully works?
The honest to goodness truth of the matter is that there are a lot of people out there pawning themselves off as systems architects, building things under the expectation that they will "work"... without ever developing the concept of what a "working product" really is.
Just because some business guy doesn't know what transactional integrity is, doesn't mean that his Systems Architect's and Analyst's ignorance of it is excused.
Personally, I do not believe that MySQL is an RDBMS because it fails to support Foreign Key constraints. That's just me. I like the comment above that mentioned using it for a temporary cache, but not as a master copy...
How's this sound: Get a real DB to do your writes from, and make some kind of replication engine to go from that to MySQL for execution of your reads? The problem here is that MySQL doesn't support some of the key parts of SQL (sub selects) that can make DB queries really hum. I know most people out there building web-sites probably won't need sub-selects, it just pains me to see MySQL win off because people should be excused for their ignorance.
I think I'll stick with the guy who wrote the article, and wonder why exactly people are willing to be so negligent in their use of MySQL, but be so adamant about not using Windows.
Sam Wilson
numbsafari@hotmail.com
Damn, I have thought about getting MySQL to play with on my computers at home. But when I read that it only does table level locking, I push all of those desires right out of my mind. Even Jet 4 has row level locking, and before that it had page level locking!
/. function with just table level locking? Do you turn that off and have no locks?
How does
I have a website. It's about Macs.
MySQL may not be the biggest, or most stable, or most bullet-proof, or most feature-rich SQL server out there. But for my purposes, it does offer some distinct advantages.
- I'm hosting the site on Pair Networks (a really good hosting service, actually). They have MySQL pre-installed and configured, and it doesn't cost anything extra to use. So it's the path of least resistance.
:-) - PHP3 includes functions specifically for MySQL, so developing the code is nice and easy, which saves time and money for both me and my client.
- I'm not managing a storefront, so there is no money involved. That means going in and fixing a bug here and there will not cost anyone any money. The data involved is NOT mission critical, and a fracture in atomicity is not going to cost any money.
If you're setting up an e-commerce web server to handle hundreds of thousands of http and financial transactions a day, you're going to want to use a multi-processor box at 800MHz running Win2K Advanced Server or Solaris with redundant power fans and several RAID arrays. If you're setting up a print server for a half-dozen people in the office, you're going to throw a copy of Linux and Samba on that P/166 that has been collecting dust the last few months. It's easier, cheaper, and is a much more efficent use of resources.Similarly, if you're doing e-commerce or tracking sensitive information, you want to use an RDBMS that can take 1,000 queries per minute without missing a beat. If you're just managing personal information, an index of articles on a small news site, or something else non-mission critical, then MySQL is a perfectly sufficent and straight-forward solution. And if you're using Linux or some other Unix, the price is just right (free).
--GrouchoMarx
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Triggers, for example, should be able to be provided with almost zero cost. If a table has no trigger loaded, then there should be a very negligible cost involved.
Providing triggers and foreign keys would not prevent mySQL from having high speed reads. If someone chooses to make use of those features, they will pay a penalty, but chances are, if they want them, then the it's a cost they're willing to pay. AND they are probably already paying the cost be simulating them in client-space.
And I completely fail to see how not having stored procedures can be considers GOOD for performance. A precompiled, cached proc, should provide speed increases over repeated client queries.
Same goes for views, although the speed gain isn't as high.
The fact is that the mySQL team has chosen not to implement features which would enhance the product, not detract from it. They surely have their reasons (Other priorities/Lack of time/Lack of manpower/Laxiness/Stupidity, I don't know), but the product is incomplete, and from a purely technical point of view, incorrect.
--
Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
Speed is important.
But the correct way to provide for speed efficiency is to ensure that the software scales proportionally to the machine speed, so that throwing more hardware at the problem will work.
Table level locking (for example) can NEVER be solved sufficiently with hardware. Fast hardware might help to bring the duration of the lock down, but it really doesn't scale.
Row level locking (or even page locking) is slower in the most basic case, because it comes down to the difference between:
acquire_table()
change_row(1, row[0] )
change_row(13, row[1] )
change_row(56, row[2] )
release_table()
vs
acquire_row(1)
change_row(1, row[0] )
acquire_row(13)
change_row(13, row[1] )
acquire_row(56)
change_row(56, row[2] )
release_rows( 1, 13, 56 ) ;
That's more operations, and therefore more cost. But it scales to having 8 processors running, each accessing different rows.
Of course, if all you want is to run a small scale web site on cheap hardware, then you probably don't care about scalability (though it will come back to haunt you when the site grows) and you will probably be cursing the database the does row level locking when you just want it to hold the table and be done with it.
mySQL has a place. It's just nowhere near me.
--
Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
As stated in the MySQL RDBMS FAQ, implementing commit/rollback feature would require a complete rewrite of the DB engine. This would as well slow down a lot the speed of this RDBMS ( this would also permit to compare more fairly the speed between various RDBMSs). Mysql would be so different that only the name would stay inchanged. MySQL is probably a very bad implementation of the RDBMS concept but as long as it does the job most people expect from it (a lot of read access, a few writes to the DB), there's no problem. If you try to put a OLTP like SAP on top of it, prepare to cry...
D
The first, last, and only tech news site on the net
Record locking;
every serious db-application, web-based or not, needs locking on record-level; table-locking will not do.
Transactions / Rollback.
If a database has rollback-options, you can use those to back out of complex update; without rollback, you need a lot more code.
How to make a sig
without having an idea
PostgreSQL or any other REAL RDBMS can be tweaked for improved performance. It maybe not as fast as the glorified file system that MySQL is, but it will get pretty close.
Bottom line is that the things that REAL RDBMSs provide are key. Data is key. Consistency and atomicity are key. MySQL doesn't even try to solve the problems that RDBMSs are meant for.
New users are seduced by the talk about MySQL when not even their implementors know what atomicity means. Just read their manual. It's a joke. Calling MySQL an RDBMS is a blatant use of that acronym.
Keyword searches. I use MSSQL at work, and before version 7 came out, there was no built in way to handle keyword searches. For example, if I am searching a database of books by the title field, the actual title of the book is 'The Adventures of Tom Sawyer' and I use the words 'Tom Sawyer' in my search, by default I would have to use a very inefficient method: ie "SELECT * FROM Titles WHERE Title LIKE %Tom Sawyer%"(pseudocode here, kids) The LIKE keyword and the % sign mean that the database has to perform a much more exhaustive search than if the individual keywords were indexed.
So thats what I did. I wrote a program to associate each keyword with its primary key. That way, I could have an indexed keyword table. This dramatically sped up my search engine. The only problem with this solution is the SQL I'm using to search both keyword and main tables. It goes something like "SELECT * FROM Titles WHERE Titles.ID IN (SELECT ID FROM Keywords WHERE Keyword='Tom' AND Keyword='Sawyer'). Although this is much faster than the non-indexed way, the nested SELECT statement and the 'IN' clause are not the most efficient SQL statements.
Can anyone tell me a better way to go about this. Also, does mySQL/Postgres have anything like full-text indexing? If not, I might have something to contribute to the open source world.
No, Thursday's out. How about never - is never good for you?
There is a very good reason to use mysql: Great Tech Support
One day I had a problem with an ODBC issue and Lotus Approach. I zipped the logs and sent it to the tech support. The next day I had a DLL that solved the problem.
/. is mentioned early on in the article. I wonder if it was openacs'ed.
Have you looked at Sybase? http://www.sybase.com/products/databaseservers/lin ux/index.html
A hardware or power failure in the middle of a set of statements will break the atomicity of the block if there is no rollback capability.
nobody really expects that after a hardware failure the server is going to fully recover due to a rollback feature. You get backup systems for that horrible eventuality. Rollbacks are for people operating a system with win31 client fumbling around in a database through ODBC. In a serious system you have a web-interface such as slashdot or you have an application server (java servlets or CORBA) taking care of the buisiness logic. Your server isn't suppose to crash and if it crahes ... if, if, if. The rollback people should consider building meteorite shelters around their servers.
Transactions and triggers kill speed without protecting mission-critical data. After all it's still me who programs the logic into the system. If I can't do it right in a SQL-statement, why should I succeed with a stored procedure or a trigger? Why is a program more advanced that does lots of messy stuff and then says "rollback" instead of being a little more intelligent in the first place?
The "few more details" are no good reasons at all:
MySQL 3.23 has.
And so what? MySQL is optimized for server side applications. The App communicates with the server via a local socket or a TCP connection on a local LAN. Surely that is no bottleneck.
Right. Because nobody needs them. They obfuscate the code and are only essential in theoretical discussions about RDBMSs.
MySQL has application locking and it works wonderfully and is fast as hell. The author obviously does not know about it or assumes that the applications with direct access to the database are written by different teams with hostile intentions. In that case, good night.
An enterprise-level system will never compromise certain features for speed
No of course not, the IT-managers usually want to spend a lot of money and how should you do that with a free Unix box and MySQL? Rather use an extremely slow RDBMS with has tons of irrelevant features slowing everything down. In that way you can claim the need for a multi-mega expensive supercomputer which makes for a much nicer appearance in your server room.
What's the reason for the high suicide rate among RDBMS programmers? They keep jumping from skyscapers for fun, shouting "ROLLBACK" just befor they hit the ground.
Good Observation.
Discussion Never Hurt Anyone.
Libertarians
ummmmm...I mean 99.99999%
Is there someone on call 24x7x365 in case of an outage? Is there MAJOR industry support (IE compaq, tandem, etc...). These are some of the more major road blocks for a 'mission critical' database. SQL Server is yet to the status or say Oracle, but they DO have industry support. There are people you can call. There are %99.99999 uptime contracts that can be purchased.
How fast a database performs is dependent on many things.
The number one factor in database performance is design and application efficiency. A poorly designed application or database structure will drag even the swiftest of database servers regardless of the RDBMS.
It's been well established throughout the posts that mySQL doesn't handle row level locking, constraints, stored procedures, and triggers. These features have a huge impact on database performance. There is no disputing mySQL's speed at reading, but that is only half of the equation. The fact of the matter is that mySQL has the potential to perform very poorly when taken outside of its core competency of decision support. Table level locking is a major limitation. Without row level locking, the table is going to experience contention, which could lead to some major performance loss depending on the amount of activity on one particular table. It is also important to note, that the absence of foreign key constraints, subqueries, stored procedures, and triggers can all negatively impact performance. The absence of those features means that application code must enforce data integrity. Constraints and procedures executed on the server hosting the database will always be faster than application code executed from a client machine or webpage.
And, I believe the author explained his position very clearly and even explained that his assessment was very clearly based on his particular needs.
MySQL in a DSS or Dynamic HTML environment is like racing a ferrari in Formula 1
MySQL in an OLTP environment is like driving a ferrari in Supercross.
"The words of the prophets are written on the Slashdot walls."
Unfortunately, many of the developers I have to work with couldn't write a well written app if their life depended on it. There are a few that do a pretty good job and produce some pretty well written code, but I still don't think I'd want to put maintaining data integrity in their hands. Not to mention the inherent overhead of using applications to maintain integrity instead of foreign keys.
"The words of the prophets are written on the Slashdot walls."
REBOOT.COM is a MSDOS program to reboot the computer. Use DEBUG.EXE the enter the hex codes, and then save the result as REBOOT.COM. Run the program whenever you need a batch file to reboot the computer.
I do find MySQL's lack of subqueries and views troublesome, but they are nothing that I can't code around (but I do keep my fingers crossed that they'll appear soon). Triggers are overrated and hard to use effectively unless you have a briliant developer designing them. FOreign-key-constraints are mainly useful for getting lines to appear on an ER diagram. Other than that they cause more trouble than they're worth.
Personally I avoid stored-procedures like the plague and will continue to until there is a standard stored-procedure language. All that stored-procedures accomplish at this point is to sometimes speed up your code with the drawback of making your system totally dependant on one particular RDBMS. When I want to provide stored-procedure like functionality I do it via an application level library, which allows me to be relatively RDBMS independant.
According to mySQL's documentation, it doesn't support complex joins (inserts), transactions, etc. that make a database ROBUST. It's perfectly fine if you want to use it as a datawarehouse or to serve dynamic webpages because it's lack of robustness translates to an increase in speed. Maybe someday it will be used as a frontline application, but not now or in the near future.
Yes, but getting a new database program is not the same as buying a new car (unless you go for Oracle).
But you are right: I should have said "don't buy a Porsche to tow your caravan".
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
As ever, it depends on what you're doing - don't use a Porche to tow your caravan.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
MySQL versus PostgreSQL was covered on Slashdot back in August 1999...
http://slashdot.org/askslash dot/99/08/10/0416205.shtml
and LinuxPlanet has an Open Source database comparison.
http://www.linuxplanet.com/lin uxplanet/reviews/204/3
--
Sometimes it's best to just let stupid people be stupid.
I origninally posted this over at Zend ( http://zend.com/phorum/read.php?num=3&id=1117&loc= 0&thread=1117 ) But I'll repost here. [I have edited some mistakes from my original post at Zend.]
It's a good article. The ArsDigita Community System (ACS) is very powerful software for the enterprise - see http://photo.net/wtr/ for more. All the points he makes about MySQL are true. But, it all boils down to what you need your website to do.
MySQL is good for:
1. low connection overhead - it doesn't take long to open a connection to the db server. This is good for those of us on shared servers who cannot run mod_php [or the likes of it] and don't have access to persistent database connections.
2. Fast reads. MySQL can read faster than any database on the web. It beats Oracle 3:1. It beats PostgresSQL by [6:1 ?]. This is good for websites like which are many reads and few updates.
3. Simplicity. Sure, MySQL doesn't have many advances features like cross table referencing, triggers, etc. But most of us don't use those features. Most of those features are db specific, meaning you can't move the code around. For smaller sites, they are not necessary.
MySQL is bad at:
1. Transactions - they don't exist in mySQL, so it fails the ACID test completely. Read: Never use MySQL to store _critical_ information. That means no ecommerce, stock information, factory inventory, payroll, etc.
But if you're using a dbms for a bbs, greeting cards, or news, it wouldn't make sense to shovel out the $50K required to set up the 18 disks required to run Oracle. So you lose a few posts in your BBS - who cares? If you're planning on $123.9 million in revenues for your enterprise ecommerce site, you want Oracle. Otherwise, keep it simple.
Regarding ACS ( http://arsdigita.com ) - their ecommerce module is very good - perhaps the best available. [snip] But, if you're just looking for a bbs or news server, don't bother with it - I haven't been too impressed with the BBS's I've seen built with ACS. I recommend sitting down and building a BBS by yourself. Check out the articles at webmonkey and get coding - it's worth the effort.
Basically, it's been said before and it will be said again, MySQL is a good read-only database. As soon as you start adding or modifying records, things change. The lack of transactions is a major issue for people handling a lot of changes. Beyond that, there are also just a large number of features MySQL simply sacrifices in the name of speed. Table-level locks are probably my biggest gripe. If you don't want to risk corruption, you've got to lock the table and as soon as you do that in MySQL, you essentially eliminate any concurrent access to that table. Oracle and many others support row-level locks. There are other issues too in terms of feature set. For example, the lack of stored-procedures, sub-selects, views, and so on can really limit the usefulness of the database under many circumstances.
MySQL is good as a read-only database for static archives, but I would choose PostgreSQL anyday over MySQL for more dynamic data, just for the fact I can use views and sub-selects. Yes, PostgreSQL doesn't have foreign keys yet, but because PostgreSQL supports triggers, you can implement foreign keys (in fact, there is an add-on module that accomplishes it in just this manner). PostgreSQL also has a usable full-text search module that is also accomplished through the use of triggers.
Go not to the Elves for counsel, for they will say both no and yes
If we want to dominate the world with Linux, we must have first class commercial software to run on it. My corporation will pay for an ORACLE DBA, not an MySQL or Postgress DBA. When your are critical bussiness activity, you need real support. I know open source often has better support that commercial software, but at some point that's not what matters. It maust exist a contractable support, someone that can be paid and contracted to answer in 24 hours. We are running Oracle and Linux very succesfully, and are happy to pay the license, the support, and everything thats necessary to tell our boss: Hey, our Linux database server with Linux works wonderfully and Oracle support help us.
I keep reading about how unstable MySQL is, and yet haven't once seen an example.
Let's seem some hard evidence to back up your flames!
I was and still am a proponent of Oracle, but it is not the end-all-be-all of my existence and does not make since in many situations. MySQL has been more than sufficient to meet most of our needs.
A single fact is worth more than infinite truth
Actually we have. We ran into trouble with the data from the other database--not MySQL And it turned out that unique indexes where not being used. MySQL screamed loud and clear when it found the dup.
Are these instances of dup records actual dup keys, or multiple "same" records with diferent key values?
But you are correct in that we are keeping it simple. We rely on platform independance and don't dive too deeply into extented functionality. So far MySQL has proven itself capable and reliable.
Unique features such as proceedures linking and what not
But I guess it all comes down to where do you want certain database features/functions handled?
Example: Linking a username to a post on a message board.
Once the user is deleted is it the job of the database
Or the job your application to take care of the stale users post?
On one hand your application can't query everytime it connects
To make sure that all the user names are valid, but
you have to consider it's not the database's core
responsibilty to process data, just store it. These things alike are nice
features added in to a basic database with about a 15,000$ overhand pelt on top just to make programming easier.
Personally I believe it's the appliacations or system softwares responsibilty to handle that sort of auditing. ;-) j/k trevor@xmission.com
I fully agree that mysql should have more crash resistant techniques such as rollback.
But for godsake just because it can't dynamically link data doesn't make it non-usable.
It's your applications job to deal with the data
It's mysql's job to store the data.
If you want to pay 15,000$ extra for spoofy logos and
features such as that go ahead, i'll just spend 10 extra minutes
programming the functions I need into my application
that can do the exact same things as oracle for a significantly lower price.
I guess it comes down that Oracle programmers are lazy.
Ahh, but then I disagree.
The evil empire certainly improved the interface and manageability of SQL Server. The database engine and the underlying architecture are still very much the same.
Sybase had a huge problem when they rushed System 10 to the market. It was buggy up to the point of unusable initially and not very scaleable. System XI is an excellent product. Very stable, quite scaleable and blazing fast.
I worked for a huge financial project that uses Sybase and benchmarked nine million transactions (each constituting ~ 8 TPC/C transactions) per day. Very stable, very reliable and very maintainable.
Where Sybase really kicks ass is when it comes to distributed data architectures. Name one product that is comparable to Sybase Replication Server. Granted that it has a steep learning curve and it' s far from easy to maintain it's unbelievable flexible and powerfull.
I agree that the DB management is far from sexy, in fact everything I've seen in terms of DBA tools from Sybase Inc. can be considered utter crap.
But who cares ? In a really mission critical environment the last thing you want is to point and click. You need scripts for all maintenance tasks and you need to treat them as source code. The alternative is to run fast and far in case of a desaster.
When you know what you do Adaptive Server is a cutting edge database which has the added advantage to be packed (11.0.3.3) with most Linux distributions.
/z
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
I am MySQL team member and will post some comments about some confusing wrong comments here: 1. Is MySQL open source? After reading all these comments I am not sure anymore that we speak in same terms. At all my knowledge this is what we can get on URL http://web.mysql.com/Downloads/MySQL-3.23/mysql-3. 23.14-alpha.tar.gz is called MySQL source. This do not miss even a one line of it's source. Why some people claim that MySQL isn't open source? I am glad to correct my opinions about terms if they are wrong. 2. If you, your boss or whoever says that transactions are essential for you then of course you should use best choice for you. Why to flamewar around it. 3. GNU. MySQL is not GNU software and not claimed to be it. We have published some versions under GNU but only few of them. Why to flame around this? MySQL if free most most types usage but not for all. Exact information can be accessed on: http://web.mysql.com/Manual_chapter/manual_Licensi ng_and_Support.html#Licensing_and_Suppor t