Slashdot Mirror

This is a step up from a cardboard box and it's still dirt cheap:
http://h2database.com/raspi/

PostgreSQL is still a *huge* player (in fact, they're pretty-much the only open-source, fully-transactional DB available).

I love PostgreSQL, but I have to acknowledge:

Firebird
H2
Ingres (ancestor of Postgres)
SQLite

None of these are Oracle-killers, but they are all robust, open-source SQL RDBMSs in their own right.

I only use it for stupid things that do not matter at home, like my MythTV, never ever on anything that could be called "production."

I wish applications like that would stop using MySQL (and server-based databases in general), but I don't think there's a good alternative that isn't written in Java that supports multiple simultaneous connections. I like the approach used by the Java embedded H2 database engine with its automatic server mode - you can open the database like a file, but the first client to connect to the database will start up an embedded server and create a lock file that instructs any other clients to connect to the server running on the first client. If the first client closes the database while there are other clients connected, one of the others will take over.

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

Using stored procedures doesn't automatically protect you. For example, this is still insecure:

stat.executeQuery( "CALL GET_USER('"+name+"', '"+password+"')");

Using parameterized queries / prepared statements / bind variables works. But that means code reviews.

There are solutions that don't require code reviews at all, for example enforcing the use of bind variables. Even better is to use LINQ or the Java variant of it, JaQu. Disclaimer: I am the developer of the open source database H2.

Using stored procedures doesn't automatically protect you. For example, this is still insecure:

stat.executeQuery( "CALL GET_USER('"+name+"', '"+password+"')");

Using parameterized queries / prepared statements / bind variables works. But that means code reviews.

There are solutions that don't require code reviews at all, for example enforcing the use of bind variables. Even better is to use LINQ or the Java variant of it, JaQu. Disclaimer: I am the developer of the open source database H2.

http://www.h2database.com/ is open source and it is faster than MySql and Postgress. And it is fully relational and transaction based from day zero.

Besides it is written in Java, so it is fully portable without requiring to recompile and the source code is lean and mean, much simpler than other databases.

Have a chip on your shoulder much? Most of what you're saying is simply incorrect. e.g. Java does not have half-a-dozen containers. Yes, the switch from the STL-inspired Vector to the more Java-ish ArrayList was annoying. Same with HashTable to HashMap. But beyond that, all those different containers you think you see are actually interfaces for wiring up complex functionality. Either that or completely different data structures with different performance characteristics. (Remember your CompSci courses?) The Java Collections package (which seems to be the only thing in Java you're remotely familiar with) provides enough functionality to write a complete database engine. Which, as a matter of fact, has been done quite a few times. (Sorry, ran out of words to link. Doh! Still more. Ah, to hell with it.)

The rest of the Java API is also not bloat. There are libraries for printing, crytography, sound, graphics, DOM, file I/O, text parsing, text formatting, text display, mathematics, directory interfaces (e.g. LDAP), distributed object systems, reflection, security, SQL database interface, logging, cross-platform preferences, regular expressions, ZIP/GZip support, accessibility, networking, the compiler, scripting engines, etc., etc., etc. Very little of the core API is redundant, with most of the (few!) redundancies being a result of the early days of Java before they moved away from the C++ style objects.

Nearly all of the post-1.0 APIs were done correctly the first time. Which means that the core Java API is actually quite slim for the amount of functionality it provides. And even then, there is a HUGE number of official expansion APIs for mail, multimedia codecs, network request/response handlers (e.g. servlets), 3D graphics, 3D sound, text-to-speech, speech recognition, telephony, SOAP, REST, USB, Bluetooth, scientific units, cross-platform desktop integration, Instant Messaging, P2P, and quite a bit more. And that's just the official JSR-approved expansions! The OSS and (bleh) commercial worlds are full of unofficial libraries to deal with nearly any problem you can come up with.

If you want bloat, stop looking at Java. Try compiling a few Linux apps sometime and tell me how many redundant libraries you come across. If you know what they all do (which is a miracle in of itself), compiling just ONE of those programs is enough to make a person blush with embarrassment. Not to mention that when a platform IS solidified (e.g. GNOME), it suffers from versionitis. (i.e. The constant need to upgrade your version of the libraries because this latest program no longer targets the version you just compiled. Or even worse, it requires a specific minor release, thus requiring you to have multiple minor releases of the library compiled and installed.) I won't even go into Microsoft's practice of inventing a new API for the same technology over, and over, and over again. (ODBC, DAO, ADO, JET, anyone?)

Now I happen to think that a lot of the choice that Linux offers is good. But don't point fingers at other platforms when there are more than enough examples of far worse situations close to home.

You never _had_ durability. On most system. See http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252. Durability is hard - mainly because of hard drives. See also http://www.h2database.com/html/advanced.html#durability_problems (I wrote that). It's not about 'losing data randomly', it's about losing transactions. The risk is: if there is a power failure or the process is killed, you may lose the transactions of the last x milliseconds. In most cases, you wouldn't know if the commit call returned before the failure, and for for those cases where it's important (distributed transactions), you anyway need the 2-phase-commit protocol. And again, this is not about corruption or losing records randomly, it's a about transactions.

I have included it in the build script: Whenever you write more than a few lines of new code (or documentation) the spell checker will bark because it doesn't know the word. Maybe I should add an automated 'word list expander' that checks unknown words on the internet... Anyway, the hard part will be to convince your coworkers to use it.

Like pointer arithmetic / manual memory management: Good developers are safe. Fact is: if you allow it, developers will make mistakes: Buffer overflow. Boom! Java doesn't allow pointer arithmetic / manual memory management. Java is safe.

SQL injection is similar: Once you allow embedding user input in SQL statements, some developers will make mistakes. SQL injection. Boom! How to solve it? Don't allow embedding user input. Enforce the use of parameters. Then you are safe. The Java database H2 database engine supports a feature to enforce using parameters.

There is a way to solve SQL injection problems: Disallow text literals in the database engine. Or even, disallow literals (including numbers) at all. This could be a setting in the database that is on by default, and only off for certain applications (ad hoc query tools). What do you think about that?

I'm thinking about implementing this feature in the database I write (http://www.h2database.com/):

SET ALLOW_LITERALS 0 (no literals allowed)
SET ALLOW_LITERALS 1 (only numbers, text not)
SET ALLOW_LITERALS 2 (everything allowed)

(Of course there are other security risks, like using 'customer id' in URL or hidden fields in a web application. Or relying on Javascript data validation. I don't know what to do about those problems.)

execute("SELECT ... WHERE NAME='"+name+"' ...

There is a way to solve SQL injection problems: Disallow text literals. Or even, disallow literals (including numbers) at all. This could be a setting in the database that is on by default, and only off for certain applications (ad hoc query tools) or users (admins). What do you think about that?

I'm thinking about implementing this feature in the database I write (http://www.h2database.com/):

SET ALLOW_LITERALS 0 (no literals allowed)
SET ALLOW_LITERALS 1 (only numbers, text not)
SET ALLOW_LITERALS 2 (everything allowed)

(Of course there are other security risks, like using 'customer id' in URL or hidden fields in a web application. Or relying on Javascript data validation. But I don't know what to do about those problems.)

SQL variations ... While SQL is a standard, there seems to be some very relaxed definitions of full adherence to that standard...

Or, as Jim Starkey said: 'SQL isn't a standard but a theme'. For a book, it means list 5 different dialects. For regular developers (not database specialists) it means knowing only one dialect really well. For an application it means, running only with one database (mostly). It would be really cool the industry could get together and define a 'real' standard. Could be a subset of SQL (http://ldbc.sf.net/) or a new language (http://newsql.sf.net/). Things would get simpler then.

(Side note: LDBC and NewSQL are both projects I started, but interest was quite low; currently I'm working on a new database engine http://www.h2database.com/ where I try to be compatible as much as possible with existing databases)

Or is there some other solution? I don't think that that O/R mapping tools will solve the problem completely, as there is always the need interactive database queries. Maybe the Microsoft extension to C# (forgot the name) could be a solution? Other ideas?

It's not so clear if MySQL is 'free for commercial use' or not:

"The Commercial License ... for organizations that do not want to release their application source code."
http://www.mysql.com/company/legal/licensing/comme rcial-license.html

"Free use for those who never copy, modify or distribute. As long as you never distribute the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not."
http://www.mysql.com/company/legal/licensing/opens ource-license.html

So if you ship your (commercial) application with (the unmodified) MySQL, you need to use the commercial license. I don't think this is so with Linux, because the important libraries (LIBC) are LGPL and not GPL. Also, each part of the system can have a different license in Linux. Not so if you use MySQL (see above). At least this is my understanding, please tell me (with the relevant links) if you think I'm wrong.
--
http://www.h2database.com/

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/

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/).

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

Something very similar happened to me in 2001. I am the developer of Hypersonic SQL (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. So they 'bought' (well, I only got shares, which are now worthless) me, and then tried to kill the competitor. They made me stop the Hyperonic 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/).

I think what Oracle will do is slowly re-assign the developers to do something else ('compatibility', 'migration' and so on). In about one year the projects will be basically dead. 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, and in most cases development is slowed down a lot.

MySQL will probably start developing their own transactional backend. They have now enough money to do that. My guess is they will start a branch in California, and hire some ex-Sleepycat developers.

Thomas, author of Hypersonic SQL

• Is the DBMS trusted? Is it well known?
• Do the developers have work experience with the product?
• Are good tools available?
• Performance? Stability?
• Is it scalable (clustering) in case it's needed?

Databases that fit in this description since a long time are: Oracle, MS SQL Server, DB2. New on the list are: MySQL, PostgreSQL. Wikipedia link: List of RDBMS

And maybe some will be added to the list in the future, like Firefird, and who knows H2.