David Axmark Resigns From Sun

An anonymous reader writes "From Kay Arno's blog we see that David Axmark, MySQL's Co-Founder, has resigned. This comes on top of the maybe, maybe not, resignation of Monty. We saw earlier this year that Brian Aker, the Director of Architecture, has forked the server to create a web-focused database from MySQL called Drizzle. The MySQL server has been 'RC' now for a year with hundreds of bugs still listed as being active in the 5.1 version. What is going on with MySQL?"

Comments

That's the power of the open source license.

[aqui]

It allows for disagreements to be resolved by disagreeing, even when there are corporations with lots of lawyers involved.

You can still fork it. No easy corporate lock down is possible.

Re:That's the power of the open source license.

[Anonymous Coward]

Development is only as good as the developers.

If the majority of the developers make their living from a single corporation, and when that corporation doesn't allow them to do further development on the project, it's going to take a big hit.

To be sure, open source makes the process harder since others may still be willing to maintain the "still open sourced fork", but when a project comes to a certain size and complexity it will be really hard to replace the lost developers...

Re:That's the power of the open source license.

[vandan]

Theoretically, yes you can fork the code. But there are broader issues than the legal ability to fork.

This has put a huge question-mark over MySQL's long-term viability. For a fork to be viable, you need a critical mass of developers. But we've seen 2 key ( founding ) developers leave, and Oracle buy InnoDB.

If Sun bought MySQL to further the project, then where is the evidence that this is happening?

If Oracle bought InnoDB to further the project, then where is the evidence that this is happening?

Of course you could argue that neither company is obliged to do anything. But alternatively you could argue that both companies have behaved in an explicitly anti-competitive way. This is itself is of course no surprise to anyone other than the US justice department.

Re:That's the power of the open source license.

[Calinous]

Does Sun have a competitive database? I ask because I don't know of any

Re:That's the power of the open source license.

[Anonymous Coward]

Why fork it? Just let it die.

There is a serious, open source, Object Relational DBMS available.

Re:That's the power of the open source license.

[SiggyTheViking]

Well, there is this.

Re:That's the power of the open source license.

[cbreaker]

I guess it's the natural progression of things. Products die, OSS projects die. If there's a gap; a need for software that doesn't exist and is very important to the community, it will be created or an old project will be resurrected.

There is money in OSS. A lot of the big or important OSS projects have been able to bring in a good deal of money (I mean, look at mySQL, those guys made a small fortune from it) so I have no doubt that if mySQL dies out and there's no equivalent alternative (but there is already) we'll see a project come alive.

Re:That's the power of the open source license.

[Anonymous Coward]

You could also argue that their internal cultures do not mesh well with the open source culture, and that is why you see projects brought in only to stagnate, or why they open source different projects only to see very little significant input from the broader community.

Re:That's the power of the open source license.

[ThePhilips]

In other words, Sun Inc. still has no clue as to precisely what it wants to do with its assets. And no clue what to do with other markets where they have accidentally became leader. Current strategy seems to be "play dead."

And the leakage of talented people from Sun, doesn't really give it a good mark as employer.

Re:That's the power of the open source license.

[TheRaven64]

Sun have offered support for PostgreSQL for a few years now. The version of PostgreSQL they ship has a number of Solaris-specific tweaks that integrate with their other buzzwords.

With regard to MySQL, forking is difficult. MySQL is GPL'd, including the client library. This means that any application that uses it (by linking against the client library) must be GPL'd, or must by a proprietary license (previously from MySQL AB, now from Sun). Postgres, on the other hand, is BSD licensed, meaning you can use any license you want for your code.

Re:That's the power of the open source license.

[Albanach]

Why fork it? Just let it die.

There is a serious, open source, Object Relational DBMS available.

Yes, and Vim is better than Emacs. Why don't we discuss that too?

Re:That's the power of the open source license.

[aqui]

You're right the key thing about the longevity or stability of piece of software is that there is a community of developers to work on it.

That being said if you look at source forge projects you'll find that many of the open source projects only have a few core developers, but still remain and are useful (rather than disappearing in some corporate lock down). It doesn't take a huge core group of developers for software to survive, what it takes is a large enough user base.

Also, the community around MySQL would like not have come together if people though that they wouldn't have control over the code they contribute. In general one doesn't see large lines of people volunteering to work on corporate owned software, unless its also under an open source license.

The open source license is probably one of the reasons that MySQL community has a chance of surviving despite the introduction of new corporate partner (SUN), because the developers rights to their previously written code are protected by the GPL and cant be taken away.

Forking the code is not always permanent, there have been many cases where forks eventually flow back into product, or ideas from forks are adapted in the mainstream. The reality is that although forking may lead to some duplication of work (and can be disruptive in the short term), ultimately it keeps good developers coding even when they are in disagreement about something, and that usually in the long term works better than people walking away because they don't have control.

As for SUN furthering MySQL... they are but maybe not the way you think they should be. I suspect that their main interest is in providing their enterprise customers with a Solaris compatible version that can run larger DBs rather than improving it for smaller users. Perhaps from a code standpoint they have no intent to invest more resources than they already do.

That being said having a big name like SUN stand behind a piece of software will likely lead to more enterprise acceptance and users (which will increase the user base and probably help the software).

For me the key reasons I use MySQL is because:
1) it works and does what I want
2) its open source so I know it will remain around even if SUN finds some other DB they like better or goes out of business (worst case I have the source code).
3) I don't have to worry about licensing costs or issues as much (eg. do I have enough seat licenses etc.)

Lets agree to disagree. Even though I forked your comment. ;)

Re:That's the power of the open source license.

[Corwn of Amber]

Of course you could argue that neither company is obliged to do anything. But alternatively you could argue that both companies have behaved in an explicitly anti-competitive way. This is itself is of course no surprise to anyone other than the US justice department.

Yeah, I wish I could have said "told you so", but it would have been mass-modded to "redundant" at that time.

Use postgres. Never heard of it? That's the first reason to choose it then.

MySQL has sucked big dirty monkey balls for YEARS before it was anything near remotely usable (how that"no subrequests"? - or whatever you call it in the RDBMS world - yeah they have those now, only took ages to implement) while Postgres was busy kicking Oracle's ass in every possible way.

MySQL has sucked for aeons from clueless devs, now they don't even have any dev left? Good riddance.

Use postgres.

Re:That's the power of the open source license.

[krow]

Hi!

There are a lot of misconceptions around the BSD license. One is that you can change the license. You can put new code you write under a different license, but the original BSD license must be kept for the code that came under that license.

What BSD does is that it allows you make use of the code with a minimal set of restrictions going forward. Personally I like the license and use it all the time.

As far as the client license goes, while the client code shipped with MySQL is GPL, Redhat distributes a public domain version of a client library for MySQL. In my opinion, license follows code, not protocols.

Cheers,
      -Brian

Re:That's the power of the open source license.

[FatherOfONe]

Your post seems to think that Oracle and Sun teamed up to kill MySQL. You want proof that Sun has done something to help MySQL along since it bought it.

My "Proof" is comes from that of a Java developer, one that uses almost all Sun tools (Netbeans, Glassfish, EJB3, WebServices and would consider Sun hardware if we could). The freaking day Sun "bought" the company that sold support for MySQL they started to push it as "their" default database of choice. Within a few days they had tutorials up on how to integrate MySQL in to your project. That is definitely an act of a company that doesn't want to KILL a product.

Sun has appeared to leave MySQL alone and to be honest the people who stared it are generally the type of people who HATE large companies and wanted to get back in to a smaller starup type company.

So why did Sun buy MySQL? In my opinion they needed to add it to their software stack. Look at their competition and tell me who doesn't have all of the following (OS, Database, Application Server, Development Tools)
Microsoft, IBM, Oracle.

So "if" Sun wanted to compete with those listed above they needed to do something. NONE of those companies were going to recommend Sun hardware any more. Specifically Oracle who now is in love with their own version of Linux.

Now Oracle buying Inodb to kill or hurt MySQL... We totally agree on that one. The thought of a company like Sun giving away software to sell hardware doesn't bode well for companies like Microsoft or Oracle.

Re:That's the power of the open source license.

[Random BedHead Ed]

I'm qualified to take part in this discussion, since I wisely chose KDE over Gnome.

Re:That's the power of the open source license.

[Sancho]

That's a bit direct (or harsh) but fairly accurate.

MySQL is useful for small- to medium-sized projects. It's easier to admin than most other database systems, and you get to balance speed and referential integrity by choosing which back-end to use. It's got the SQL syntax that so many are familiar with. The problem is that if you go for referential integrity, you lost most of the speed that MySQL is known for. You get speed closer to PostgreSQL, and the latter is more cleanly designed and has a better support structure for a relational database.

Really, though, SQLite is often a perfectly adequate replacement for MySQL. So when I'm working on something, I tend to choose between SQLite and PostgreSQL. It's just really rare that MySQL is the best fit for the overall design.

Re:That's the power of the open source license.

[chrysalis]

And Prototype is so much better than jQuery.

Re:That's the power of the open source license.

[lanc]

yeah, but check out where it is running, on Debian, Teh Chosen One!

Re:That's the power of the open source license.

[NateTech]

Ahh, who cares?

Just buy Informix which has worked solidly since the 1980's, and forget about the idiots at both Sun and Oracle.

It's owned by IBM now, and they have been dedicated to keeping it going, including major releases, for years since they bought it.

Works great, used by tons of government and large telco shops, and you spend a whole lot less worrying about whether or not someone's dicking around with it just to keep it half-alive.

Re:That's the power of the open source license.

[ta bu shi da yu]

You should see what they are doing to OpenOffice.org. Sun buying or open sourcing something is really the death-knell of that product.

It ain't MY SQL

[Anonymous Coward]

Take responsibility for it Sun.

MySQL sucks

[Anonymous Coward]

MySQL sucks

Re:MySQL sucks

[Ron_Fitzgerald]

Let me say this about that....

I have used MySQL for nearly 7 years now. I currently maintain about 30 databases across many servers and operating systems from MS to Linux. Databases as small as 200k to one as large as 900MB....I have never had a single issue with any of them in all that time, ever.

Re:MySQL sucks

[Reality Master 201]

ooh, 900MB. Positively ginormous, that.

Re:MySQL sucks

[DerWulf]

Really? How about the "bad connection" issue where the database server due to no reason obvious to the developer will count to ten and then just refuse new connections? How about when MySQL trips over itself and locks it's own tempfile? How about the admin gui that pretends to let you change parameters but really doesn't? How about MySQLs abmyssal speed once it has to deal with larger tables? How about introducing new keywords that are common words like 'release' and thus making a DB upgrade much more painfull then it needs to be? Overall I like MySQL, grew up with it even, but there is no use in pretending like there aren't any problems ...

Re:MySQL sucks

[The Bungi]

to one as large as 900MB

Is that what powers your HTML applications?

Re:MySQL sucks

[Kev Vance]

I have! MyISAM tables get corrupted by normal MythTV use on x86_64, which causes mysqld to crash. Pretty annoying to live with, until you realize you can change the engine to InnoDB and it seems to work.

This is documented on the ubuntu wiki, but affects gentoo as well.

Re:MySQL sucks

[ConceptJunkie]

That's the problem with MyISAM. It's only useful if you're not worried about losing data. Any breakage, whether it's a server crash, running out of disk space or the wrong phase of the moon will totally lunch your DB. InnoDB on the other hand is storage engine actually meant for real projects. That said, MySQL definitely has its limitations, but within them it's pretty good.

Re:MySQL sucks

[ConceptJunkie]

Yeah, I had to snigger at that. The project I'm responsible for has a database that's gotten up to tens of gigabytes in size. MySQL was chosen before I came along, and knowing what I know now, I'd definitely consider alternatives, but for the most part, it serves our purposes.

Re:MySQL sucks

[lysergic.acid]

there's no need to start dicksizing about the type of databases you manage. no one is claiming that MySQL is the best database management system out there, or that it can handle any kind of application. but for a certain range of applications it's a very capable and well designed database server.

not everyone needs a multi-terabyte database. and the utility of a RDBMS is not defined by database sizes it can handle. MySQL is so popular precisely because most sub-enterprise businesses don't need anything as robust as Oracle. so MySQL is therefore a much more cost-effective solution.

Re:MySQL sucks

[runningduck]

I am perplexed by MySQL. I installed it on a server 9 months ago for a new project I was tinkering with. Paying jobs kept me from doing much more than getting MySQL up and running. Last month I noticed my server was straining under a heavy load. I figured I had finally pushed the server beyond its limits doing multi-site hosting with Apache and Postgres, multi-site mail serving with Postfix and Courier POP/IMAP [backended into Postgres], running video security software, and being a general collect all project server. It wasn't a big deal being there are no critical customer services running so I wasn't too concerned even when SSH was non-responsive. When I got console access I was shocked to find MySQL, which had no databases and no connections [blocked via iptables], was consuming tons of memory and cpu. Arrgh! I killed MySQL, the server recovered and everything else it humming without a problem.

My only explination is that MySQL is like a petrol engine in that it will seize up if run too long without a proper load. :)

Re:MySQL sucks

[Anonymous Coward]

Basically, you're saying all your databases fit in RAM. Anything would get good performance out of such small DBs, unless you go out of your way to write ridiculously bad queries.

Re:MySQL sucks

[mooreti1]

MySQL sucks

And your post, like my response, is pointless.

Re:MySQL sucks

[raju1kabir]

I know! And he's ridiculous on the other end of the scale too. 200KB? Gimme a break. I've worked with microdatabases as small as 5 bits.

Re:MySQL sucks

[mysidia]

I have used MySQL for over 12 years now. I have maintained databases as small as 100mb and as large as 400gb.

I have had numerous issues with MySQL and its poor reliability, lack of standard SQL features, and buggy, incorrect, or dangerous implementation of standard SQL features causing silent data corruption.

Although I can say the more recent versions of MySQL are much better. MySQL 3.x was the worst, with periodic crashes major database corruption, and appallingly bad query execution.

Historically, MySQL has been unstable, with periodic crashes, and very long rebuild times to repair damaged ISAM tables.

I have used postgreSQL over the years also, and not encountered any problems with that.

I want a database engine that combines PostgreSQL's best strengths with SAP DB and MySQL's best strengths, and contains none of their worst weaknesses.

Re:MySQL sucks

[TheLink]

"and the utility of a RDBMS is not defined by database sizes it can handle"

Actually there is some relevance.

If you needed a database gigabytes in size a few _years_ ago, MySQL would have been a really bad choice (it still is crap, just less so IMO).

For MyISAM:
You would have to configure it to get tables bigger than the default 4GB limit (there's a number of row limit and table size limit). Hope you don't make the new setting too small so you're still working in the place when those run out too ;).

For Innodb:
Before the single file per table, if you're moving about gigabytes of stuff, you end up with one huge multigigabyte innodb table.

For both:
Adding an index was the same as "alter table" and involved making a copy of the table.

So let's say you have a 40GB table and 40GB of space free. No index add for you :).
Keep in mind if you have plenty of space free making a copy of a 40GB table does take time.

BTW concurrent inserts to an innodb table with an auto increment field were slow till only recently (well allegedly they've fixed that).

Re:MySQL sucks

[guyminuslife]

It's not a microdatabase unless it's stored in microbits. Anything that takes up a whole bit or more is way too big.

Re:MySQL sucks

[theantix]

"How about the "bad connection" issue where the database server due to no reason obvious to the developer will count to ten and then just refuse new connections? How about when MySQL trips over itself and locks it's own tempfile? How about the admin gui that pretends to let you change parameters but really doesn't?"

I've developed, debugged, administered, and administered MySQL databases for nearly a decade now, and I have never seen any of those issues you complain about.

"How about MySQLs abmyssal speed once it has to deal with larger tables?"

The InnoDB storage engine uses clustered indexes and is actually pretty good with large tables. Combine that with the partitioned table support in MySQL 5.1 and large tables are quite manageable. I have one OLTP application with well over 300M rows, and the server runs fine even though it is on commodity hardware.

"but there is no use in pretending like there aren't any problems ..."

Indeed, but they weren't what you mentioned here. I am looking for better CPU utilization on multicore systems, semi-synchronous replication, parallelized replication, better foreign key performance, and better join algorithms. Many of these features are planned of course but I want them now.

Re:MySQL sucks

[TheLink]

I've definitely seen mysql use up tons of memory before for no apparent reason. Trouble is it did this at a customer's site on a live machine with lots of users.

My ex-boss insisted on MySQL - whereas me and my colleague were pushing for postgresql instead. Oh well...

Postgresql has its fair share of problems, but looking at the Postgresql and MySQL mailing lists and bug reports, I'm more comfortable with the Postgresql problems.

Stuff like this scares me:

"ORDER BY DESC in InnoDB not working"

http://bugs.mysql.com/bug.php?id=31001

So it might actually be a good thing if MySQL fades away.

(which reminds me of the error message when it crashes every once in a while: MySQL has gone away :) )

Re:MySQL sucks

[TheLink]

The problem with MySQL is the "brochure" looks very nice to the PHBs.

But when you get to the details, a lot of the advantages/features are mutually exclusive.

Want fast simple selects - MyISAM
Want fast single user inserts - MyISAM
Want fast concurrent inserts - InnoDB
Want fast concurrent inserts to tables with an "autoincrement" column - better look at this http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html

Re:MySQL sucks

[Splab]

Then you my friend, are only using MySQL as an advanced file pointer.

Simple things like firing triggers during cascading events, ensuring the client gets the engine he requested are features MySQL does not have.

MySQL is a nice toy database, but until they change from best effort to ensuring our data, it should never be used for anything critical.

Re:MySQL sucks

[Splab]

Postgresql is a nice database, however in this day and age, a database must support clustering in some way or other, unless they get working on at least a replicating service they wont take off.

Re:MySQL sucks

[siDDis]

Youre joking right? PostgreSQL supports several replication engines which works fantastic great and it has been doing that for years!

You have:
PGCluster
Slony-I
DBBalancer
pgpool
PostgreSQL table comparator
SkyTools
Sequoia

You can read about what Skype use replication for PostgreSQL here:
https://developer.skype.com/SkypeGarage/DbProjects/SkypePostgresqlWhitepaper

And Slony for example is developed by Jan Weick, a PostgreSQL core team member.

Re:MySQL sucks

[TheLink]

" one huge multigigabyte innodb table"

Agh I meant file. And you can't shrink that file easily even if lots of it is unused.

Re:MySQL sucks

[shutdown -p now]

I've worked with microdatabases as small as 5 bits

So that's like 1 bit for metadata, 1 bit for indices, and the other 3 is raw data?

Re:MySQL sucks

[Splab]

No I'm not kidding.

PostgreSQL does not support any of these, they are all add on. On top of that none of them are viable for critical environments, some work by replicating through triggers, some work as a middle layer, none of them can guarantee your data in case of primary failure, and none of them has proper sub second fail over (except for Sequoia who doesn't support triggers and procedures) - trust me I've been researching this extensively and there are no FOSS databases that handles this.

Re:MySQL sucks

[glwtta]

Wait, since when does SAP DB have strengths?

Re:MySQL sucks

[glwtta]

Ooh, tens of gigabytes!

I have about 2.5 TB in MySQL right now, it does alright, but it's also not critical data. While MySQL improved technically quite a bit in the last couple of years, their overriding philosophy seems to have always been "speed over data integrity", which makes it a hard choice to make (and it only has that performance advantage in a relatively narrow set of circumstances, at that). So it's usually relegated to the role of "granular file system for non-critical data".

Maybe that's improved lately? I haven't looked at it in detail in a while (the above-mentioned database is large, but not terribly complex; it's also a free project, so I've only done minimal development with it). In the 3.x days it was a joke; 4.x was still missing a lot of basic functionality, but even more annoying was the developers' attitude that it's because you don't need it: Views? Only Elitist Ivory Tower developers would want such an outlandish feature in their database! And so on. 5.1 seems to have at least mostly caught up as far as the feature checklist.

But enough reminiscing, time for people with 100+ TB databases to jump into the willy-waving contest.

Re:MySQL sucks

[Anonymous Coward]

I've "experienced" MySQL replication before and it can't guarantee your data either.

In fact it seemed nearly guaranteed to lose some data given enough time :). Just look at the previous bugs and also how they are fixing their replication to "new style" (their old style doesn't work).

MySQL AB were just more willing to make big claims about their replication (and be more "discreet" about the inconvenient details) than the postgresql developers - who will honestly tell you the limitations of the various postgresql replication approaches.

Re:MySQL sucks

[Splab]

And you are telling me this why?

as I clearly state in my replies, there is no FOSS solution that handle this.

Re:MySQL sucks

[Reality Master 201]

For cost, for robustness, for functionality, MySQL is a far poorer choice than PostgreSQL.

I've used lots and lots of databases, relational and otherwise - MSSQL, Oracle, DB2, Informix, Unidata, etc. etc.. MySQL looks great to people who haven't got much experience with other databases, and it looks like a chunk of shit to those of us who have. I'm not even talking about database size. I'm talking about functionality level stuff - views, useful subselects, a single reliable table type that supports transactional data writing (and for that matter, a transactional layer that isn't shitty). Features that are always coming in a future version, but are already available in other products - ones that can be had for free.

There's no compelling business case for MySQL over another product, except that you might need to make use of a crappy open source project that's tied to it.

Re:MySQL sucks

[Fweeky]

We store about 3 billion rows using compressed MyISAM tables. I dread to think what that'd be like using a transactional table type; MVCC generally bloats disk usage 2-4x, and compression is only supported in the very latest InnoDB.

Sure, it'd be nice to have everything in one table type, but at least some of these tradeoffs seem quite fundamental.

Re:MySQL sucks

[ais523]

Probably my favourite MySQL stupidity:

$ mysql
[snip]
mysql> help analyse
Name: 'PROCEDURE ANALYSE'
[snip]
mysql> help analyze
Name: 'ANALYZE TABLE'

In other words, both "analyse" and "analyze" have a special meaning in MySQL, and they're two different special meanings. "PROCEDURE ANALYZE" and "ANALYSE TABLE" are both meaningless.

Re:MySQL sucks

[hey!]

Yeah, well. But disk size has nothing to do with how important a database is. Nor is it the only measure of database "size".

I have clients that have databases in the 100-500MB range, the result of small but regular transaction volumes over the course of years, in some cases decades. They extract a lot of valuable information out of those databases, and the queries that do that can be extremely complex. Some of them insist on MS SQL Server. MSSQL easily scales well beyond any of their transaction volumes, but it scales poorly in complexity. I've had to rewrite a number of queries to handle peculiarities of MSSQL with column aliases for calculated values (well, that's ANSI's fault, but every other vendor on Earth seems to have figured it out), and bugs in "advanced" SQL features like subqueries. Once I rewrite queries around MSSQL's SQL limitations, they run fine, except that they're much, much messier.

Which illustrates my point: there are different dimensions of scalability. For many developers who are primarily interested in integrating with the MS toolchain, MSSQL is sufficiently scalable. If you are doing some kind of IIS hosted web site and you don't need to scale to Amazon levels of transaction volumes, MSSQL is fine.People looking for a simple persistence layer that integrates well with Visual Studio don't run into the problems I do.

It seems to me that MySQL has a similar kind of niche in the open source world that MS SQL Server has in the Microsoft universe. It is sensible default choice for a persistence layer in most projects using an open source tool stack. Just because these projects may not be complex from a database standpoint or large from a storage standpoint doesn't mean they aren't valuable.

This "sensible default" position could be extremely valuable to the right company. That company might be Sun. Unfortunately, Sun's track record is mixed when it comes to delivering successful open source projects.

Spinning off Open Office as a community supported sister project to Star Office seems to have worked reasonably well. Certainly a lot of people are using Open Office. On the other hand, the opening of J2ME has been a disaster. There has yet to be anything close to a production quality open J2ME release after two years, nor is there any specific future date on which we can expect to see such a release. The only result of Sun's opening J2ME has been abandonment by hardware (Palm) and software (IBM) vendors. With Android, Google has managed to bring an entire java centric mobile operating system to market, while Sun has failed to get anything done. So, despite there being plenty of developers out there who are familiar with J2ME, who would like to be able to write J2ME applications for devices like windows smart phones or Palm PDAs, despite one of the most popular line of mobile devices (Blackberries) having a proprietary J2ME port, Android is the platform mobile developers are pinning their hopes on.

All Sun has to do to keep Google from owning the mobile space is to deliver a free, production quality J2ME port for Windows Mobile based phones. Even if it were just MIDP, it would mean developers like me would do our next project in J2ME (or I guess "PhoneME") rather than steering our customers to Android. Once you can get an Android phone from any carrier, the J2ME game is up.

My point here is that while in theory MySQL under Sun's wing might be a good opportunity for Sun, it appears Sun has too many opportunities on its plate already. If there were somebody outside who was willing and able to pick up the ball and run with it, Sun might help them, but Sun isn't going to do it.

Re:MySQL sucks

[siDDis]

No I'm not kidding.

PostgreSQL does not support any of these, they are all add on.

EnterpriseDB supports slony... http://www.enterprisedb.com/products/postgres_plus/replication.do

Re:MySQL sucks

[toby]

not everyone needs a multi-terabyte database

And if you did, MySQL would do just fine. Ask Slashdot, Wikipedia, Flickr, Yahoo!, Google, YouTube, US Census, SABRE, Travelocity, Digg, Facebook, Mytrix, LiveJournal, Neopets, Mixi.jp, Linden Labs, SLAC (planning a 10+ PB store) and many other customers (http://www.mysql.com/why-mysql/case-studies/).

Not to mention many of Sun's present and future customers - hence the $1b acquisition.

Re:MySQL sucks

[Anonymous Coward]

"On top of that none of them are viable for critical environments"

Tell that to the hundreds of critical environments using them. Let's see... Skype, Japan's NTT, Backcountry.com, Myyearbook.com, Afilias...

Re:MySQL sucks

[FuckTheModerators]

Pointless but indicative of the general nature of the whole discussion. Anybody seen Godot?

Re:MySQL sucks

[not already in use]

Ohhh, 2.5 TB! Gimme a break.

I have a 100 TB database stored in CSV format, maintained via Excel and accessed through IIS using classic ASP.

So put that in your pipe and smoke it!

Re:MySQL sucks

[ins0m]

LiveJournal couldn't deal with the load balancing and disk latency issues with MyISAM just flat-out _not_ scaling. Hence, their need for the creation of memcached. Of the others listed, who else is using memcached?

Oops.

Re:MySQL sucks

[T(V)oney]

Ooooh, I've got some too! Their silly, non-standards-compliant alternative INSERT syntax that breaks when the SQL is ported to a different DBMS, i.e., INSERT INTO table [field = value], .... Or how about type inferencing that encourages lazy SQL code... which breaks when ported to a different DBMS (numbers in strings literals, ahoy!). Or, my favorite, how MySQL will truncate strings instead of throwing an error if the string overflows the field you're inserting it into.

MySQL is crap. If you want a good database on the cheap, use Postgres. Fast, reliable, predictable, relatively simple, adheres to standards, supports a slew of languages for stored procedures, blah blah blah.... It's a shame MySQL is so popular when Postgres is so much better.

Re:MySQL sucks

[ConceptJunkie]

Fine! I have a 3PB database stored on paper tape in EBCDIC accessed over a 9600 baud modem and transferred using Z-Modem. Seek time is in hours, but file transfer isn't so bad.

Re:MySQL sucks

[NateTech]

Well, I think the reason people "dicksize" about such things is that MySQL's um... size... is continually smaller than all of it's competitors.

As a long-time Informix fan, MySQL's been a joke to me for as long as it's been in existence, and Oracle has been over-priced bloatware.

Re:MySQL sucks

[NateTech]

Oh. You want Informix.

Re:MySQL sucks

[dtecmeister]

I've been using various versions of MySQL for about 7 years now and have had no issues at all. I don't use InnoDB, stored procedures, or subqueries, so I can't speak to those features.
I have used replication, extremely long queries, complex joins and unions, and all other common features with no problem.
I took many precautions like daily backups, log storage, etc. and never needed them except for restoration of lost data due to user error (user sent query that deleted all entries, or updated all entries, etc.)
I have a couple programs I haven't touched in 3 years except for minor cleanup that are still running with no problems.
If you're running into issues with MySQL, you must be using new features or versions that just aren't as rock-solid as core MySQL is.
I must admit that by design my programs don't run into many concurent update collisions and if they did, it would only be a minor annoyance.

Re:MySQL sucks

[gowen]

Screw that. I have a 200 Petabyte databased maintained using only ed and only queried with fgrep.

Re:MySQL sucks

[lanc]

fine. but are you ed'ing and fgreping the single raw devices in the raid array using the serial console controlled by whistling into a microphone?

Re:MySQL sucks

[ConceptJunkie]

Fine. I have a 7800 exabyte database stored on clay tablets and accessed by five hundred Hittite slaves (average seek time, approximately 7 weeks) and edited using small chisels and patching compound.

"What is going on with MySQL?"

[LaminatorX]

Not much from the sound of things.

Ah well. I run Postgres.

Re:"What is going on with MySQL?"

[inKubus]

I'm switching to PGSQL also. I knew when Sun bought them it was the beginning of the end. The community is just not there any more. I would like to see MySql survive, but they are so far behind when it comes to SP programming and such. Postgres was designed to be programmed, whereas MySql was designed to be small and fast for little websites. I have multiple Mysql boxes with 5GB+ innodb tables and while it works, it does not make me comfortable..... I have a few pgsql out there but there's a lot of migration that's needed first.

Re:"What is going on with MySQL?"

[RiotingPacifist]

looks to me like sun are trying to make mysql good for buisnes (bug fix it and add features that sound good to buisness) which doesn't get anybody laid so nobody really wants to work on it anymore.

Re:"What is going on with MySQL?"

[GaryOlson]

Does that mean your server now runs a LAPP stack? (someone please insert a Hooters joke)

Re:"What is going on with MySQL?"

[TheRaven64]

Back when I was a student, one of the modules I had to take was databases. The coursework for this was meant to be done in MS Access (yes, depressing) but could be done on any other database supporting SQL, since we were not meant to use the GUI. I first tried doing it on MySQL. I got as far as question 2, which required foreign keys. Back then, MySQL wouldn't even parse these (SQLite now does, but ignores them, although you can implement them yourself using triggers). Considering such a basic feature of SQL was missing, I was amazed that they were allowed to call it MySQL without violating some truth in advertising laws. In contrast, PostgreSQL just worked. I've been using PostgreSQL since then when I need a RDBMS. Apparently MySQL has improved, but I'd still rather be using an engine where basic features were mature six years ago than one where they are brand new. Between SQLite and PostgreSQL it's hard to find a niche where MySQL fits.

Re:"What is going on with MySQL?"

[ShieldW0lf]

MySQL has very lack enforcement of data integrity and constraints. Which is to say, it doesn't do it. They call them "gotchas", where it's broken, but it's by design, so it's a feature. Or something.

At any rate, when you don't pay a lot of attention to data integrity in the first place, it makes it a lot easier to set up multi-master replication. That's MySQL's niche.

Re:"What is going on with MySQL?"

[Anonymous Coward]

Does that mean your Hooters now run a LAPP stack?

I'll be here all week. Please, try the fish.

Re:"What is going on with MySQL?"

[Anonymous Coward]

I have multiple Mysql boxes with 5GB+ innodb tables and while it works, it does not make me comfortable.....

You understand that this makes absolutely no technical sense.

"feeling confortable" is a subjective feeling. Do you mean anything objective in the behavior of the database server by that?

One good turn deserves another.

[sethstorm]

Well, one good turn (PSARC 2002/013 (FastTrack, sun4m EOL, closed approved automatic 1/4/02)) deserves another (jumping ship from MySQL).

Re:One good turn deserves another.

[Anonymous Coward]

Does anyone here know what your ranting bout?

Re:One good turn deserves another.

[Temkin]

Does anyone here know what your ranting bout?

Yes. He's mad than Sun dropped support for a 15+ year old processor architecture over 6 years ago. Never mind that there were truckloads of Ultra 1 & 2 machines for sale cheap on eBay at the time, any one of which could have filled the void left in his life by the death of sun4m.

Now if he's talking about enabling sun4u only instructions in Solaris 9 patches without doing an arch check at patch install...

Re:One good turn deserves another.

[sethstorm]

Yes. He's mad than Sun dropped support for a 15+ year old processor architecture over 6 years ago.

Only recently was this information even available, with the only clues being in the Solaris 9 notices, and the Opensolaris 9 release.

Never mind that there were truckloads of Ultra 1 & 2 machines for sale cheap on eBay at the time...

One of which had a serious bug that nearly made it(Ultra 1) as dead as a quad-ROSS SS-20. Opensolaris nearly shunned it, but it and the Ultra2 survived due to being "Ultras with SBUS".

IPC/IPX's and Sun3's are one thing. Sparcstation 20's that can be coaxed to display 1080p on a CG-14(see sun-rescue mailing list) are another.

Which boat is Larry's and which is David's?

[KPexEA]

The article not clear on that. http://blogs.mysql.com/kaj/files/2008/10/davidaxmark-larrysyacht-2005-08-15-l.jpg

How long...

[russlar]

How long until Netcraft confirms that Sun is dieing?

Re:How long...

[Forty Two Tenfold]

About 4.5 billion years?

Re:How long...

[Anonymous Coward]

And it'll still run today's binaries!

Re:How long...

[jvillain]

You don't need Netcraft to tell you that. Just pull up google financial, yahoo financial or any other and plug in java as the symbol. You don't loose >80% of your companies value year after year and survive. At the rate their share price has been dropping for the last 2 years their share price will be zero in less than 3 months. That won't actually happen as they should be bought up very soon. The only question is by who? Oracle, HP, IBM or one of the hardware giants they rebrand and resell? My money is on HP who will then get rid of Solaris as they all ready have HP-UX.

Re:How long...

[russlar]

About 4.5 billion years?

Well played, sir. Well played.

Re:How long...

[Da VinMan]

God please let it be IBM.

Re:How long...

[hdparm]

At least Schwartz got properly 'punished' for the company's poor performance - he received only $11.1 mil. pay package for 2008.

It's really tough being CEO today.

Re:How long...

[Waffle Iron]

That won't actually happen as they should be bought up very soon. The only question is by who? Oracle, HP, IBM or one of the hardware giants they rebrand and resell?

The way things have been going the last few weeks, my bet is on the United States Treasury Department.

Re:How long...

[symbolset]

The way things have been going the last few weeks, my bet is on the United States Treasury Department.

So you're a speculator then? Because the long term money is in tribbles.

Re:How long...

[caluml]

Give it a few months, and that won't even buy a car.

Nice guy

[Anonymous Coward]

David Axmark spoke at our LUG a few years ago. We've had a bunch of folks speak there and he was certainly one of the most likable. That alone is not enough to impress a jaded LUG membership, so he was also extremely sharp technically.

No other reason for this post except that it's good to hear that he did well for himself.

Huh ...

[ScrewMaster]

David Axmark Resigns From Sun

So, he gets the ax because somebody missed the mark.

Re:Huh ...

[Anonymous Coward]

Gotta love that trademark Slashdot cheez :)

Re:Huh ...

[OldManAndTheC]

So, he gets the ax because somebody missed the mark.

Never fear, this is a minor setback for him. I hear he's already writing a book about what he will do in the next act of his career.

Title: "My Sequel"

Re:Huh ...

[ScrewMaster]

Well, the pun is the sincerest form of wit, you know.

Sombody finally FINISHED a program!

[Ungrounded Lightning]

I have used MySQL for nearly 7 years now. ... 30 databases ... many servers and operating systems from MS to Linux. ... as small as 200k to one as large as 900MB.....I have never had a single issue with any of them in all that time, ever.

Sounds like somebody got a program working right and, instead of tweaking it some more and breaking it again, quit.

After decades of information technology it's ABOUT TIME that happened.

WAYTAGO!

Re:Sombody finally FINISHED a program!

[bcrowell]

Oh, God, your sig makes my head hurt. Which George Bush? Carter and Bush I were both good presidents.

Re:Sombody finally FINISHED a program!

[ConceptJunkie]

Sounds like somebody got a program working right and, instead of tweaking it some more and breaking it again, quit.

Yeah, because requirements never change.

Re:Sombody finally FINISHED a program!

[Ungrounded Lightning]

Sounds like somebody got a program working right and, instead of tweaking it some more and breaking it again, quit.

Yeah, because requirements never change.

Sometimes they don't. B-)

Re:Sombody finally FINISHED a program!

[ConceptJunkie]

Yeah, because requirements never change.

Sometimes they don't. B-)

You're right. Sometimes they just get cancelled. :-)

Re:Sombody finally FINISHED a program!

[syousef]

Sounds like somebody got a program working right and, instead of tweaking it some more and breaking it again, quit.

MYSQL is almost completely bug free? News to me.

Re:Sombody finally FINISHED a program!

[tayhimself]

Time to burn karma points, but why are people being such assholes about the GP/OP. So he may not be the poster child for database experience and administration but there is really no need to belittle him/her.

Re:Sombody finally FINISHED a program!

[andrikos]

"It's about time" in a mysql thread? Anyone thinks about a marine DB?

Re:Sombody finally FINISHED a program!

[ConceptJunkie]

Um, YMBNH. Besides, it's mostly in good fun. We're guys... and nerds... a little friendly belittling is tobe expected. You should see my friends... they're brutal compared to this. :-)

Do you suppose...

[Anonymous Coward]

that the rest of the guys on the MySQL project will abandon ship and just start up a new MySQL project (OurSQL or somesuch) on the codebase?

Drizzle?

[Joe U]

Has anyone here used Drizzle?

I'm about to start a new web project and I get to choose the DB. I'm concerned over the lack of stored procedures though. My last big project used SP's for everything and honestly, while initial coding was a pain, in the long run it was a huge benifit.

I need a lean and mean webDB, so, if not Drizzle, does anyone have other recommendations?

Re:Drizzle?

[nicolaiplum]

Don't use stored procedures. They concentrate computation in the database server which is harder to scale than the application servers. Use simple queries to suck appropriate amounts of data out of the database and process them in an app somewhere else.

Re:Drizzle?

[afidel]

That advice is only appropriate in the expected query results are small, on large tables using stored procedures can significantly reduce the load on the DB by not requiring it to handle open connections while a large amount of data is streamed to the remote client.

Re:Drizzle?

[krow]

Hi!

We are still working on the first version of Drizzle. While folks are using it, I don't really recommend it at this point. When we feel like it is ready for adoption we will publicly start recommending it.

Cheers,
      -Brian

Re:Drizzle?

[lysergic.acid]

why is a post about a DBMS forked from MySQL, and mentioned right in the summary, being modded Offtopic?

personally, i hadn't heard of Drizzle until today. i'm pretty curious about what others think of it too if anyone has experience with it.

Re:Drizzle?

[Anonymous Coward]

Don't use stored procedures. They concentrate computation in the database server which is harder to scale than the application servers. Use simple queries to suck appropriate amounts of data out of the database and process them in an app somewhere else.

You obviously have very little experience in database application design.

Re:Drizzle?

[Nefarious Wheel]

Don't use stored procedures. They concentrate ...

You obviously have very little experience ...

Horses for courses, mate. There are good arguments in either direction. Personally I tend to avoid stored procedures not for performance reasons but for pragmatic ones. For one, it's easier sometimes to get a change approved in an application than it is to talk someone into approving a change -- any change -- in the database schema, no matter how trivial, and for another it's easier to migrate or replicate a database to another platform's database (say, Oracle to DB2 for example) when you're only worried about transferring tables and views, not logic. And it is true that the simpler it is, the easier it is to scale. Databases tend to scale by lock-managed clustering, applications by horizontal means (sometimes simply adding another apps server). One tends to be easier than the other.

Sucking data out in bulk can be a good idea too, for safety reasons -- I've seen bank OLTP databases frozen because someone thought it would be safer to set a read-only lock on a report scan, not realising they were using the wrong consistency setting across the entire database & thus forcing the rest of the users (thousands of them) to operate off the DB's log file, then killing the job mid-way after a few hours only to discover he had to face a few hours rollback....

Like I say, horses for courses...

Re:Drizzle?

[Samah]

Don't use stored procedures.

That's a very narrow-minded statement. The application I maintain has an Oracle 10g backend, Pro*C middleware, and a Java fat client. The standard process for an action in the application is to ask the middleware to run a certain stored procedure in an Oracle package.

Given that this application is huge (I'm talking 1000+ tables, some with up to a million rows) and there are at least 1000 concurrent users, it's very convenient to have the logic on the server-side. Any code change to the client requires an outage (to replace the jar file), which is BAD if it's an emergency fix. By putting all the logic (and access to a vast amount of data) server-side, it reduces network traffic, allows easy rollbacks, and allows the support team to apply a fix without an outage.

Some more great things about our setup is that Oracle packages and triggers support networking. We have a publish/subscribe system tied to triggers such that when one user makes a change, it's instantly reflected on every other user's screen.

Obviously this solution isn't best for all situations, but it fits our needs very well. YMMV

Re:Drizzle?

[afabbro]

Don't use stored procedures. They concentrate ...

You obviously have very little experience ...

Horses for courses, mate. There are good arguments in either direction.

Yes. Which is exactly why sweeping generalizations like "don't use stored procedures" are idiotic. There are a wealth of cases where stored procedures are best practice.

Re:Drizzle?

[rbanffy]

It's sad. MySQL does not deserve a lot of its user base ;-).

Re:Drizzle?

[codepunk]

It is also appropriate if you do not want a vendor bending you over every year for a support contract all because
you put all the logic in the database and cannot easily port it.

Re:Drizzle?

[codepunk]

Stored procs do have their place, but now say for instance your company needs to reduce some costs this year. You know
shrinking economy and such, so oracle comes a knocking for their annual or is that anal bend over the IT budget and ram it home support contract costs. Or perhaps your customers are not really very passionate about having to drop a million for a single database instance to run your software. Yes, now you are in between a very big rock and a hard place, all the logic is now
embedded in a proprietary database requiring a rewrite of the entire system to support a cheaper alternative. My personal feeling is to try to keep code out of the database unless I really, really need to resort to a stored proc.....Oh hell what am I flapping my gums about I would never use a proprietary database in the first place.

Re:Drizzle?

[afidel]

Your definition of huge is funny, I have tables that are growing a million rows a month and that's for a small S&P 500 company. I have a friend who does joins on multiple tables with 300+M rows every day. I'm not bragging because my DB is huge (it's not) but more commenting on the fact that so many slashdotters seem to lack a perspective on what a truly large DB is.

Re:Drizzle?

[Joe U]

I disagree.

The database server is designed to handle data efficiently. Most large DB's, Oracle, SQL Server, Sybase, DB/2, etc.. have years of experience in doing one thing, handling large amounts of data efficiently. Application servers are multifunction tools, while they are used to handle data retrieval, it's not their primary purpose, they have other things to do and can do them more efficiently.

While I think it's great to be able to throw ad-hoc queries down to the DB from the app server, I found that I'm better off in the long run creating a well defined interface to the data. I'm also happy that I can lock out all queries from the web servers, so in the event someone does manage to break the web server's security, all they can do is process data through the interface, and not inject something into the query processor.

All that being said, it depends on the task at hand. If all you're doing is a few small queries, then yeah, the app server is easier. If you're going to dump 50,000 records with multiple tables, the db server is where it belongs.

Re:Drizzle?

[Joe U]

Thanks for the heads up.

I'll tinker around with it in a test VM for now.

Re:Drizzle?

[Anonymous Coward]

Why would a stored procedure port be harder compared to a ad-hoc query port?

Re:Drizzle?

[Zarluk]

I need a lean and mean webDB, so, if not Drizzle, does anyone have other recommendations?

PostgreSQL!!! You'll get a stable DBMS, stored procedures, triggers -- and it's pretty fast handling large tables if properly tuned ;-)

Re:Drizzle?

[Splab]

That's a load of crap.

No matter what DB you chose you are going to be tied in whether you use SP's or "dynamic" SQL.

If you go for SP's you have the benefit of only having to port the database - not the programs, the reason? Calling stored procedures are on most databases the same so you could in theory just port the database and the application layer would be none the wiser.

Re:Drizzle?

[Splab]

So instead of changing a database, putting in the same SP's your suggestion is to have 100's of coders changing all the dynamic SQL?

Also using dynamic SQL means any programmer within the organization can do whatever the f*** he wants, and trust me, most people have no idea what they are doing with databases.

Give me SP's any time.

Re:Drizzle?

[Samah]

It seems my estimate of 1M was rather off. I just did some SELECT COUNT(*) from some of the frequently used tables and got about 20M per table. That's "used per day", not including historical records. I don't lack a perspective; in this case "huge" means "larger than most private clients". When it comes to "large databases", there's a difference between "huge" and "behemoth" (ie. Google).

Re:Drizzle?

[asc99c]

Have you considered Firebird? I was recently introduced to it and it looks like a better option than MySQL / Drizzle.

The other obvious option is PostgresSQL, which looks fairly comparable to Firebird - the only reason I'm going with Firebird is that I can reliably remember how to pronounce it!

Re:Drizzle?

[Anonymous Coward]

Given that this application is huge (I'm talking 1000+ tables, some with up to a million rows)

Might I suggest you redesign and refactor?, seriously. Take the functionality, identify the separate components, define loose coupling interfaces between them, and split them up.

Any system that has 1000+ tables is not a single system, it's a horribly designed mash of several.

Re:Drizzle?

[shutdown -p now]

Don't use stored procedures. They concentrate computation in the database server which is harder to scale than the application servers.

How exactly are database servers hard to scale?

Re:Drizzle?

[mattcasters]

Sure, but the scalability arguments of the grand parent poster holds.
Scripting languages like PL/SQL are not the most performing by definition and had me in a performance fix more than once I must admit.
At the same time, object relational mapping technology (Hibernate and all) have advanced to such a state (even for .Net it seems) that it feels completely wrong to me to put too much application logic in the database. Database independence comes rather cheap these days.

Sure, I'm not an extremist, I can see the use-case for a trigger here and there and a well chosen stored procedure. However, do you really want to keep programming in hard-to-compile-elusive-error-message-generating-2nd-generation scripting languages? For me the answer is clearly "no!".

Re:Drizzle?

[Samah]

When I said 1000+ tables, I was identifying the entire system. The components/subsystems ARE separated and DO have loose coupling.
It's not "horribly designed", it's just 15 years old and has had 15 years worth of enhancement requests.

Re:Drizzle?

[Anonymous Coward]

Has anyone here used Drizzle?

Yeah, fo' shizzle

Re:Drizzle?

[Anonymous Coward]

That's why good developers don't put any business logic in the client either. Think separation of concerns; ie. N-tier architecture (where N is normally 3). Presentation logic in the client. Business logic in the application server, and storage handled by the DB.

Opt for loose coupling between all layers so switching out any particular layer isn't a problem.

As long as you're running redundant servers, switching out any particular node that handles the application logic can be done without any client outage too.

Some of your arguments are very much straw-man based. Less network traffic? Pull the other one... It sounds like you ought to consider restructuring your queries if network traffic drops so much by using stored procs. Makes rollbacks easier? Care to explain that one?

I've worked on systems like the one you described in the past and inevitably the lines become too blurry as to where things are done - patches become way more difficult than they ought to be, new developers coming on board take a lot longer to get their heads around what's going on, business logic ends up being duplicated in the confusion, components end up too tightly coupled with each other, and at least in the couple of projects I've witnessed that use this approach, they've ended up underdelivering relative to their peers.

As for triggers being used to update users screens, frankly that sounds a bit mad. If you had your object model defined in such a way that users of the model (ie. inside your application code) could register to listen for update events that are in turn published to clients who need to know about them, I'm sure you'd end up in a much happier place. This is the idea behind the MVC patter. It would mean less wasted overhead (only interested clients - those that are currently viewing a particular piece of information - need to be informed of changes to the data) etc etc etc.

Having a rich domain model has many other benefits too - for example adding an in-memory cache is made dead easy, particularly if you use a persistence framework for your application development.

Sorry about the rant - I know different styles suit different folks - I'd just hate to see others paint themselves into a future maintenance nightmare without having seen a counter-point to your post.

(YMMV too).

Posting anonymous because it's late, I'm drunk and probably won't want to have this on my permanent record tomorrow.

Re:Drizzle?

[mlwmohawk]

Don't use stored procedures. They concentrate computation in the database server which is harder to scale than the application servers.

Ahh, sadly this is what "MySQL database thinking" has wrought.

The mystical grail of the enterprise "scaling." Like many things, conventional wisdom often evaporates when confronted with facts. Can stored procedures load the server? Sure, if you are doing something bad. For the most part stored procedures reduce server load.

(1) Stored procedures can be "pre-compiled" SQL which saves CPU time in the planner. (In databases with such an architecture).

(2) Stored procedures allow data selection beyond mere SQL and can lead to the reduction of data transfered from server to application.

(3) In PostgreSQL, for instance, one can create an index based on a function (like a stored procedure), so:

create index on mytable myindex (foobar(mycol) );

select * from mytable where foobar('froboz') = foobar(mycol) ;

Generates a query that uses and index and doesn't do a full table scan.

(4) Computers today are seriously fast, so much faster than the data storage systems that CPU capability is almost infinite with regards to I/O. Any CPU work that can be done at the server to reduce I/O load will probably improve general scalability.

Basically, stored procedures and functions would not exist, i.e. no one would have created them, if they did not help. Saying that "don't use stored procedures because they load the server" is the same logic behind "don't use power tools because they are dangerous." Yes, if you are ignorant, power tools present a huge danger, however, neglecting them means a lot more work. It is better to educate ones self and use the more powerful tools. Those tools would not exist if they did not provide a positive contribution.

Re:Drizzle?

[gbjbaanb]

Stored procedures are the fastest way to get data from a database. ORM cannot compete. Think about what happens under the covers of the ORM framework to see that this is always true.

PL/SQL isn't a scripting language, its a query language (ok with bits added that you don't have to use) designed to get data from a DB, and the DB is designed to give data using it.

ORM stuff is for developers who want to get data without having to learn SQL, or go through a DBA, or to make programming data-access easier. That's all. Its not a better way of accessing the DB, its not more efficient (far from it in some cases), but its easier for the application programmer. That's why it feels wrong, its designed for your mind-set so it feels like it integrates with your programming. Its like how buying shoes feels so right if you're a woman. You or me, we know 2 pairs of shoes is optimal.

So if you have a small DB then feel free to use it. If you have a very large one, you'll want to ask your DBA how to do things. I guarantee he won't tell you to use the wizard to setup the ORM for your app!

BTW, if you are trying to put logic in your DB, you're using it wrong. A SP is for fetching subsets of data, you should further filter and manipulate it in your application server.

Re:Drizzle?

[codepunk]

Can you say database abstraction layer? Don't leave home without it.

Re:Drizzle?

[CrazedWalrus]

You go talk to EnterpriseDB, who've been working on Oracle compatibility for Postgres. I can't speak for it personally, but you might be able to get away with the cost of a conversion project to a similar database (read: close, but not equal). At that point, it's pure savings.

Oracle has features PG doesn't have, sure, but ask yourself: how many of them are you actually using? Of the one's you're using, can they be done differently -- maybe by tying in a different FOSS project or home-growing a solution? If you "think outside the box" a little, I think you'll find that those features are generally nice to have, but not really worth the million bucks a year you're paying to have them, and by applying different solutions, you probably won't lose much functionality anyway.

Is that true for everyone, no. I'm sure someone will tell me about their absolutely necessary Oracle-only feature that they're using, but the fact is that there are lots of projects on Oracle could have used MySQL and not lost anything.

Re:Drizzle?

[CrazedWalrus]

I see your point, assuming the DBAs or "database developers" write the SPs. Unfortunately, that hasn't been the case in any of the large companies where I've worked (Wall Street mostly).

In these, the same guy who writes Java writes stored procedures. I've seen some pretty horrific SQL in my time - manual "joins" using cursors, for example - but at least they were in stored procedures to optimize performance. (?!)

Re:Drizzle?

[Nefarious Wheel]

Stored procedures are the fastest way to get data from a database

Not always, no. Sometimes stored procs do horrible things involving the repeated creation of temporary tables, in algorithms that could be done more efficiently externally. Triggers are generally safe, constraints are generally safe, but you need to remember to trace carefully what your SP's are doing to make sure you're not in that boat.

Re:Drizzle?

[Joe U]

In these, the same guy who writes Java writes stored procedures. I've seen some pretty horrific SQL in my time - manual "joins" using cursors, for example - but at least they were in stored procedures to optimize performance. (?!)

But at least the DB code can be reviewed and re-written without touching a line of code in the application.

Re:Drizzle?

[Joe U]

Can you say database abstraction layer? Don't leave home without it.

No, not in a custom app. If I was writing something for widespread disribution then I would add an extra layer, but I'm not going to add that to a static platform.

Re:Drizzle?

[Samah]

I was being very vague in my description of the publish/subscribe system, because it's a lot more complex than that, and I couldn't be bothered explaining it all in that post. Triggers insert an event row into a table that's picked up by a Pro*C daemon. That daemon executes stored procedures that call networking code to connect to another daemon that handles the publishing to subscribed clients. The clients register for certain event types with filters for the data they want to be notified about, and only that data is published to a particular client.

I only mentioned network traffic because I was trying to think of something extra to list. Rollbacks are a little easier to handle in our situation because table locks don't need to be preserved between client<->server communications.

I agree that realistically business logic should be placed in an application tier, but this was the design choice that was made 15 years ago, long before I joined the team (personally I would have shot whoever made that choice if I'd been there). I also agree that new developers find it difficult to adjust, but unfortunately that's just the way it is in our situation.

And I don't think you'd have to worry about posting AC; you didn't say anything nasty. :)

Re:Drizzle?

[afidel]

Most commercial offerings already support multiple DB's and doing so in your own apps should be trivial with a sane design, the SQL calls should all be abstracted into their own chunk of code so only that piece needs to be touched. I think either extreme approach is a bit insane, use a bit of both a know when each is appropriate.

Re:Drizzle?

[Anonymous Coward]

Not the least of which is in web apps, where using SP's can help sanitize inputs for you.

Seriously, concatenating input, even sanitized input, into a query string is just begging for trouble.

That leaves SP's and prepared statements, and SP's only have to be parsed/compiled once, PS'es have to be parsed/compiled each time they're initialized.

Re:Drizzle?

[abirdman]

do you really want to keep programming in hard-to-compile-elusive-error-message-generating-2nd-generation scripting languages?

Thank you, thank you for pointing that out! I've written SP's in Oracle, MSSQL, MySql, and PostgreSQL and they're all horrible, non-standard, difficult to debug, poorly documented, exhibit seemingly arbitrary limitations, and are so completely different from one another you might as well be writing in a different language. MySQL was a particular bother to learn, because of the necessity to escape the whole script ("delimiter %%" anyone?) because the command line interpreter wasn't designed to accommodate multiple statements directly, and the documentation has not caught up with the new feature set. Uggh. I've also had PostgreSQL functions slow down to the point of uselessness, only to be miraculously revived on recompiling. And while most DB's have reasonable query analysis tools to pinpoint problems in specific queries and views, the tools for analyzing SP's tend to be much less refined.

I use sp's, functions, and triggers because they're useful, and having then in the database means they only have to be developed and maintained in one place, but I'll never think of them as a simple solution.

Re:Drizzle?

[mattcasters]

This is all just FUD. Large amounts of data are not typical for a transactional database in the context of ORM.
Maybe you're the type of person that writes reports on the source system in PL/SQL? (Are there still people like that left?)

Anyway, another limitation of stored procedures is in the lack of parallelism and the lack of scalability is a direct result of that.
In a 3-tier environment, you can add more application servers (in a cluster for example) to improve performance.
Stored procedures are exceptionally hard to run in parallel and even on Oracle you couldn't get it done in the days I still wasted time with PL/SQL.
Finally, it's a question of responsibilities: a database server manages the data. An application server manages the application logic.

Re:Drizzle?

[gbjbaanb]

I think you're labouring under the impression that you use a SP for logic, which is wrong.

Once you create a SP, to retrieve a load of data that is further manipulated by your app servers, you find your execution plans are precompiled and cached, your locks are held much less, in fact the whole thing gets well optimised by the DB engine.

SPs do not need the kind of parallel running I think you're referring to. Firstly, the DB engine is very efficient at extracting that data, in parallel if it wants. It can do it much better than you running 2 queries at the same time. In a large scale system, you're going to have lots of connections executing simultaneously anyway, so this is a pretty pathetic point to make.

Let me put it this way, if you write an ORM to retrieve data that you then filter to weed out the bits you don't want, you will kill your performance. If you write a SP to retrieve only the data you want, you are using the DB in its most efficient way, and reducing the size of the caches needed, and reducing the transfer and the memory needed in the connections. Things go faster then.

If you write 'select a,b,c from customer where cust_num = x' then your ORM will be almost as fast as a SP.

If you have a customer table, customer history, products tables and you want to retrieve a full view of all the customer details.. then a SP will be quite a bit faster than your ORM.

Go profile a complex query yourself - see what the profilers say about your ORM v the equivalent SP.

Re:Drizzle?

[Anonymous Coward]

Has anyone here used Drizzle?

I'm about to start a new web project and I get to choose the DB. I'm concerned over the lack of stored procedures though. My last big project used SP's for everything and honestly, while initial coding was a pain, in the long run it was a huge benifit.

I need a lean and mean webDB, so, if not Drizzle, does anyone have other recommendations?

Try Ingres. Stable, multiplatform and very easy to maintain.

Re:Drizzle?

[mdahlman]

Yes. Which is exactly why sweeping generalizations like "don't use stored procedures" are idiotic. There are a wealth of cases where stored procedures are best practice.

I agree. All sweeping generalizations are always wrong.

Re:Drizzle?

[NateTech]

Informix.

Re:Drizzle?

[Anonymous Coward]

Stored procedures are the fastest way to get data from a database. ORM cannot compete. Think about what happens under the covers of the ORM framework to see that this is always true.

Consider the case of an ORM framework that is asked to retrieve a domain object hierarchy that was recently used and is therefore stored in an in-memory cache. In that case, how can a stored proc possibly compete? Even if the ORM wants to check that it's copy is up to date, this would only involve checking version stamps, not the entire object tree.

Ceding control to an ORM framework can not only make your life easier as a developer (as in writing less code that is less complicated), but it can also actually IMPROVE performance without you, the developer, having to do anything differently except for turning on caching!

The end result is that you have more time left over for beer, pizza and reading/replying to posts on slashdot :D

Re:Drizzle?

[Anonymous Coward]

Not the least of which is in web apps, where using SP's can help sanitize inputs for you.

100% agree that sending data to the DB without strict validation is a bad idea. Doing that validation in the DB doesn't seem smart either though - not least for the fact that the DB is the specific entity that you're trying to protect!

Re:Drizzle?

[Anonymous Coward]

Your loss. Accessing your data through DAO's doesn't involve a lot of overhead and makes changing stuff later a relative breeze. Even if you only end up providing concrete DAO implementations for one particular framework (hibernate/ibatis/raw SQL) etc I'm sure you or whoever's left to maintain your code when you've moved on will be thankful when the CIO wants to change his preferred DB vendor (because they paid for a ritzier night out than the other guys). Don't laugh - I've seen it happen.

It's a lot easier to maintain things if you can see all the DB access code in a related package.

Re:Drizzle?

[TheSunborn]

But why should rewriting the sql to a new database be any less work then rewriting the stored procedures?

Drizzle...

[Anonymous Coward]

For shizzle!

Goodbye MySQL

[progrmr]

See, this is why MySQL should never have signed on with Sun - I dig Java, but I really dig MySQL and its clear that the difference is Sun. This sucks - seems like the end of MySQL. Maybe I should focus on .NET and SQL.

Re:Goodbye MySQL

[corsec67]

Or use a better DB: PostgreSQL

Re:Goodbye MySQL

[gbjbaanb]

maybe it'll increase the adoption of postgresql instead, or at least prompt developers to write their queries so they run on both databases.

Re:Goodbye MySQL

[progrmr]

I am downloading postgre right now, after I uninstall mySQL.

The real question here is...

[Anonymous Coward]

who IS the drizzle?

Jay Pipes Moved Over to Drizzle Too...

[bcolflesh]

http://www.jpipes.com/index.php?/archives/263-So-Long,-and-Thanks-for-all-the-Fish.html

Interesting comment at the bottom (#11):

"Glad to hear you'll be working full-time on Drizzle. Even if you didn't escape Sun.

I can't imagine who would want to be a community manager under the current situation, though. Good luck to Giuseppe."

Noooooo!!!!!!!!

[Metroid72]

David, don't quit in this market.
Unemployment is rampant and you'll likely be lowballed for your new job.

MySQL greetings

[martenmickos]

Thanks slashdotters for being passionate about all topics FOSS and MySQL!

David's departure is in all ways amicable, and he will continue to be an ambassador for MySQL and for free and open source software in general. For some time already, David was working only part-time for MySQL. After about 25 years of working on MySQL and the projects that preceded MySQL, he very much deserves do whatever he pleases to.

Marten
SVP Database Group at Sun
(previously CEO of MySQL AB)

Re:MySQL greetings

[Atlantis-Rising]

Would you say otherwise if it wasn't amicable?

Re:MySQL greetings

[martenmickos]

I think if you ask people who know me, they will say that I stand for transparency and truthfulness.

If the departure had not been amicable, I guess I would not have commented on it at all, or I would have focused my commentary on whatever other positive aspect I could find.

But the best may be to ask David directly. I don't want to publish his email address here, but it is not difficult to guess. Most early employees of MySQL AB, like myself, use firstname at mysql dot com.

Marten

P.S. Generally I am somewhat perplexed by the attention this topic is getting. The beauty of open source is that you can be actively contributing and participating in your favourite project whether you are employed by a certain company or not. So what's the big deal about David choosing not to be employed? He is not abandoning MySQL. With the enormous payout from the acquisition, the founders can now allow themselves to pursue whatever interests and daily routines they like. Good for them, and I think we should all just be happy that open source can provide not just software freedom but also financial freedom. Just my 2c.

Re:MySQL greetings

[Angostura]

I would rather expect "an ambassador" for MySQL to be saying that kind of thing in here himself, if he agrees with your appraisal of the situation.

Re:MySQL greetings

[krow]

If you look around there are couple of articles that quote David on why he is leaving. It is perfectly amicable, he just dislikes paperwork and would prefer to not deal with it.

      -Brian

Re:MySQL greetings

[martenmickos]

And so he did. See elsewhere on this thread the posting with subject "David Axmark" and ID (#25309745).

Marten

Re:MySQL greetings

[oldhack]

Thanks slashdotters for being passionate about all topics FOSS and MySQL!

Sounds suspiciously like Demogran. Let's stop pestering them, lest they will shoot courtesy guided missiles at us.

Re:MySQL greetings

[Anonymous Coward]

P.S. Generally I am somewhat perplexed by the attention this topic is getting. The beauty of open source is that you can be actively contributing and participating in your favourite project whether you are employed by a certain company or not. So what's the big deal about David choosing not to be employed?

Because usually NDAs and Non-compete agreements prevent just that.

Re:MySQL greetings

[kestasjk]

Keep up the good work, MySQL is excellent.

Re:MySQL greetings

[maestroX]

Generally I am somewhat perplexed by the attention this topic is getting. The beauty of open source is that you can be actively contributing and participating in your favourite project whether you are employed by a certain company or not. So what's the big deal about David choosing not to be employed? He is not abandoning MySQL. (..) Just my 2c.

Your cents are worth it :-)

Who has contributed or donated to the MySQL project while actively using MySQL in a production environment?

I am somewhat perplexed by the attitude of some users towards open source. Software? FREE. Support? FREE. Developer wishes to change jobs? NOT FREE.

What the f*ck are we thinking?

Re:MySQL greetings

[Larryish]

If you look around there are couple of articles that quote David on why he is leaving. It is perfectly amicable, he just dislikes paperwork and would prefer to not deal with it.

And so, in honor of this momentous occasion, October the 10th, 2008 shall be forever known as "Dave Axmark No-Paperwork Day".

Dave Axmark No-Paperwork Day: Any paperwork that comes to your Inbox, STAYS in your Inbox.

Re:MySQL greetings

[Anonymous Coward]

Handy link: http://developers.slashdot.org/comments.pl?sid=989907&cid=25309745 (anonymous post since otherwise I'm karma whoring)

Re:MySQL greetings

[Anonymous Coward]

The reason for the attention and big deal is simple. Sun is where technology goes to die. There are many people who don't want to see MySQL die. Between things like this, and the apparent stalling of the 5.1 release process, the many of us who have worked on technology and for companies that have been acquired by Sun, only to see them mismanaged into extinction have seen the red flag here.

There doesn't have to be a dispute, or bad blood for a project to be run so poorly that highly motivated and talented people get bored and abandon their projects for greener pastures.

Granted I know nothing.....

[Anonymous Coward]

About databases but couldn't you build some saleability into it so that you could be reasonably certain that it could easily carry you forward for many years? Shouldn't all new IT solutions be forward thinking enough to avoid obsolescence whenever possible?

Re:Granted I know nothing.....

[Anonymous Coward]

Wow. Are you a manager? Don't ever use that one on your employees, or they'll laugh at you as soon as you leave.

Man makes millions, quits his job!

[Anonymous Coward]

That's some real news.

Something fun to try

[Anonymous Coward]

This will give you some fun:
SELECT * FROM tbl1 AS t LEFT JOIN tbl2 AS u ON u.key=u.key

It's bad syntax and apparently an infinite cross product or something. The join criteria is stupid, but that will create a giant temp file and maybe crash your server. Killing the thread with the admin GUI doesn't seem to matter much or at least takes so long I couldn't tell if it just killed itself or worked. It ran out of free space about the same time so...

So with user level access a syntax error gets you a DOS.

I'm a pretty big MySQL fan, but you don't want to let idiots use your server...self included.

Re:Does Sun have a competitive database?

[Anonymous Coward]

Sun does not own the Oracle database - Oracle owns the Oracle database. Wow.

- T

A database software with hunderds of bugs?

[seek31337]

zomg!

Bet oracle has, like 3. Postgres, too!

zwtf! Obviously no company could ever run on MySQL in this state. I am sure it constantly crashes.

Re:A database software with hunderds of bugs?

[seek31337]

Oh, and I am never putting MySQL on any of my servers until they fix bug #16565! The bastards!

Re:A database software with hunderds of bugs?

[TheRaven64]

You think that's bad? Take a look at the LLVM bugs sometime.

David Axmark

[Anonymous Coward]

Lots of press about a not to large event. I have been working less with MySQL over the past several years (as the company has grown). And when we got acquired we got to big for me (I like to know everyone in a company).

A huge part of my work have been spreading FreeSoftware/OpenSource and I will continue to do that. And tell about the MySQL story many times more hoping to inspire others to try to start FLOSS businesses.

And I hope to meet many of all the people who made MySQL such a sucess many times over the coming years. /David (who posts so seldom he does not remember his slash login/password..)

 

Oracle also took down Berkeley DB

[SgtChaireBourne]

...

If Sun bought MySQL to further the project, then where is the evidence that this is happening?

If Oracle bought InnoDB to further the project, then where is the evidence that this is happening?

...

Oracle also took down Berkeley DB. It's still there but buried rather deeply. If Oracle is contributing to BerkeleyDB, then now is a good time to be vocal about it and collect some good karma.

Re:Oracle also took down Berkeley DB

[Anonymous Coward]

Yeah, really buried. One google search for "berkeley db" leading to the product page, from which multiple links take you to a page with a big shiny red "download" button. In other words, it's as accessible as it was from Sleepycat. Oracle's site search sucks, so I can understand why one might think it buried.

Now what they have buried is all the docs from companies they bought, bringing them under their crappy doc portal using a redirect, with the same crappy search.

Re:Oracle also took down Berkeley DB

[Anonymous Coward]

Oracle has release several updates to Berkley DB, version 4.7 of the DB, 3.3 of the java edition and 2.4 of the XML DB have all been released in the last few months. This is the second or third update that I can remember from Oracle on the Berkley front. I guess they are just quiet about it.

Re:Oracle also took down Berkeley DB

[Anonymous Coward]

Cyclists use the road by right, motorists use it by license.

Yes. It's a travesty that cyclists are not required to pass some kind of test in order to use the roads. -- From a fellow cyclist tired of the fresh crop of idiot cyclists we get here every September.

What's the Big Deal?

[RAMMS EIN]

What's the big deal? One developer leaves the MySQL team, after MySQL has been bought by Sun. Ok. The two may or may not be related. And it may or may not indicate that something is making the developers unhappy.

MySQL has hundreds of bugs open against the upcoming release. Ok. Is that a lot? It does sound like it. On the other hand, it's hard to say what this means for quality. It means all these bugs have been _found_, which is good. Now they just need to be fixed.

In the meantime, existing versions of MySQL will continue to work as well as they have always worked. If that isn't good enough for you, there are always other databases. I prefer PostgreSQL, myself. On the other hand, if you really want to use MySQL, but some bugs are getting in your way, you can always go and fix them yourself.

I really don't see the big deal. Even _if_ something is going terribly wrong with MySQL at Sun, nothing is lost; except, perhaps, the happiness of the developers - who would have my sympathy, in that case.

What's Going On With MySQL?

[zonker]

More like "What's Going On With Sun?". Their last big hit was Java and that was quite some time ago...

Perhaps you can call StarOffice "big" for allowing the creation of OpenOffice. Sun isn't exactly the proud company they used to be.

Derby

[Kupfernigk]

Sun doesn't, but if you live in the Java world have you looked at Derby recently? We started out using it as an authentication database embedded in an app, and are now making more and more use of it. It supports transactions and hundreds of simultaneous connections, has very flexible configuration, and supports up to about 50Gbytes of storage. The last alone makes it more useful in many applications than the free versions of MS SQL Server. There are many applications currently running on MySQL which (in my opinion) would benefit from migrating to a tightly coupled all-Java solution. The Derby footprint is tiny, database backup and failover is now supported, and you can work with anything from the command line tool to the usual studio type applications. It has taken me 4 years to become a convert, after 8 years of MySQL, but now in the latest release I love it.

Re:Derby

[Anonymous Coward]

Derby is slow, but there are other open source Java databases: H2, and HSQLDB.

Re:Derby

[Anonymous Coward]

Derby is NOT slow. It can handle lots of concurrent users in TPC-B and TPC-C benchmarks with being rock solid. When it comes to database performance, scalability is an important factor versus running some non-standard single-user benchmark database queries like some other databases excel at doing and publishing.
http://wiki.apache.org/apachecon-data/attachments/Us2005OnlineSessionSlides/attachments/ApacheCon05usDerbyPerformance.pdf
(from 2 years ago and performance has improved even a lot more in the last 2 releases).

Re:Derby

[Anonymous Coward]

To say that "Derby is slow," without any support and as if it is a maxim from God, and to state the names of some other "open-source Java Databases" as if they are comparable or come anywhere close to Apache/Derby, demonstrates best a complete lack of appreciation of what kind of database Derby is, what it supports and how well it does. The commentators should have at least noticed how Kupfernigk's post mentions "hundreds of simultaneous connections" supported by Apahce/Derby (a.k.a. Java DB, as distributed in the Java Developers Kit).

C++

[GNUPublicLicense]

They are putting a lot of C++, which has a "software cost"(size and complexity of the compiler) which is, as far as I am concerned, not reasonable. Drizzle is the same: they chose C++ for the fork. I would love to see a mysql fork rewritting the C++ bits using C.

PostgreSQL

[leandrod]

Faster, more scalable, richer, more stable, more standards-conformant, more free.

because of persistence frameworks

[Anonymous Coward]

Why would a stored procedure port be harder compared to a ad-hoc query port?

First example that comes to mind: you're using a persistence framework such as hibernate or JPA where the restructuring of queries for different database backends is handled automatically for you (all you need to do is update the configuration file and away you go).

Re:because of persistence frameworks

[FuckTheModerators]

Persistence frameworks? I guess you don't care about database performance then. Like Java, they may make your app portable, but it'll most likely never use the full capability of the RDBMS you're attaching to. Write once, run anywhere but slowly.

Re:because of persistence frameworks

[abigor]

For most applications, some things are more important than speed - maintainability, portability, and time to market. "Fast enough" is good enough. Persistence frameworks allow you to focus on the stuff that matters - the actual business logic - and get the stuff out the door faster, to more clients, for more sales. Which is what it's all about.

Re:because of persistence frameworks

[Samah]

Yet another "Java is slow" bashing. Sigh.

Re:because of persistence frameworks

[Anonymous Coward]

Write once, run anywhere but slowly.

It's a shame you don't back that up with anything more substantial or I'd have had a better attempt at a rebuttal. I'm going to do the best I can with what you've given me though...

The first point you make is that of persistence frameworks not using the 'full capability' of the RDBMS. I'm not entirely sure what you mean by this - a framework like hibernate will optimize queries for the particular DB that you're using.. whatever that may be. Want to change DB? simply change the config file and your queries will be updated accordingly.

I would have to assume therefore that perhaps you're really trying to say that using features like stored procs/triggers/advanced queueing/in-built xml parsing/blah/blah/blah in the DB will actually increase performance.. My personal opinion is that this type of thinking is now outdated - ESPECIALLY now that people are developing apps using the frameworks that you seem to despise so much.

My main reason for saying this is that modern data access frameworks make in-memory caching of data dead simple. Relying on stored procs/triggers/whatever DB features you think are so wonderfully beneficial to performance IMO makes it harder for these frameworks to help you out. Using the 'advanced features' of databases also tends to make applications harder to develop and maintain, less portable and ultimately less performant in a lot of cases unless you REALLY REALLY REALLY know what you're doing (and if that's the case, and you truly have weighed up the alternatives and decided to place your eggs in the DB-as-appserver basket, good luck to you!).

People who are a lot cleverer than I am came up with the 3-tier-architecture pattern and I tend to think that their reasons for doing so were pretty sound. I would expect any developers working for me to have a pretty damned well reasoned argument for why they would ever want to start offloading business logic to the DB..

Re:because of persistence frameworks

[Stu Charlton]

Speaking as a long time architect, who used to work for BEA, the "3-tier architecture" was a hold-over from limitations of 1990's-era database servers that required an external OLTP monitor like Tuxedo. It hasn't been necessary for many, many, years, but got promoted by "clever" folks that build application servers and persistence frameworks.

Persistence frameworks can be useful -- but they lull developers into a false sense of security that they don't need to know how the database works. You need to REALLY REALLY know what you're doing when you're building a large scale application on a persistence framework, the same way you would if you were building it with stored procedures. Most Java applications "get away" with using these frameworks because they create a completely proprietary data model that's tied to their object model, and never designed to be reused by multiple applications. Naturally there's a maintenance bottleneck with schema changes there, but that's what stored procedures and views are for.

So, instead, we now have enterprise service buses and Web services to take the place of what a good shared database used to do.

The only reason stored procs, triggers, and advanced database features are considered 'outdated' or 'hard to maintain' are because a) they're not taught in Java class, b) developers are too lazy to learn them.

I've seen 50 KLOC Java systems that could have been replaced with maybe 1600 lines of PL/SQL. I know cases where 5-10K LOC PL/SQL systems were re-written by multi-year J2EE efforts, and the resulting system was much harder to maintain and consumed a heck of a lot more resources.

I'm not saying databases are the 'best' way to do things (Oracle certainly costs a lot of dough), but the reason technology trends wind up in certain directions aren't necessarily due to facts or progress, it's more to do with vendor politics mixed with ignorance.

Re:because of persistence frameworks

[Anonymous Coward]

Speaking as a long time architect, who used to work for BEA, the "3-tier architecture" was a hold-over from limitations of 1990's-era database servers that required an external OLTP monitor like Tuxedo. It hasn't been necessary for many, many, years, but got promoted by "clever" folks that build application servers and persistence frameworks.

I recognise your credentials since BEA is a company that I had a fair amount of respect for. I would therefore like to ask what is, in your opinion, a fair replacement for the 3-tier architecture, keeping security, performance and maintenance agility in mind as 3 key requirements?.

The only reason stored procs, triggers, and advanced database features are considered 'outdated' or 'hard to maintain' are because a) they're not taught in Java class, b) developers are too lazy to learn them.

It sounds like you're generally pretty down on the new-age development crowd. That's a shame and I think I'm generally a bit more of an optimist.

I agree that in a lot of cases, you can look at any given system and probably build something that is functionally equivalent in 1/2th the time and with 1/10th the number of lines of code using some other methodology. Lines of code is a pretty poor metric to use comparing two systems though, as is in many cases up-front development time. Who's system would have been faster to respond to a change in requirements such as "we want to deliver this to our clients as an iPhone app" or "DB vendor X is no longer our preferred supplier. Make your app work with Y", or "we want to be able to update the business rules ourselves now" etc etc etc. I know in your particular case these things might never have happened, but they are the sort of things that some of us have to deal with constantly. To my mind, 3-tier is the best solution I've seen for coping with an application and/or business that have fluid requirements.

Re:because of persistence frameworks

[FuckTheModerators]

Not the main point really. I just threw that in as it's a common reference point here. Regardless of its truth, that's the perception. Mainly trying to say that RDBMS-specific code runs better.

Re:because of persistence frameworks

[FuckTheModerators]

I'm all for N-tier architecture, and I'm also all for decoupling business logic from the database, and I'm also all for stored procedures and removing queries from the application. The app ought to have no clue what the db schema is.

"Using the 'advanced features' of databases also tends to make applications harder to develop and maintain, less portable and ultimately less performant in a lot of cases unless you REALLY REALLY REALLY know what you're doing..."
That's my point. You need someone who is that competent to run your database. Also, though it may make apps harder to maintain, it makes the db side of things infinitely easier, and if you've got competent developers writing the app code as well as competent dbas/dbdevs working on the rdbms, that's the best of both worlds.

People are very much developing apps using these frameworks, but IMHO and in practice they're spending more on hardware than they need to when they rely upon these toolsets.

A lot of people's livelihood depends on MySQL

[unity100]

including mine. unbelievable amounts of client sites use mysql, all web development clients use mysql, there is a HUGE market for php/mysql out there (bigger than anything similar i assure you), hell, even a goodly percentage of web runs on mysql ....

rest assured if anything happens to mysql, ill come there with a thick stick in my hand.

SUN can't use MySQL to compete with Oracle

[CuteSteveJobs]

I've used MySQL for small record keeping web sites where it worked very well, but I also worked at a company where they used MySQL for enterprise databases. They had many, many problems due to bugs and optimization problems caused by index limitations. They were very frustrated, but they were locked in. I left concluding that MySQL will never make it into the enterprise database market. If SUN bought MySQL for the kudos of supporting a popular open source DB, cool. But if they bought it expecting to take on Oracle & friends with it, they're going to be very disappointed.

I resign from Sun, too

[Anonymous Coward]

Alpha Centauri, FTW!

I know what's wrong....

[PontifexMaximus]

SUN MICROSYSTEMS! Wow, wasn't that easy? Those idiots at Sun can't do the smallest things right. They should never have been able to purchase MySQL except for the overwhelming GREED of the idiots who controlled it.

Have you noticed that that level of greed is all over the place now.

Yes, but which license?

[hey!]

GPL is normally a pretty good license, IMO, if you want to safeguard user freedoms. But it has bugs like any other human artifact, and MySQL illustrates this.

The client libraries for MySQL are licensed under either (a) a proprietary license or (b) GPL. The reason for this is to drive users who must use incompatibly licensed software to buy a non-free license for MySQL. This is contrary to the intent of GPL.

In theory, a user can download the MySQL client libraries since users are not required to accept the GPL. But vendors can't help them with it unless the other software they are providing is compatibly licensed. Furthermore, vendors adapting their software to work with MySQL are on questionable ground. Finally, if the user himself writes a program using the MySQL client, he can't convey that program to anybody else under a different license, even a free one, even though the work is only "derivative" in a trivial, legalistic sense.

This is why there is a LGPL. Downstream licensees can "upgrade" their license from LGPL to GPL if they wish, but not vice versa.

This means Sun alone has the legal right to dictate user freedoms. They can use the GPL to claim legal rights over the works of others, because they simply call the MySQL libraries. Sure, you can fork MySQL if you want, but you can't give the users their freedom. They have to buy that from Sun, even if they are using your fork.

Monty's false resignation

[swordgeek]

OK folks, it's time to put this rumour to bed. Monty hasn't resigned. Over a month ago, a bloody GOSSIP COLUMNIST claimed he had an 'exclusive tip' about Monty. Nothing came of it. It was just gossip. (Although I have to ask if the idiot who originally published the claim had gone short in Sun stock.)

In short, nothing to see here. Move along.

I'm not defending excessive CEO pay, but

[Kupfernigk]

Schwartz is at least a "real" CEO - i.e. he is in a company which has real products - not the "products" of the finance industry - he really knows a lot about the company and its products, and he is in a position to make a significant difference to how it performs. There is a huge difference between Schwartz and some near-psychopathic egomaniac parachuting in to a bank to make stupid investors feel confident.

I have no problem with the people who start, build up and long-term maintain real industry getting paid for it. I have a huge problem with people who have done none of these things (especially those who are really no more than gamblers) thinking they are entitled to excessive rewards from the moment they are appointed.

But.....

[sogoodsofarsowhat]

Sun....once again fucking up a good thing. Way to go Sun...keep making yourself even less relevant. /dumbasses

The Forked Up Fallacy.

[fm6]

We keep hearing this claim, always made by people who have obviously done no serious software development, open source or otherwise. It would make sense if most software projects involved one or two people. Then anybody who had access to the code base could fork it and create their own version of the project.

There was a time when a lot of software actually got made by individuals. (Interesting piece on NPR this morning about Richard Garriot. Mentioned that when he was a teenager, he wrote his first commercially successful RPG in his spare time over a couple of weeks.) But very few projects are like that any more, and MySQL certainly isn't. It's kept viable by the work of dozens of paid programmers and QA people. The contributions of customers, volunteers, and users of the free version are also essential. Any major software project is as much a community as it is a code base, and that's doubly true for open source.

Now, I'm not saying that the ability to fork has no value. It's just not as important as people seem to think. Most successful forks aren't intended to compete with the original project — and when they are, it usually means that the original project has imploded and needs a reboot with fresh leadership.

A more common reason to fork a project is to create something new. That's what Drizzle is about. It's not Aker's notion of "what MySQL ought to be." It's an attempt to address issues (concurrency, scalability) that not all DBMS users care about.

That's a positive thing, but it's still not the major reason for the Open Source. The "Power of Open Source" mostly comes from the fact that it's a good model for collaboration. If somebody has an idea for a cool new feature or thinks a certain bug really needs to be stomped on, they can just go ahead and code it. This has actually happened in projects I've been involved with (as a tech writer) several times. Once, when I was at Borland, a nasty memory leak in GNU libc was screwing up our project; our engineers coded the fix. More recently, I've been working for a server manufacturer that needed some new drivers and native Windows support for IPMItool; we paid a consultant to write the code, then donated it back to the original project.

It's worth noting that the Google search engine seems to follow much the same model, even though it's (very) closed source and only worked on by Google employees. Despite this restriction, the engine is designed so that lots of different people can code and implement new search engine feature without jumping through a lot of bureaucratic loops. That's why the search engine keeps sprouting new features with no advance notice. It's also why many of those features are very poorly documented — also an issue with most OS projects, alas.

MySQL is more than InnoDB, BDB

[toby]

Don't underestimate upcoming transactional engines, specifically Jim Starkey's Falcon (which is nearing readiness), PBXT and future versions of Maria.

Plus the mature InnoDB engine is not going away any time soon.

Change control

[DragonHawk]

I'm not going to comment on the rest, but this seems bogus:

For one, it's easier sometimes to get a change approved in an application than it is to talk someone into approving a change -- any change -- in the database schema, no matter how trivial ...

Either way, we are talking about making a change that could impact the quality of the results given. So either change control on the database side is too strict, or change control on the application side is too loose. Either way, the problem is with the change control procedures in use, not with the adoption or avoidance of database-level intelligence.

Aren't normal (non SP) queries precompiled too?

[Anonymous Coward]

Once you create a SP, to retrieve a load of data that is further manipulated by your app servers, you find your execution plans are precompiled and cached, your locks are held much less, in fact the whole thing gets well optimised by the DB engine.

I might be talking out my arse here - can any Oracle/SQL server/Sybase/Postgres/MySQL gods step in and set the record straight?

I was under the impression that most good DB's these days will actually keep a cache of previous queries in precompiled form (particularly if the query uses named parameters), and the DB will use the precompiled version if the query is reused frequently. If this is the case, then your argument for using SP's as a performance enhancement pretty much falls down.

Let me put it this way, if you write an ORM to retrieve data that you then filter to weed out the bits you don't want, you will kill your performance.

I'm not sure that you fully understand how ORM software these days works. Hibernate for instance has it's own query language so you can retrieve only the data that you need. It also has support for lazy-loading, where only the parts of the data structure that you actually use are queried/retrieved from the database.

As far as performance goes, ORM frameworks these days also support in-memory caching and other things that are made a hell of a lot harder if you start using stored procs for retrieving data.

I suggest you actually try some of these frameworks before you get up on your high horse knocking them. They've got some damn clever people working on them and for the most part they really are very good.

Re:Aren't normal (non SP) queries precompiled too?

[mattcasters]

You are indeed correct AC, compilation is not a reason to use stored procedures and queries are indeed cached in all possible ways these days.
These things are what databases do best, it's part of their explicit responsibilities.
Executing stored procedures is IMHO not.
In all fairness, there are things that Stored procedures do a good job on too.

They are great for:
* Assuring vendor lock-in
* Logic obfuscation
* Programmer job security
* ...

They are bad for:
* Execution speed
* Scalability
* Migration scenarios
* ... ;-)
Matt

typo, meant Opensolaris release

[sethstorm]

Only recently was this information even available, with the only clues being in the Solaris 9 notices, and the Opensolaris release.

I don't know

[ClosedSource]

Sun has had its share of white papers as "products".

The right size for limits

[symbolset]

Absurd limit theory: Where software imposes a limit the limit should be so large that uses outside the limit are not merely implausible, but absurd.

Here I'll use n=2^256 to represent a reasonable representation of an absurd limit, though time may spell the doom of that estimate. The universe is presumably 2e52 kg, so while this seems reasonable for now n=2^2^2^2^2^2 bits may be our ultimate answer for the addressing of normal data.

The right size for a limit on the size of data that can be stored in a field is "all of it", but n bytes should do for now. The right size for a limit on the number of tuples in a row is "all of them", but again, n should do. The right limit for the possible number of rows (or free tuples) is also "all of them" but n is a good number here. The right size for a "time" variable is enough bits to cover the number of seconds from the big bang to the heat death of the universe squared for the whole part and as many bits for the fractional part - n.n should do well here too. Since the nth particle at the n.nth moment in the n.nth frame of reference can be used to specifically identify any particle potentially extant in the metaverse indices of this size should suffice for real objects. You can add values for energy level, vector, phase and accrued entropy or other issues as required for your application. These are not infinite values, but they are fairly large. If you use smaller units than n common software will eventually need to be rewritten to use larger units. No matter what units you use, eventually some theoretical applications will require specially designed units. The idea is that where there is a limit on the number of objects measured or contained, the limit should be absurd. Likewise for the divisions of units.

We have moved from 4 bit computing to in some cases 256 bit. We may be aproaching the limit of utility in this "bitness".

In short, I agree with you that the limits in MySQL are pretty tiny. You don't use MySQL for that. You use MySQL for speed on smaller databases. For heavy work you use PostgresSQL. If you need absurd limits, well... you have access to the source code for both of them. It's not like you can't just build it. Remember to submit patches back to the tree, ok? Eventually somebody will and then everyone will have the option of units that should have been available to start with.

BTW, financial calculations will require larger bit fields for US federal computations because on the current trend line the US national debt overflows $2^n in 2016, before which time some long term debts will be due.