Let's see if this is the case when it's available, because complete compatibility is very very hard to implement. Also, let's see what's the performance. Also interesting to see how Solid is integrated into MySQL (will the MySQL engine create SQL statements for Solid?).
It is a good idea from MySQL to get another storage engine, but I don't think this is the final solution. My guess is MySQL currently works on theirs own (transactional) storage engine, maybe based on Firebird.
The whole InnoDB/Sleepycat/Solid story probably scared some customers. On the other hand, it made MySQL more visible to those who never thought about using it.
I don't view MySQL as a 'true open source' database, when it's not free for commercial use. But MySQL is the reason why many big companies are currently thinking about making the application database independent, and that's good. No, just using SQL (the language) does not make your app database independent. 'SQL, isn't a standard but a theme' (this is from a Jim Starkey interview).
No, I think less important. For some reasons, many people believed app server are very important and therefore used them if they could. Including EJBs for persistence. But there was a wave of 'simplification' lately (POJO, Ruby on Rails) and now the trend seems to be: use app server only for the things they are designed for. In my view, most apps can be developed just with Tomcat (or Jetty) and Hibernate (or another persistence library) and a database.
I think the same trend happens with XML: first, everybody used XML for everything (including configuration of EJBs, XML databases), and now the trend is more in the direction of annotations for configuration, and storing XML inside SQL databases.
Oracle whould just have tried to convert JBoss customers to Oracle. Red Hat will probably let JBoss do what they want, and that's good (not that Linux would be bad).
The most imporant asset of JBoss is probably Hibernate, and I think Red Hat knows that even better than Marc Fleury. Java/Tomcat/Stuts(JSF)/Hibernate is a good and proven plattform, and is here to stay. I think app servers will play a less important role in the next years.
English is not the main language of Switzerland. A few languages spoken in Switzerland are:
- Italian, in the south - French, at least in Lausanne - Rhaeto-Romanic (Rätoromanisch), in the mountains;-) - Swiss German (the most important language) - German (related to Swiss German, but not the same) - English (many, if not most, learn it)
Guess what language this is: "mi dünkt, Amerikanär si mängisch scho chli überhäblech"
This article made me angry. For me (I'm Swiss), it shows that most Americans - are arrogant - ignore minorities - don't know they are a minority themselves - are selfish in a way that hurts themselves and they don't know it - forgot the history of America - think America is Paradise - would probably elect Bush again - are therefore really, really stupid
I don't even want to go on details, because I guess a Real American woudn't even care to discuss and try to understand why this is so. This arrogance is the reason why America loses power and respect in the rest of the world.
Security: no viruses (because no client installation).
Data would be clustered on the server side, so less data loss problems.
Fast startup (just open the browser).
About the disadvantages:
Security issues: Similar to e-mail security problems, I don't think its a problem for most users.
Slow speed: Internet connections are fast nowadays. Application speed is probably ok.
Remember you don't need to download the whole document always, just one page at a time (Ajax).
Dependence on Internet connections: You have this dependence with e-mail anyway.
Probably ok for most users. But I agree, this is the hardest problem. Could be solved (see below).
Limited features: As long as the app has enough features it's ok for the masses.
See GMail: it's enough functionality for the masses.
Harder to program: Yes, but this never was a problem.
Rembember the Win 3.1 programming API? First only C++?
Still every bigger company started writing Windows applications.
Not all such applications need to run on a distant server. They could very well be installed on the company server, or even on the desktop (like Google Desktop search works today). If installed on the desktop, not all (convinience) functionality is required, because desktop use would be a 'fallback' solution. You do need document standards. The 'small' installation could be slower as well. If you make it a 3 tier application (Browser / Middleware / Database) you wouldn't need a clustered database; an embedded Java database (plug: http:www.h2database.com/ would be enough. The middleware would be probably Java (but not the full blown J2EE stack).
I hereby claim ownership of the name NewSQL (http://newsql.sf.net/) and demand that you pay me a license fee to use this name a subject in your posts;-) Just joking.
Otherwise I agree. Maybe the next MySQL kernel should be written in Java? Before people are shouting 'too slow' they should have a look at the performance numbers: http://polepos.sf.net/.
At least I think that Java is fast enough for a database engine, otherwise I wouldn't write my 3 engine in Java (1th was Hypersonic SQL, 2nd PointBase Micro, and 3th H2 (http://www.h2database.com/).
I don't think Oracle wants to play in the Open Source field as the article suggests.
They will probably try to kill/hurt the competitors
and get as much customers from them as possible.
Maybe Oracle will offer a free version of the software (InnoDB / BerkelyDB / PHP / JBoss), but I don't think they will do it like Sun with OpenOffice. Or IBM with Eclipse / Linux. Oracle doesn't need to do it, because they have the market share already (unlike Sun and IBM). Oracle just wants to keep the market share, and keep MySQL small.
Oracle tried to buy MySQL, and because they can't (probably MySQL just wants too much money),
they try to hurt them as much as they can. Oracle must be really scared of MySQL.
When they buy Zend, they will probably try to charge for it, and LAMP will become LAM.
Oracle bought Innobase just to hurt MySQL. I think Oracle will try to make as much money
from InnoDB as they can (converting customers to Oracle) and then try to kill InnoDB.
Probably MySQL tired to buy Innobase, but Oracle just offered more money.
Then they bought Sleepycat to hurt
MySQL, and to use the technology
and get more customers (the main customers of BerkleyDB are not from MySQL).
So Sleepycat will probably survive, but the Oracle will
poison it so MySQL can't use it.
MaxDB now assumes a much more important role, and MySQL should be working on integrating it as quickly as possible
I don't agree.
MaxDB is a different database engine, including parser and so on.
Probably it's a huge, ugly, complicated mountain of source code.
Integrating such a thing is hard, really hard.
If it's done in a hurry it means hacking and patching.
This will lead to bugs, stability problems, slow performance.
And if that happens, people will loose faith in MySQL.
It could in fact mean the end of MySQL if they do that and if fails.
Better would be actually: grab a few database kernel developers (Jim Starkey for example),
and write a new kernel. Probably even better (if MySQL has enough money):
build 3 teams, one doing MaxDB refactoring, and two writing a new kernel.
Then after some time integrate the best one, and throw away the rest.
I heard Oracle did such 'competitive development' in the past.
Oracle Express: this is not a response to MySQL, it's a response to SQL Server Express Edition.
About other databases: I think PostgreSQL has the best position as an open source db, but
don't really feel that Firebird is anywhere close. Firebird lacks a lot of features,
and development is slow. Well let's see.
Thomas Mueller, author of Hypersonic SQL, PointBase Micro,
and (lately) the H2 Database Eninge (http://www.h2database.com/).
MaxDB is a different product, not (yet) a 'storage engine' of the regular MySQL 5.0. It's a different codeline, and I'm not sure if its fast. Maybe it can be integrated with the core MySQL database, but currently, it's not. And just the fact it 'belongs' to MySQL doesn't make it a good candidate for integrating, technically. Well, maybe from a manager perspective it does:-) Well, let's see what happens next.
Thomas
I don't agree MySQL does not depend on Berkeley DB. Without it, and without InnoDB, MySQL needs an alternative. In any case it's bad for MySQL, because some customers are probably already scared.
I think what Oracle will do is change the work priorities inside Sleepycat. Development and support related to MySQL will be stopped completely. Developers will be re-assigned to do things like 'compatibility', 'migration' and so on. Future version of Sleepycat will just not work with MySQL any more. Probably the license agreement will change. Not sure if the code will be forked, but if the main developers of the codebase are gone (no longer working on it), the code becomes a legacy.
Something very similar happened to me in 2001. I am the original author of Hypersonic SQL (a Java database engine). PointBase, who also developed a Java SQL database, asked me if I want to work for them, I said yes. We agreed I will continue to work on Hypersonic SQL. But this suddenly changed about half a year later, and they made me to work on something else (PointBase Micro, PointBase UniSync). So they 'bought' me (well, I only got shares, which are now worthless). And then tried to kill the competitor. They told me to stop the Hypersonic SQL project. But it was forked (HSQLDB). I left PointBase in 2003, and now I'm working on a new Java database: H2 (http://www.h2database.com/).
MySQL will probably start developing their own transactional backend. They have now enough money to do that. They should do that, probably they already started (I was asked to work for them, but obviously I said no because of H2). My guess is MySQL will start a branch in the Bay Area, and hire some good developers there. There are quite a lot good database developers in this region.
Slashdot Mirror
Let's see if this is the case when it's available, because complete compatibility is very very hard to implement. Also, let's see what's the performance. Also interesting to see how Solid is integrated into MySQL (will the MySQL engine create SQL statements for Solid?).
It is a good idea from MySQL to get another storage engine, but I don't think this is the final solution. My guess is MySQL currently works on theirs own (transactional) storage engine, maybe based on Firebird.
The whole InnoDB/Sleepycat/Solid story probably scared some customers. On the other hand, it made MySQL more visible to those who never thought about using it.
I don't view MySQL as a 'true open source' database, when it's not free for commercial use. But MySQL is the reason why many big companies are currently thinking about making the application database independent, and that's good. No, just using SQL (the language) does not make your app database independent. 'SQL, isn't a standard but a theme' (this is from a Jim Starkey interview).
--
http://www.h2database.com/
No, I think less important. For some reasons, many people believed app server are very important and therefore used them if they could. Including EJBs for persistence. But there was a wave of 'simplification' lately (POJO, Ruby on Rails) and now the trend seems to be: use app server only for the things they are designed for. In my view, most apps can be developed just with Tomcat (or Jetty) and Hibernate (or another persistence library) and a database.
I think the same trend happens with XML: first, everybody used XML for everything (including configuration of EJBs, XML databases), and now the trend is more in the direction of annotations for configuration, and storing XML inside SQL databases.
---
http://www.h2database.com/
Oracle whould just have tried to convert JBoss customers to Oracle. Red Hat will probably let JBoss do what they want, and that's good (not that Linux would be bad).
The most imporant asset of JBoss is probably Hibernate, and I think Red Hat knows that even better than Marc Fleury. Java/Tomcat/Stuts(JSF)/Hibernate is a good and proven plattform, and is here to stay. I think app servers will play a less important role in the next years.
---
http://www.h2database.com/
Oh, I'm sorry. This joke was too smart for me ;-)
Let me try to make a joke as well:
Maybe it was not a typo.
They just forgot say beowulf cluster.
Ok, was probably a dumb comment as well.
I feel bad now.
----
http://www.h2database.com/
English is not the main language of Switzerland.
;-)
A few languages spoken in Switzerland are:
- Italian, in the south
- French, at least in Lausanne
- Rhaeto-Romanic (Rätoromanisch), in the mountains
- Swiss German (the most important language)
- German (related to Swiss German, but not the same)
- English (many, if not most, learn it)
Guess what language this is:
"mi dünkt, Amerikanär si mängisch scho chli überhäblech"
http://www.h2database.com/
This article made me angry. For me (I'm Swiss), it shows that most Americans
- are arrogant
- ignore minorities
- don't know they are a minority themselves
- are selfish in a way that hurts themselves and they don't know it
- forgot the history of America
- think America is Paradise
- would probably elect Bush again
- are therefore really, really stupid
I don't even want to go on details, because I guess a Real American
woudn't even care to discuss and try to understand why this is so.
This arrogance is the reason why America loses power and respect
in the rest of the world.
- No client installation required.
- Security: no viruses (because no client installation).
Data would be clustered on the server side, so less data loss problems.
- Fast startup (just open the browser).
About the disadvantages:- Security issues: Similar to e-mail security problems, I don't think its a problem for most users.
- Slow speed: Internet connections are fast nowadays. Application speed is probably ok.
Remember you don't need to download the whole document always, just one page at a time (Ajax).
- Dependence on Internet connections: You have this dependence with e-mail anyway.
Probably ok for most users. But I agree, this is the hardest problem. Could be solved (see below).
- Limited features: As long as the app has enough features it's ok for the masses.
See GMail: it's enough functionality for the masses.
- Harder to program: Yes, but this never was a problem.
Rembember the Win 3.1 programming API? First only C++?
Still every bigger company started writing Windows applications.
Not all such applications need to run on a distant server. They could very well be installed on the company server, or even on the desktop (like Google Desktop search works today). If installed on the desktop, not all (convinience) functionality is required, because desktop use would be a 'fallback' solution. You do need document standards. The 'small' installation could be slower as well. If you make it a 3 tier application (Browser / Middleware / Database) you wouldn't need a clustered database; an embedded Java database (plug: http:www.h2database.com/ would be enough. The middleware would be probably Java (but not the full blown J2EE stack).Otherwise I agree. Maybe the next MySQL kernel should be written in Java? Before people are shouting 'too slow' they should have a look at the performance numbers: http://polepos.sf.net/.
At least I think that Java is fast enough for a database engine, otherwise I wouldn't write my 3 engine in Java (1th was Hypersonic SQL, 2nd PointBase Micro, and 3th H2 (http://www.h2database.com/).
Thomas
Oracle tried to buy MySQL, and because they can't (probably MySQL just wants too much money), they try to hurt them as much as they can. Oracle must be really scared of MySQL. When they buy Zend, they will probably try to charge for it, and LAMP will become LAM.
Oracle bought Innobase just to hurt MySQL. I think Oracle will try to make as much money from InnoDB as they can (converting customers to Oracle) and then try to kill InnoDB. Probably MySQL tired to buy Innobase, but Oracle just offered more money.
Then they bought Sleepycat to hurt MySQL, and to use the technology and get more customers (the main customers of BerkleyDB are not from MySQL). So Sleepycat will probably survive, but the Oracle will poison it so MySQL can't use it. MaxDB now assumes a much more important role, and MySQL should be working on integrating it as quickly as possible I don't agree. MaxDB is a different database engine, including parser and so on. Probably it's a huge, ugly, complicated mountain of source code. Integrating such a thing is hard, really hard. If it's done in a hurry it means hacking and patching. This will lead to bugs, stability problems, slow performance. And if that happens, people will loose faith in MySQL. It could in fact mean the end of MySQL if they do that and if fails.
Better would be actually: grab a few database kernel developers (Jim Starkey for example), and write a new kernel. Probably even better (if MySQL has enough money): build 3 teams, one doing MaxDB refactoring, and two writing a new kernel. Then after some time integrate the best one, and throw away the rest. I heard Oracle did such 'competitive development' in the past.
Oracle Express: this is not a response to MySQL, it's a response to SQL Server Express Edition.
About other databases: I think PostgreSQL has the best position as an open source db, but don't really feel that Firebird is anywhere close. Firebird lacks a lot of features, and development is slow. Well let's see.
Thomas Mueller, author of Hypersonic SQL, PointBase Micro, and (lately) the H2 Database Eninge (http://www.h2database.com/).
MaxDB is a different product, not (yet) a 'storage engine' of the regular MySQL 5.0. It's a different codeline, and I'm not sure if its fast. Maybe it can be integrated with the core MySQL database, but currently, it's not. And just the fact it 'belongs' to MySQL doesn't make it a good candidate for integrating, technically. Well, maybe from a manager perspective it does :-) Well, let's see what happens next.
Thomas
I don't agree MySQL does not depend on Berkeley DB. Without it, and without InnoDB, MySQL needs an alternative. In any case it's bad for MySQL, because some customers are probably already scared.
I think what Oracle will do is change the work priorities inside Sleepycat. Development and support related to MySQL will be stopped completely. Developers will be re-assigned to do things like 'compatibility', 'migration' and so on. Future version of Sleepycat will just not work with MySQL any more. Probably the license agreement will change. Not sure if the code will be forked, but if the main developers of the codebase are gone (no longer working on it), the code becomes a legacy.
Something very similar happened to me in 2001. I am the original author of Hypersonic SQL (a Java database engine). PointBase, who also developed a Java SQL database, asked me if I want to work for them, I said yes. We agreed I will continue to work on Hypersonic SQL. But this suddenly changed about half a year later, and they made me to work on something else (PointBase Micro, PointBase UniSync). So they 'bought' me (well, I only got shares, which are now worthless). And then tried to kill the competitor. They told me to stop the Hypersonic SQL project. But it was forked (HSQLDB). I left PointBase in 2003, and now I'm working on a new Java database: H2 (http://www.h2database.com/).
MySQL will probably start developing their own transactional backend. They have now enough money to do that. They should do that, probably they already started (I was asked to work for them, but obviously I said no because of H2). My guess is MySQL will start a branch in the Bay Area, and hire some good developers there. There are quite a lot good database developers in this region.
Thomas Mueller, former author of Hypersonic SQL