Slashdot Mirror
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?"
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.
----- "Profanity is the one language that all programmers understand."
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.
~ Ron Fitzgerald
How long until Netcraft confirms that Sun is dieing?
Anybody want my mod points?
David Axmark Resigns From Sun
So, he gets the ax because somebody missed the mark.
The higher the technology, the sharper that two-edged sword.
ooh, 900MB. Positively ginormous, that.
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!
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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 ...
___
No power in the 'verse can stop me
to one as large as 900MB
Is that what powers your HTML applications?
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?
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.
Cool! Amazing Toys.
For shizzle!
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.
F0 07 C7 C8
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.
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.
You are in a maze of twisty little passages, all alike.
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.
You are in a maze of twisty little passages, all alike.
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.
IranAir Flight 655 never forget!
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."
David, don't quit in this market.
Unemployment is rampant and you'll likely be lowballed for your new job.
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.
Does that mean your server now runs a LAPP stack? (someone please insert a Hooters joke)
Every mans' island needs an ocean; choose your ocean carefully.
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. :)
-rd
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)
MySQL sucks
And your post, like my response, is pointless.
Oh, for the days when sig's didn't have to be cute...hey, wait a sec.
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.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
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.
"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).
It's not a microdatabase unless it's stored in microbits. Anything that takes up a whole bit or more is way too big.
I don't believe in time. It's a grand conspiracy designed to sell watches.
Sun does not own the Oracle database - Oracle owns the Oracle database. Wow.
- T
"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.
501 Not Implemented
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 :) )
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.
No SIG for you!
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
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.
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.
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.
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..)
" one huge multigigabyte innodb table"
Agh I meant file. And you can't shrink that file easily even if lots of it is unused.
...
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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.
Please correct me if I got my facts wrong.
So that's like 1 bit for metadata, 1 bit for indices, and the other 3 is raw data?
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.
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.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
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.
Wait, since when does SAP DB have strengths?
sic transit gloria mundi
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.
sic transit gloria mundi
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.
I am TheRaven on Soylent News
Faster, more scalable, richer, more stable, more standards-conformant, more free.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
And you are telling me this why?
as I clearly state in my replies, there is no FOSS solution that handle this.
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.
Read radical news here
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.
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.
-1 Uncomfortable Truth
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.
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.
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...
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.
(1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
Pax Vobiscum
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
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
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.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
Sun....once again fucking up a good thing. Way to go Sun...keep making yourself even less relevant. /dumbasses
. I love the sound of burning women and screaming rubber....
Pointless but indicative of the general nature of the whole discussion. Anybody seen Godot?
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.
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.
you had me at #!
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!
Similes are like metaphors
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
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.
Never attribute to Hanlon that which can be adequately attributed to Heinlein.
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.
Yet another "Java is slow" bashing. Sigh.
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
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.
You are in a maze of twisty little passages, all alike.
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.
+++OK ATH
Oh. You want Informix.
+++OK ATH
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.
-Stu
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.
Screw that. I have a 200 Petabyte databased maintained using only ed and only queried with fgrep.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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?
"First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
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.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Only recently was this information even available, with the only clues being in the Solaris 9 notices, and the Opensolaris release.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
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
News about the Kettle Open Source project: on my blog
Sun has had its share of white papers as "products".
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.
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.
You are in a maze of twisty little passages, all alike.
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.
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.
Help stamp out iliturcy.