Summary
The key premise of Dave Warner's recent IBM developerWorks article is that databases are more than just information stores, and should be used for a broad array of information-management tasks as well. He introduces a client-side example of using the embedded Apache Derby database to develop a rule-based system.
Advertisement
Databases are often thought of as data storage components, but they really are more: Most database systems are, in fact, data management systems (DBMS), according to Dave Warner's recent IBM developerWorks article, Real-world Apache Derby: Who needs Ajax, anyway? [IBM developerWorks registration required*]. A key point of Warner's article is to encourage developers to think of using databases for all aspects of data management, not just for storage, and on both the client and on the server.
For example, with embedded databases, such as Apache Derby, a rule-based system can be developed by delivering complex rules to the client in the form of an applet. As a result, the rules can be evaluated entirely in the client's address space, alleviating the need for frequent trips between client and server.
An alternative implementation of this system would likely result in a complex client-server API, but with Warner's approach, the entire rule base can be evaluated by using database queries and stored procedures on the client.
To what extent do you use databases for tasks beyond data storage?
* Note: Although we pointed to this item solely because we thought our audience would find it useful, Artima is currently running a program for IBM to drive registrations at DeveloperWorks.
I don't see the benefits of the tiny database over, say, a data structure and capable programming language. So you can do set operations? Your collection classes and language should be able to do the same kinds of set operations anyhow.
I have a library for Java that I wrote that allows me to match any java object against a predicate. It is similar to the NSPredicate stuff in Cocoa. With some collection helpers, I can write pretty much the same kinds of queries on arbitrary data structures as you can over tables.
So, the tiny db idea sounds to me like a crutch to work around a lack of expressability in the programming language.
> A key point of Warner's article > is to encourage developers to think of using databases for > all aspects of data management, not just for storage, and > on both the client and on the server.
The question is whether it's actually a good idea or just something IBM wants to push because of some internal agenda.
I can imagine that using a local database as a local cache might be helpful in some specific scenarios (like grid computing) but as a general solution, I don't see why this would be preferable to creating Objects to represent the rules and serializing them (using Java serialization or any other serialization). It should be pretty much the same amount of data (if not less) and simplifies the client. If there's a lot of data, you might be better off going the other way and doing the computation on the server.
Previous Topic
