Slashdot Mirror
MySQL & Open Source Code Quality
dozek writes "Perhaps another rung for the Open Source model of software development, eWeek reports that an independent study of the MySQL source code found it to be "in fact six times better than that of comparable commercial, proprietary code." You can read the eWeek write-up or the actual research paper (reg. required)."
Six times better? I didn't know it was possible to quantify code quality in that matter. Interesting.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
Woot. Pretty amazing, but with so many eyes and not at all confined by the "9-5" grind, it is almost expected.
...until I release my MySQL source code to the open source community. Then that 6x multiplier will drop down to 2x.
Yeah, it's really that bad. Gets the job done, though. Hell to maintain. Probably would've helped if I documented any of it.
Maybe I should read that Code Complete book I keep meaning to read sometime.
Creator of the popular web game Proximity
Perhaps another rung for the Open Source model of software development
Uhh... no.
It's is a glowing report for this particular open source project but that brush shouldn't be used to paint all open source. That will just lull open source developers into a false sense of euphoric contentment. Code quality didn't get this far by having a fixed target, that target should be a carrot on a stick that will never quite be reached.
Trolling is a art,
Through its analysis, Reasoning concluded that the commercial average defect density--covering 200 recent projects and totaling 35 million lines of commercial code--came to 0.57 defects per thousand lines of code
Um, so they just guessed that the code was six times better. Okay.
Undoubtedly()
{
when();
you = measure(quality);
in.defects();
per->lines_of(code, anyone);
can = write(good, solid, code);
}
MySQL is not touted as Enterprise because its not Enterprise. Sure, it's fine for running Slashdot, but I wouldn't want it storing mission critical data. Oracle may be slower, but I'd much rather trust it to make sure my data is properly stored than MySQL.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
"Reasoning performed its independent analysis using defect density as a prime quality indicator. Defined as the number of defects found per thousand lines of code, MySQL's defect density registered as 0.09 defects per thousand lines of source code. Through its analysis, Reasoning concluded that the commercial average defect density--covering 200 recent projects and totaling 35 million lines of commercial code--came to 0.57 defects per thousand lines of code."
Jason Lotito
...they quantified it by dividing verified defects by lines of code. MySQL had 0.09 bugs/KLOC while the "commercial" defect density was 0.53 bugs/KLOC. (Their use of the term "commercial" confused me since MySQL is, after all, a "commercial" project, just an open-source one.)
All's true that is mistrusted
This article must have been written by supporters of closed software. The ratio of 0.57/0.09 is 6.333~ and the article states it is 6. Clearly FUD. Let the flaming begin!
And line of code for line of code there are less known errors in MySQL than there are assumed/predicted/mean errors in their commercial counterparts, but that doesn't answer the question of how does MySQL compare performance-wise to Oracle or <flameretardent coating>MS SQL 2003</flameretardent coating>
Just my 0.03 (adjusted for inflation)
Music is everybody's possession.
It's only publishers who think that people own it.
Fuck Beta
~John Lenno
I agree with you that you can't simply measure quality but...
If you just RTFA, you'll see that is not "6 times better" but "6 times less bugs found then the average on commercial products"
The only thing wrong in the article:
They should replace the term "commercial" with "closed source", because Mysql is also a commercial product and what makes it different is the open source model.
As strong proponent of MySQL, I'd be very curious to see how it stacks up in those regards.
listen to "Stay Away From The Guy With The Funny Eyes" by DJ Bob Hoskins Going Mental In A Dustbin before you go to bed, and clinical psychology tells us that when you wake up in the morning, you will be 17.3% safer.
- doctea
Anyone know how this one is faring? Will it ever be released? It's based on GCC, right? How many students can it pass between until it's "distribution"?
The reason I'm asking is because I saw that one member of the team has jumped over to a company called Coverity where one can read:
I just think it'd be horrible if they used the GPL'ed GCC to develop their methods (having access to a full portable compiler onto which to do research and development is hardly a "small thing"), and then lock these same methods away from the community.
I'm grateful for their work on checking linux, but really... this smells bad, IMHO.
(If you don't know what I'm taking about, don't assume it's off-topic, okay? The Standford Checker is a related topic to the Reasoning analysis of MySQL, and I'm not sure we'll ever have a _better_ fitting topic to discuss this)
Belief is the currency of delusion.
I do believe that Open Source is better than proprietory. Faults per 1000 lines of code may seem like a valid scale, but I think it is indicatory at best, not proof.
* It does not take into account the design of the software. This is often as important as the actual quality of the code.
* It does not take into account the kind of errors. This is related to the first, but a buffer overflow that allows root access is worse than a failed instruction.
* It does not even take the length of lines into account. Shortening the lines could lower the number, without actually changing anything.
So, small victory, but the race goes on.
the pun is mightier than the sword
This just looks like some quasi-scientific statement, trying to express things as a number that really don't fit such a representation. For example, as the number of defects decreases, it becomes increasingly more difficult to find the ones that are left. And is code that contains no bugs at all infinitely much better than code that contains a single bug which hardly ever occurs?
The main difference between open and *MOST* closed code is the fact that the early release of closed code means mucho mas money to corporate pigs and dogs, thus, proper requirements analysis, design, coding and testing are usually pummeled in the name of happy-go-lucky capitalism. "It will be ready when it is ready." -Carmack "I love America!" -Murphy
HAD
And that's because...of nothing in particular? At least give a reason *why* you have an opinion, if you're gonna do that. Is it some vague feeling of fear? What's the reason?
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
I don't think MySQL is intended to be `comparable' to OracleSQL, but someone else may be able to clarify.
philcrissman.com.
Since we're measuring Defects per 1000 lines, perhaps calling them "Gates" or "Ballmers" might be more appropriate.
yeah but MS is touting that MSSQL Is Enterprise class. which I find absolutely hilarious...
The MCSE's here keeps asking for MS SQL to replace oracle.
oracle is a great DB, but the difference is between Microsoft utter crap and MySQL.
no contest MySQL is much better than MSSQL.
I've used mySQL, Oracle, MS SQL, DB2, and MSDE. I'm not sure I get your comment about MS SQL server. Like any other RDBMS, a little performance tuning goes a long way. As a matter of fact, until Oracle's release of 10g, MS SQL beat all commercial offerings in the TPC benchmarks.
MS has a buggy os and an awful model for business practice, but I think MS SQL server is a fairly nice offering. It's too bad it only runs on Windows servers though.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
if only there were some sort of linking technique i could use to direct you toward a news article that explains all that to you. you could read the article the link directs you to, and you'd have the information you requested. too bad telepathy hasnt been discovered yet, otherwise i'd transmit it to you that way.
Neener neener!
Now, I'm sure we can all be very mature about this...
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
This "proves" that MySQL is better than commercial offerings. Good. A lot of people knew that. Hats off to the developers. But...
1. This cannot be generalized into a property of all open source projects.
2. It's more a tribute to the architecture and original core developers of MySQL than anything else.
3. Realize that even though MySQL is an open source product, MySQL AB is the *company* that organizes and pays for MySQL development. So, again, you can't generalize this into something that covers late night hackers working on personal projects in their basements (the open source geek fantasy).
MySQL is awesome! But let's be careful about this story, okay? It's the over-generalization that gives OSS/Linux advocates a bad name ("The Gimp is equivalent to Photoshop!").
How many lines of code are there in a Library Of Congress?!
Because there are portions of the MySQL code that are just painful to look at.
Take for instance the part that takes as input the key index size and calculates internal buffer sizes. The option's size is an unsigned long long, but they cast it to an unsigned long all over the place, do in-place bitshifting on the cast (and cause it to wrap -- try specifying 4G for your key index sometime and you'll get 0), and the quality of code in that case is just painfully horrible to look at or even figure out what it's doing.
I could only shudder to think what the quality of the commercial product looked like, in comparison. Hell, I'll have nightmares if I consider the quality of MySQL++ as a comparison..
--jordan
I imagine that I could write such a poor bubble-sort program that would have no errors - but would take a programmer a week to figure out what it does because it is over 5000 lines long...
From excellent karma to terible karma with a single +5 funny post...
How buggy is MySQL is compared to say PostSQL, FileBird, etc. MySQL tends to crumple under load, while PostSQL keeps going.
Need a particular reason? Take your pick. http://sql-info.de/mysql/gotchas.html
no, that would be defects per 10 lines of code
I'm a chainsmokin' alcoholic sociopath, so-ci-o-path
RTFA. They quantify it by measuring Defects per thousand lines of code. They they compare those numbers, viola... quantification.
00101010
So how many of the eWeek people do you think saw the code to MS SQL Server or Oracal SQL? I am hightly doubting that they even were able to get to the front door to knock on either of the doors to ask if they could see the code. I mean this just looks like pure propoganda to anybody that has half a brain and keeps up with the industry.
Don't get me wrong I love MySQL, but these types of articles are just as bad as the people saying that MacOS X isn't that secure because of the less users on it. Or the guy claiming that MS is way superior in the Internet Server world. These type of articles are just there to cause controversy and seperate us as a community Mac/Windows/Linux combined.
I am not putting any merrit in this article and neither should you.
Slashdot is a bad commercial for MySQL. Maybe it is the SlashCode, and not MySQL, but the Slashdot database regularly becomes confused, such as posting a comment to the wrong story.
This is a good example of developing high quality software versus a piece of crap with lots of "features".
MySQL doesn't have some features such as stored procs or views, but what is implemented is pretty solid, which is important for a database.
Wasn't it 6.56 times better?
We suffer more in our imagination than in reality. - Seneca
Up until recently, MySQL had no transaction or atomic operation support. As such, you need to write application code to trap problems. Whereas with Oracle, when you run an atomic operation, you know without certainty whether the query failed in its entirety. I also believe stored procedure support is somewhat lacking in MySQL (however, there is that new Java function support). The MySQL 3 tree does not enforce constraints which is something most essential for data integrity. MySQL does not have subrow locking, whereas enterprise databases do. Once again, MySQL is great. I use it. However, it is not enterprise.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
There's a hell of a difference between 235,667 lines of code and 35 million lines of code. Just like there's a difference between 1000 lines of code and 235,667 lines of code. That is, the more line of code, the more likely a defect will survive.
Remember the 'Open Source' IE patch that came out recently? That had a few bugs in - buffer overflows, that sort of thing. Luckily, being Open Source, they got spotted quickly.
Now apply the 'Rule of 6 times' to Microsoft's closed source IE patches...
You spelt "walla" wrong.
;-)
Handy tip for you there
Bush and Blair ate my sig!
Anybody care to enlighten me on how they came up with that number?
And you don't think Oracle has any gotchas? Oh boy, wait till you grow up:)
First off, I think MySQL is a fantastic product. Its the perfect mix of speed and ease of use well suited for small to medium sized datastores where speed and relaibility are a must. That being said, I think it's unfair to describe this product alongside others such as Oracle, MSSQL (blow me guys, its a great product) and even PostgreSQL and SAP DB (which is be best OpenSource option in my opinion). The codebase for MySQL will never acheive the magnitude of the aforementioned products so it should be used that way. Just my 2 cents.
My mother never saw the irony in calling me a son-of-a-bitch.
If that had been your first post, you'd have gotten some mod points.
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
How much sampling did they do? Or did they just take MySQL and some bum-wad county program and compare them?
/. would be able to see past stereotypes already.
That's like saying all negros are criminals because the TV show COPS shows them being criminals.
I'd think a left-wing pro commie gaggle of hippies such as
Live in the now man!
Someday, I'll have a real sig.
Let's call it the Linus !!
Great, then we'll have people arguing that we should call it the GNU/Linus!
One man's -1 Flamebait is another man's +5 Funny.
marketing sites only have 3% more fake/fudged stats then news sites.
and 74.6% of all stats are made up anyways.
Well, you're right, but i wouldn't want to be the one to honour Gates or Ballmer with a unit's name.
Well, the reason I mention version 3 is because it's widely deployed. Debian stable, for instance, is still on 3.23.49-8.5.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
You forgot to make main void.
I'm not sure what point you're arguing here. Of course there's nothing stopping you from building commercial software using GCC, but the Standford Checker is -- as far as I know (and I could be wrong) -- built ON gcc, not only with. As in, the meta-compilation framework was added to gcc as backend (and if it wasn't, this is all moot, but I seem to recall that it was. Doubt it was LLVM)
Forget the legalities, I'm sure they're withing their _RIGHTS_ to take the research and move it into a compoany, but is it -- assuming my reasoning and background is correct -- ethical? Should we condone it? Is it within the spirit of the GPL?
Belief is the currency of delusion.
So.. if they can find x number of "defects" per y lines of code...
Why not fix them?
I'm in the midst of upgrading a SQL Server 2000 installation. MS issued their latest patch in August - a mere 56 MB patch. Hopefully that will fix some of the flakiness I've been seeing.
[Insert pithy quote here]
I find the MySQL gotchas frightening:
Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.
Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.
# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your
Higher levels of investment in development may yield things like better test labs, more test boxes, more test OSes, easier benchmark simulation, etc. More dollars means that development can take place on more special-case nodes, and devote time to specific optimizations.
I want to delete my account but Slashdot doesn't allow it.
is code that contains no bugs at all infinitely much better than code that contains a single bug which hardly ever occurs?
even if i consider this theoretical question i think it depends on the fact what the software is used for. i am with you when we talk about a mediaplayer or a game, but if we talk about surgical or airplanecontrol software my view changes radical.
This study really only shows the defects in the MySQL code base and nothing about proprietary database source code.
:-(
The analysis of the proprietary databases' source code is by guessing as they don't have access to the proprietary source code and therefore can not make such a claim.
While I have no doubt that the open source model is superior in development, this study, unfortunately, proves nothing. Smoke and mirrors..
jason
No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil
those are just bugs! what about lack of features?
at least there's row-level locking now... finally.
2 1337 4 u!
Let's just break it down to error per Line of Code. Since LOC is already taken as a measurement unit (Which I still have problems with, as the LOC keeps growing, making it like inflation, I mean seriously, How many LOC's could the egyptians have stored in the pyramids), so we will use Ballmers. This particular example is measured in kiloBallmers, and could have been expressed as gigaBallmers just as easily.
Usually in the open source world, there are two major implementations of a software concept and several minor ones, and usually commercial rivarly as well.
Examples
Editors such as Vim, Notepad, Kedit, BBedit, Textpad, nano
GUI's such as Explorer, Finder, KDE, Gnome, XFeaces, Box.
Kernelss such as ntkrnl.exe, linux, darwin.
Each one has varying bugs and complexity, There is a link between ones market share, feature set and lines of code.
For example, in Gnome vs KDE for example, I find KDE to be less buggy even though its more complex, because it has more users (90% of distros use it be default) and so there are more people finding faults, while also adding more features as well. Gnome 2.4 shockingly had LESS features than 2.2, because the code base had became so buggy that the developers had to remove a lot of the functionallty to stablize.
MS SQL is basically a revamped Sybase. So, on UNIX & Linux you could use Sybase ASE.
open sourcers don't necessarily get paid to release code, so they don't have the luxury of releasing shit just so they can keep their jobs by releasing updates for the next 5 years. when a commercial product finally DOES become useable they make a whole new buggy/bloated product that they can release fixes and patches for.
"...if you don't like your job, you don't strike. You just go in every day and do it really half-assed..." -Homer
This is proof positive that the marketing engine has started churning in the Linux / Open Source arena. The quoted statistics are meaningless. Here are is a short list of things (in no particular order) that are wrong with this "study" (who paid for it anyway?):
Lines of code is meaningless as a reliable measure of anything. The most this number can be used for is for assessing the high level complexity (i.e. simple, non-trivial, or hard) of an application / code construct. It is absolutely pointless to compare two different applications against each other by lines of code. This means that you can say that one is non-trivial and the other is complex or you can say that both are complex, but there is no valid way of determining (by using this particular metric) that one application is more complex than the other. I believe this is the fundamental flaw in this "study".
The study igores capabilities. If application A has feature a, b, and c, and application B has features a, b, c, d, e, f, g, h , is it even meaningful to compare the number of defects detected between applications A and B? And no - normalizing it by lines of code is not valid (see previous point).
Testing methodology : from the defects quoted in the article, it appears as if they "study" did white box testing on MySQL. This is hardly complete. While null pointer dereferences are certainly terrible, I would be also very very concerned about bugs pertaining to SQL capabilites, data integrity, performance, etc. If I go out and do a comparison of RDBMS's for a client, my report wouldnt be complete at all without covering these areas. How come the "study" doesnt mention any of these things?
Lets face it : this is a paid propaganda article by the marketing machinery. Much like Microsoft has done in the past.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
It is really embarassing to have bad code with your name on it, released to the public.
Not only that, but there is a small percentage of coders when presented with an ugly solution to a problem, will pretty it up, just "because". And it is a good way to get known in the OSS world.
Unlike the corporate world, working but ugly code is hidden deeper and deeper, and people go out of their way to avoid it.
I think you need some help too. I've never seen C code with line numbers, or with print instead of printf. and where are your semi-colons? Back to Qbasic with you!
These are exceptions and highlighted, it does not in anyway reflect the entire model as a whole as we can plainly see buy looking around.
There is a hell of alot more reliable closed source software out there than open source.
Like it or not fanboys, its reality.
Just add a bunch of creatively placed linefeeds, you can easily get back up to the 6X number (based on lines of code).
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
Too bad ADO Blobs still don't work...
Seen lots of intelligent comments about lenght of lines and potential bloat skewing the results, but there is one more issue to consider: design.
No matter how good the coding itself, if the design is broken, the tool is broken, period.
And MySQL has a broken design. So broken that the upgrade path isn't MySQL X or something the like, but MaxSQL -- in fact, rebranded SAPdb. That SAPdb is at most at Oracle v7.2 levels tells lots about MySQL.
I could be more specific, but do your own research in Google -- lack of SQL compliance, lack of features to enable declarative coding at the server instead of procedural client code, and so on.
Now, the interesting part. Suppose MySQL AB would have a sudden insight and repent of their un-SQL, anti-relational ways. Unlikely, you say; yet possible. Now suddenly they have to recode, or change drastically the current code. The resulting tool will be probably much bigger than the current, because SQL is baroque; or even worse than much bigger, because of MySQL backwards compatibility.
The sheer bloat will make even this faulty measure of bugs/KLoC skyrocket. Now, run the comparision again...
Not to say SQL compliance shouldn't be attained. In fact, bloat in the SQL DBMS is a more than good enough tradeoff against bloat in the application. The ideal would be a RDBMS, but while there isn't a MyDataphor a SQL DBMS should do.
Even today, I don't care about comparing to, say, Oracle or MS SQL Server. IBM DB2 would be a better baseline, but best of all the real competitors: PostgreSQL and Alphora Dataphor.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
So Oracle is mission critical to our operation. But I hate their licensing structure enough that I'd love to go with something like MySQL. Reliability and speed are very important.
Does anyone have any option, backed by experience in the matter, on switching from Oracle to MySQL. A good or bad idea? Disregard cost of the actual switch. I'm looking at this from the standpoint of technical merit and capability.
David Whatley
I'm a little confused. I thought I understood how to make profit with the GPL, but now I'm not sure.
MySQL GPL'ed all their products. (presumably so they could get developers and bug-fixes to their product for no charge.) However, they offer "commercial" licenses for people who want to integrate MySQL into their software, but don't want to GPL it. How can they do that? Presumably, any improvements/bugfixes/modifications that came from the community would be GPL, and therefore cannot be re-integrated under a more restricted license. I'm a little confused here. How can they take code that has been released under the GPL and turn around and release it under a more restrictive license?
Actually int with a return value to indicate execution status for script kiddies in theyre shells (ala linux fanboys that cant use WBEM industry standard for machine management)
Not checking the return status of printf for errors looks like a defect to me.
There is a bad Moderator amongst you - giving you a bad name! The nefarious moderator marked the above post redundant - Never checking the timestamp on the post. If they did. they would find that the above first post on the subject, and cannot be redundant!
Your question is actually a valid one, but, come on... The names are PostgreSQL and Firebird.
(which ranged from a few uninitialized variables prior to use
Are you out of your vulcan mind? That's instant GIGO!
.
It lacks stored procedures, yes. But that's certainly just the top it. I wouldn't even call it a real DBMS, as it lacks almost all advanced features: Transactions (begin, commit and rollback), simple sub-selects (or is that included nowadays?), referential integrity, triggers, and I could go on.
But it's fast (due to the smaller scale), I'll have to admit that. But to compare the speed of MySQL to the large enterprise DBMS's is simply unfair as MySQL serves a different purpose.
By including the use of 'stdio.h' to which we (SCO) own the rights to, you have violated the DMCA.
MrHanky, you now must either pay us for the use of said file ($699) or ceist and decist.
We hold rights to your future earnings from your use of our file, and we option the rights to your childrens earnings.
Thank you
Daryl
soo so sorry... It just popped into my head...
Why worry? Each of us is wearing an unlicensed "nucular" accelerator on his back.
Sig changed for readability by G.W.
The numbers in the article are too fuzzy to draw meaningful conclusions, but I wonder if there was a correlation between size of project and bugs/KLOC. Most comp-sci types agree that the difficulty of writing good code grows polynomially with a project's size and not linearly. So, is MySQL more bugfree than a commercial program of its own size, or one with a codebase 10 times larger? Maybe it was competing with 199 little bugless programs and one giant, riddled behemoth.
I guess my main point is that the article provides some data but no information at all. The original study might've, but the summary could have said "MySQL is more purple than commercial code" for all the supporting evidence it gave.
Dewey, what part of this looks like authorities should be involved?
..are in the header file but obviously you can't show those as they are belong to SCO...
To Terminate, or not to Terminate, that's the question - SCSIROB
there are foreign key constraints, but only on certain table types, and only in certain versions, and only on certain column types.
on mysql 3.x, the table types that support foreign key constraints don't support transactions, and vice versa.
OT: This is just a dummy post to cancel an accidental incorrect moderation. Sorry
I'm sorry but this is a joke. They do not tell what proprietary code they looked at to make this conclusion. They do not even say if they compared this to other Commercial database solutions. Obviously this is good code but if its not compared against other databases I don't really see the point.
OMG! And Windows 98 didn't support fast user switching!
If you are going to bitch about something, at least bitch about the latest version of it. MySQL 4.x has been out for over two years.
Tuus crepidae innexilis sunt.
Which commercial counterparts? oracle, db2, informix? I seriously doubt it - and eWeek didn't say.
Given that a database is a core software component I'd *expect* a far lower defect density than you'd typically find in an application or especially a desktop application.
Good to hear that they're working on reducing their defects, but please - this is hardly a big deal.
Used the early 4.0 stuff on a few projects only bug that bit me was a release where the bits to bind it to an ip address were borked. Checked it's mailing list and it was a issue that was resolved, and fix was in the next release also there was a workaround for the release I was using.
Say what you want but it was solid backend for
the program using in my case.
Great tools do only ONE thing, but do that ONE thing very, very well.
anything open sourced in that domain?
4 funny?
Wow... In that case.
A pig fell in the mud.
Hahahahahahaha!!!!
Yeah, it was supposed to be a joke. Too bad nobody else thought it was funny. But that's what you get after an all night hacking session. Or so I've heard. I was, of course, only playing games.
That they're filing suit against MYSQL for violating their IP on code quality.
http://www.reasoning.com/pdf/MySQL_Defect_Report.p dfo rt.p dfr .pdf
http://www.reasoning.com/pdf/MySQL_Metric_Rep
http://www.reasoning.com/pdf/MySQL_White_Pape
MySQL Defect Report: http://www.reasoning.com/pdf/MySQL_Defect_Report.p df p df f
MySQL Metric Report: http://www.reasoning.com/pdf/MySQL_Metric_Report.
MySQL White Paper: http://www.reasoning.com/pdf/MySQL_White_Paper.pd
Can be easily worked around. Who cares.
Real DBAs care. The point is you shoudn't have to work around it.
A pain in the butt, but in order to have stored procedures you need a procedural language
Ahh the last cry of the desparate - "that's a stupid feature - nobody needs that!" Despite the fact that having to code around it in the app makes the whole thing slower (I thought MySQL was all about speed?) And increases development time.
In order to have a trigger you have to have a procedural language.
Another "that's a bogus feature" excuse.
Any foreign key constraint may be expressed as a join and this is usually considerably faster.
Do you even know what a foreign key is, or how it's used? It certainly doesn't sound like it. "You don't need the database to ensure the integrity of your data, because you can just check it manually!"
I think MySQL is good for a website and all, for reasons listed above. If I were looking for a database a little more robust, and that has more in common with the commercial leader, Oracle...I'd go for PostgreSQL. Has transactions, procedural language..etc.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
It's called "PEER REVIEW" and it does make your code better. Closed-source software vendors may want to take note.
-ted
It does indeed sound a bit like that, and with good reason. If you notice, the "indepedent review" was carried out by Reasoning, Inc., and we've heard of them before in these parts.
For the benefit of those who haven't seen this trollfest^H^H^H^H^H^H^H^H^Hstory in its previous incarnations, Reasoning's services spot what some people call "systematic" errors, things like NULL pointer dereferencing or the use of uninitialised variables. As many people note every time this subject comes up, any smart development team will use a tool like Lint to check their code anyway, as a required step before check-in and/or as a regular, automated check of the entire codebase, and so any smart development team should find all such errors immediately. IOWs, it's grossly unfair to compare open and closed source "code quality" on this basis. Any project that has errors like this in it at all isn't serious about quality, and it shouldn't take an external study to point this out.
Serious code quality is not dictated by how many mechanical errors there are that slip through because of weaknesses in the implementation language. Rather, it is indicated by how many "genuine" logic errors -- cases where the output differs unintentionally from the specifications -- there are. Of course, no automated process can identify those, but to get a meaningful comparison of code quality, you'd need to investigate that aspect, rather than kindergarten mistakes.
There are other objections to their principal metric as well. For starters, source code layout is not normally significant in C, C++ or Java, so any metric based on line count is going to be flawed at best. But the big objection is that they're talking about childish mistakes, and comparing supposedly world class software based on childish mistakes isn't helpful (except to dispel the myth that some big name products have sensible development processes).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
How does the code quality of the free MySQL v4.0.17 compare with the priced MySQL v4.1? They're both open source (source code downloads), but 4.1 has a proprietary non-GPL license with a price attached. What do you get for your money, other than "new features"?
--
make install -not war
Hint: it is near the bottom
I was under the impression that the InnoDB table type in MySQL supported transactions - in the real sense of the word. (I was shocked to read the user manual where the MySQL developers explained why transactions were overrated...)
/.), so I could care less about triggers/etc - though obviously they are important. I do think that by using InnoDB I'm covered as far as transactions go, however.
I'm all for databases having an option to turn off transaction tracking for cases where you have high loads and you don't need the protection it provides. However, I think that most applications would benefit from transactional support.
Right now all MySQL is doing is tracking hits on my website (hmm - maybe if I posted the URL I'd get a free load test care of
So its useful for what it was intended for?
MySQL Gets Functions in Java
My point was that MySQL not only lacks transactions and sp's, it also lacks quite a few other features which are commonly used by other (real) DBMS's.
But as far as the possibily to turn off support for transactions, I think you're absoluty right.
I have a reasonably nice mySQL database set up to manage my research data. It's set up so that anyone in-house can access it using a web browser, extract reports, etc. I think it's pretty slick, and it's orders of magnitude better than what they were using before I got here. (That would be spreadsheets, all in different formats, and all with different coding of entities. Sheesh!)
Anyway, someone else in the same building is collecting the same kind of data, identical format, just in a different region. He's got his tech building a new database in Access. As far as I can tell, this duplication of effort is just because they both have Access as part of MS Office. I keep trying to encourage them to just piggy-back on my database. Because of the web server aspect, they don't need to be running linux or mySQL themselves, so there's no "geek factor" involved. Neither of them already know Access, so whatever they do, they'll be learning it from scratch.
My feeling is that this is a wasted effort on their part. The only downside that I can think of is that I'll end up supporting their data as well as mine, since we have no IT support. From their point of view, there's no real drawbacks that I can think of, but they're still very reluctant.
Anyone have any ammunition I can use to support my case?
I prefer to be called Evil Scientist.
I really don't know that I understand (or even agree with) the quality statement.
;-)
I routinely work with DB2 UDB and Sybase ASE, less often with Oracle. All of those I can be assured of recovery with and all I would be comfortable deploying in business environment.
I keep MySQL on my laptop because it's a quick'n'dirty database for me to play in and prototype with. I let customers (I'm a gun-for-hire) deploy it for non-business-critical applications such as web site backends, mailing databases, etc. Stuff were rollbacks and point-in-time recovery are less critical.
So given the above, how can you really claim the code is really better "qaulity"? It's like comparing apples and oranges. A Toyoya Corolla is certainly a well built and reliable car, but comparing it to a Hummer or a Porsche is a bit more than subjective.
Maybe the 'quality' they referring to is really just nice indents and comments
Just my 2 cents (Canadian),
-psy
In my opinion, there is no substantial difference in code quality between open source software and proprietary software.
/usr/bin/env. Kind of confusing %-)
/usr/local, which is the default location) and Perl 5, just to compile some C/C++-Code?
:-) is Sun JVM vs. GCJ's libjava. I compiled a very complex multithreaded application using GCJ; it worked fine on uniprocessor machines, but it randomly deadlocked on my multiprocessor server. Finally I found out, that libjava is broken on SMP machines. That doesn't mean, that libjava's code quality is bad; but it still means, that some other Java-Libraries (those of some virtual machines) are more mature, and possibly better tested.
I have seen a lot of very buggy commercial software (including nVidia drivers, IBM's LANManager Services for OS/2, lots of Microsoft's services and utilities in Windows 2000 (for example, "TCP/IP Helper Service") and Netscape 4.7).
On the other hand, I have also seen very bad code quality in open source products - for example, GTK+ (actually, the really bad thing about GTK+ is primarily its install scripts, makefiles and such). Compiling and installing GTK+ on anything else than on a GNU/Linux-machine is some kind of an adventure, while its commercial counterpart, Qt from trolltech, can be compiled quite easily.
- I set the PKGCONFIG env variable before running 'configure'. It worked quite well until line 27.000 (or so) in 'configure', where the variable's content was suddenly gone (BTW, I really dislike debugging 28.000+ line shellscripts). I tried to 'configure' with bourne shell and with korn shell 93.
- It assumes, you have Perl installed (if it's not in your PATH, 'configure' creates funny things like "#! -w" instead of "#!/path/to/perl -w"). The error message produced due to this bug was something like '/usr/bin/env: no such file or directory' - because the perl script was directly started using
- 'configure' forgot to add '-fPIC' to CFLAGS, for this reason all shared libraries where broken. I had to add this option manually.
- Nothing works with 'make'. I had to install 'gmake' (GNU make) instead.
- The actual source code of the core libraries finally compiled, after I had upgraded to gcc 3.3.2. The source code of the 'demo' programs was totally broken, and gcc refused to compile it - once more I had to change the makefiles manually.
-----
One or two weeks later I compiled trolltech's Qt library on the same computer. It was as simple as './configure --platform=platformname && make && make install'.
Why do I need to debug 28.000+ lines of shellscript-code and a lot of makefiles, why do I need to install gmake, pkgconfig (by the way, pkgconfig and most other things in GTK+ don't work well if you don't install everything to
Qt does mainly the same as GTK+, but it simply compiles, using only shellscripts, 'make' and a C/C++ compiler.
Another example regarding code maturity (rather maturity than quality, notice the difference
-----
Some fundamental things about Software:
- The more people read the code, the more people can potentially find and fix bugs (good about open source).
- If a lot of people are allowed to write the code, somebody has to coordinate the work of all these people. Lots of different versions of the same module, written and/or modified by lots of different people need to be combined or coordinated otherwise (bad about most open source projects, because hardly somebody knows, how trustworthy anyone of the developers is; good abous some closed source projects (e.g. Trusted SunOS kernel, IBM SLIC kernel and other trusted code), because only a small group of really good programmers is allowed to write or modify code).
Conclusion: It's good to have only a small group of 'trusted' developers, who write or modify the code, and then to let everyone else read and verify the code.
regards,
octogen
"OMG! And Windows 98 didn't support fast user switching!"
Your analogy limps. Did most other operating systems support fast user switching in 1998? No, and especially not Windows' biggest competition on the desktop.
On the contrary, PostgreSQL has had decent foreign key and transaction and subquery support since 1999.
MySQL STILL doesn't support subqueries in a production version. Foreign keys are only supported by one table type. It doesn't support views. I could go on, but if you really want to see the differences, look at mysql's crash-me comparison chart. The differences that aren't cosmetic, even talking the last MySQL alpha, are pretty annoying.
...just think how much better Postgresql must be.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Fewer bugs per line of code means either fewer bugs or more lines of code. So if you blather on using long-winded, repetitive, cut-and-pasted code, you'll score highly on this scale.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
You're wrong on 3 of those 5 counts. Foreign key constraints have been available for ages (with InnoDB tables); subqueries were implemented in 4.0, updates on joins ditto. Stored procs will be implemented in 5.0. Not sure about triggers, but I'd be surprised if they don't come in 5.X once stored procedures are solid.
Il n'y a pas de Planet B.
What braindead excuse for a moderator modded this as a troll? The dude is spot on (except he failed to mention that MySQL added support for subqueries in 4.0), and I hope somebody with a clue will mod him up.
BTW, I know of at one project implementing stored procedures for MySQL in LUA and PHP. Either of these is a far better choice for a procedural language than Transact-SQL. (IMO arivanov is much too kind here, as I think that T-SQL makes Fortran77 look like a decent language.)
Il n'y a pas de Planet B.
There is a chain of discount supermarkets in Hungary called Smatch. Probably all over Europe as well, not sure. I believe the company is Belgian. In Budapest there's about 180 of them, if I remember correctly.
;-)
Just some off-topic trivia for you, since it's your project.
This Like That - fun with words!
It's a really clean 10 lines of code...now if they can implement something to make MySQL useful like subqueries this article will be worth reading.
Slashdot were to read their own articles, they would know this is a repeat. Slashdot, where's the quality?
/*
Undoubtedly()
{
when();
you = measure(quality);
in.defects();
per->lines_of(code, anyone);
can = write(good, solid, code);
}
*/
Do Not Move Gemstone from Oracle! You have severe stability problems with play.net at times and I bet its unrelated to Oracle. I don't know about the games but the web site is tied to Oracle by the function calls.
/. reader.
Netcraft says your site is using MS 2000. There is your problem. Move to an OpenBSD solution first on the frontend and I'd keep Oracle at the backend.
Remember the saying goes: "No one got fired for buying IBM." Also the same for Oracle. But...
I'd choose a PostgresSQL solution. Toss it in a sandbox and use it for the forums per-se and see how it goes.
My advice costs a premium and basic membership. (wink)
GS4 Player and
Well Debian Stable is not exactly the most popular linux distro. Yeah it is a good distro, debs rock, I run fink on panther. However, I think their are many mosre Redhat and SuSE mysql servers out their and that would be a better judge of deployment. Also are we talking servers deployed in the last 6 months or all servers, cause I'm sure for many people Redhat 7.x is good enough cause it was the latest and greatest when the server was built.
Finally, most debian users are running unstable.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Make that "6 times fewer bugs found...".
What braindead excuse for a moderator modded this as a troll?
Probably one that disagrees with you. Just like me.
He's NOT spot-on - he's got a bunch of excuses (typical for MySQL zealots) about how his favourite piece of crap^H^H^H^Hsoftware doesn't 'need' features (that everyone with a clue says are needed) because workarounds exist.
I wouldn't say most debian users are running unstable. I run unstable on my TiBook and unstable on my workstation, but all my servers run stable. Important things in unstable are known to break. I haven't had stable ever break on its own.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
... How companies like this "Reasoning" sell people on this bullshit. Do they actually get paid for writing this pointless tripe?
What a joke. How about this:
I'll write 15 lines of code that do absolutely nothing right now, in a language of "Reasoning's" choice, and it'll completely bug-free. Does that mean I'm infinitely better than mySQL? Despite the fact that my code does absolutely nothing???
Please. Any of these bullshit whitepapers that don't take feature set into account are WORTHLESS.
Reminds me of that line in Tommy Boy(?): "Hey, if you want me to take a dump in a box and mark it guaranteed, I will. I got spare time."
MySQL STILL doesn't support subqueries in a production version.
4.x is a production version. His analogy is perfectly valid, people are complaining about mysql 3.x when 4.x implements most of what they were complaining about.
They should replace the term "commercial" with "closed source", because Mysql is also a commercial product and what makes it different is the open source model. - They should replace the term "commercial" and the term "open source" to the actual name of the database. Where is the proof that any difference in quality of the code is at all related to the fact that the other database was closed source?
You can't handle the truth.
Despite the uncovered bugs, Reasoning concluded that Uppsala, Sweden-based MySQL AB's code quality was in fact six times better than that of comparable commercial, proprietary code. - they decided this after looking at one "commercial" - closed source database and comparing it with one open-source (also commercial) MySQL? Talk about self-serving use of statistics! Sure, there is a correlation, but where is the causation?
whatever.
You can't handle the truth.
> As a matter of fact, until Oracle's release of 10g, MS SQL beat all commercial offerings in the TPC benchmarks.
pardon?
which benchmarks? tpc-c, tpc-h, tpc-r, tpc-w? It actually has some strong entries in tcp-c (oltp) but that's about it. DB2 and Oracle are all over it most of the time - and not just oracle 10g, but 9i as well.
I do agree with you though - that sql server is about the easiest database to develop on. I still won't give it much credit here though - the fact that it *isn't as bad* as oracle, et al isn't much to celebrate.
And when it comes to supporting it in a production environment, that's when it really begins to stink.
"You don't need the database to ensure the integrity of your data, because you can just check it manually!"
I'll just redundantly repost what you said, because that part SCREAMED in my mind when I saw that. To the parent: go back to your comma separated files and leave the big boys alone...
Both functions fail to initialize the integer i before performing an operation on it :)
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
4.1 is the first version of MySQL to fully support subqueries as in the SQL standard, at least as described in the docs.
The latest PRODUCTION version of MySQL is listed as 4.0.17 on their front page.
Yes I do. And I have revived and made perform to to spec god knows how many cretinous foreign key designs by a combination of
The difference between this and a classic foreign key constraint is that this approach always uses efficiently multiple CPUS while a foreignkey is usually a single CPU bound task, it also maintains much less large scope (global or per table) locks and is generally faster for retrieves by a factor of between 10 and 100 times. Due to the TPC vendors have overoptimized join at the expense of many other different things in order to have nice benchmarks..
And in btw, learn the difference between a "real DBA" and a database designer. I mean the one that is the justification for the 20+% salary difference.
Cheers (lessons start at 500 per hour),
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
500? Ok chump, here's my 500 pennies. Seems about the right salary for someone who likes to reinvent the wheel when ever he/she feels like it.
And BTW Mr "real" DBA. Oracle will split tasks between multiplt CPUs just fine thanks.
I'm not sure I agree. If speed is important, and you know the pointer isn't NULL due to earlier checks which the scan tool can't see, you might not want to throw in extra checks. Of course, you'd need a clear way to document the perimeter of checked-ness.
If speed's not important, why not use Perl or Java or something? High level languages protect against this kind of mistake. Of course you may be using C simply to use libraries that are only available for C.
Yeah, maybe. That's after they managed to surpass recommended limit of 1e6 rows per table (just in case it corrupts). And even in current incarnation they still don't (always) get ANSI joins right. What is even funnier, they sometimes don't get their own syntax right either. I had a couple of cases when I ended up having to *emmulate* a join via UNION SELECT with EXISTS/NOT EXISTS!
As should have been expected this thread gets all lost in "MySQL lacks [insert many of ACID and a bunch of other features]" and "who ever needs this stuff anyway!" posts. Which is common for any thread about MySQL. It is all very personal -- you either like it or you don't basically. It is like vi vs. EMACS of databases argument. And as always our wonderful geek crowd will never ever agree on anything here. Just like in the UserLinux GNOME vs. KDE debate, and a ton of others.
Not to be critical -- it just *is* that way and will hardly change, not in our lifetime, at least.
--AP
True. I'll say this though, any RDBMS offering is better than ISAM (which I still have to report off of here.. paged databases in 2003, wow!). I just got my Cache disk in the mail this past week, so I'm going to spend some time playing with the OODBMS model, see what all the hoopla is.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
All your databases are belong to MySQL!
There are at least some things questionable on this study:
... it has grown to
a) MySQL is not a good example of Open-Source Development. It is a good example of
'Cathedral-style' development (with the cathedral having its windows opened, though).
b) Whether source has x or y bugs per line is not the most interesting thing when it comes to open-source.
How consistent in design and implementation some piece of software is may be more interesting - especially if bugs are not only
fixed by the original author (or just in case a moose stampede runs over the orignal author).
Anyone who made a look into MySQL source code
does not need to know more
yet another crufty piece of software over the years.
c) The question what is a bug and what is not is
'questionable' in any non-trivial software.
Err... What you miss is that that foreign key transactions are what it reads on the label - transactions. They are done end to end now, hear and holding the relevant locks. At the same time if you do them by split join/garbage collection you can move the cleanup to idle hours. This quite often is the factor that may push an otherwise out of spec transaction system back into spec.
Of couse this is all valid if you can replace the existing selects by selects with joins. In most nowdays projects where the database access is abstracted and unified as load/store methods for objects this is not a problem.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
"Read for yourself" link is a goat!
Now it bold.
Slow down buddy, or you might get a cardiac infarct...
Well at least your family will enjoy a nice large cheque from Bill and Steve.
Wow, you are confusing foreign keys with subselects. I've never seen that mistake before.
Style errors could be errors that work for a given platform at a given configuration. But would not work on another one.
Unitialized variables is often a mistake where you assume than an int, as an example, is zero if you dont init it. True on many compilers, but not on others. ISO C standard states you must initialize the variables.
Such an error might or might not raise an error or a warning by the compiler.
Standard compliance really hits you in the nose when you try to compile stuff written for a linux distro and you want to use it on FreeBSD.
> And even in current incarnation they still don't (always) get ANSI joins right.
Yep, it's great that they still have some of their legacy join syntax working - otherwise multiple outer joins would have to sometimes be done with temp tables and multiple stages!
> It is all very personal -- you either like it or you don't basically. It is like vi vs. EMACS of databases argument.
Nah, it's more like notepad vs vi or EMACS: with the vi/EMACs crowd trying to educate the notepad crowd regarding the value of undo, syntax-checking, etc. Or in this case support for ansi-sql, transactions, views, unions, subselects, etc.
lol, sort of funny given how often is used by php web apps that are crap, regularly featured on bugtraq. Can't blame MySQL for that though.
Sounds like a perfect mysql strategy - you don't need all the extra 'fluff' in the database - because you don't mind getting garbage into your database. Cleaning it up later while the database is idle will also generally be faster.
Makes perfect sense - if you don't mind invalid data. Also note that performance problems with referential integrity is generally a sign of bad design - you should have (in general) neither locking nor performance issues with this built-in protection.
Also note: this sounds a lot like arguments I remember from the early 80s - in which the old spahgetti programmers using flat files were quite upset that we would dare to create data stores with built-in protection against invalid data.
Of course, the reason that we did this is that they continuously tossed garbage into the database. Most of them considered themselves 'designers' - but failed to understand the economic value of the data - and that given enough time they were certain to screw it up. Instead they focused on performance.
So here we are with mysql - catching up to 1981...
A few years ago, I looked around and found that there weren't very many good lint like tools for C++ code. What would people recommend now?
In particular, I'm thinking about a very large source base (the Linux kernel is usually built along with the rest of the system), written in C++, but with a lot of source files in XML or custom formats that are processed via various build time programs in a variety of languages (TCL, Perl, Java, Python).
Multiple executables are produced, and some very tricky custom systems are used for memory and thread management.
plus-good, double-plus-good
The modern C spec says that integer variables default to 0, but in the interests of portable code, explicit values are still better.
:) I think your point still came across ;)
I wouldn't worry about it, either
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
"Once again, MySQL is great. I use it. However, it is not enterprise."
This depends, of course, on the enterprise application. For many situations, you are correct. For many other situations, however, mySQL would fit like a glove.
It's not a matter of "disagreement" -- it's a matter of *misrepresentation*.
I get really tired of (among other things) people saying that MySQL doesn't support transactions when in fact it has done so for several years and it's just that some people are just too lazy to learn about InnoDB tables.
The parent poster even said himself that MySQL isn't suited for every purpose under the sun, so I don't see where you get off talking about "zealotry", either. Given that you mischaracterise what the parent poster said *and* posted AC, I'd say it's more likely a case of *your* (anti-MySQL) zealotry.
Il n'y a pas de Planet B.
And mySQL offers 1/6th of the functionality that commercial products offer.
What you are missing is that in 1981 the languages in use were flat structured and addressed the database from all over the place. What happened in the 1980-1990es was that the databases got a 1981 level solution - Fortran 77 level like languages with abnoxious syntax (ever tried to look at a full parser for SQL? Try :-)
The difference between 1981 and 2003 (for big projects) is that the database is usually touched only in an object create, store, retrieve and delete methods and in rare cases one or two more application specific methods.
As a result, instead of it being accessed all over the place the access is limited and work is done mostly in the application. Using foreign keys, triggers, stored procedures, so on under these conditions makes sense only under a limited set of circumstances. You are much better off splitting the tasks and doing them at app level. You can also do stuff which is extremely expensive to do at a PSQL/TSQL level. For example foreign key is nothing but an example of a simplistic reference counting with the reference values being limited to zero and non-zero. It is fairly obvious that in many cases where a foreign key has been used on data that is loaded into a list of various objects you actually need a proper reference count (and a proper garbage collector to kill of dead references). So on so forth.
In btw, do not understand me wrong. I have no objection to using foreign keys for the rare cases where you have several trained baboons using MS access or even SQL queries directly. What I have to note that this usage is slowly descending to the red book of endangered species and the usage of interest is the one from an OO language. There you either have to deliver the relevant performance, because 90% of the developers do not give a flying fuck about having their database access optimized. All they care about are abstracted store, load, update, delete.
So you have the choice. You either get involved with the developers process and work with them to get these store, load, update, delete optimized which usually ends up in moving PSQL code to C++ or Java at the client end. Alternatively they tell you to FUCK OFF and move to a persistent object store like prevailer. And they are bloody right.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
> The difference between 1981 and 2003 (for big projects) is that the database is usually touched only in an
.NET application to it. Now you're screwed.
> object create, store, retrieve and delete methods and in rare cases one or two more application specific methods.
It's really not that much different today than it was 20 years ago: we knew then as well as today to isolate the database interface. It was more difficult then (they were often just paragraphs in COBOL)- because the languages weren't generally as sophisticated as they are today. The real problem occured over time - over 5-10 years of modification with new technologies - the isolation would typically break down. Today the same is true - you build your app layer in Java - and then someone wants to connect their
Another reason to avoid trying to perform this code in the application layer - is that in the db layer it is declarative - easily created, easily enforced, 100% guaranteed to work, and easily tested. Do it in the app layer and you will frequently screw it up. Sure - maybe *you* are good enough not to, but 95% of the folks out there aren't.
Another reason to avoid driving the database design from OO - is that OO has only caught up with transactions in about the last ten years. It still hasn't caught up with decision support. So, the developers can bloody well encapsulate the hell out of their data, keep it in an object store, etc. Then when management starts to demand robust analysis of the data and the developers discover only at this time
* that much of their private data - really isn't
* that their data is nearly impossible to compare from one part of the application to another (because they thought it was data - when it was supposed to be information)
* that they have invalid data - because of defects in their referential integrity rules
* that they have inconsistent data - because their referential integrity rules changed over time - and they just handled in in their API
It's about that time that management will replace the designers and architects of that solution with new ones - that understand more than just 50% of the problem.