Open source object-oriented database db4o Journey, the 1th part of the first knowledge db4o

Objective

The industry's quest for persistent storage has never stopped, and many new technologies have sprung up in the open source and in the business world to make it easier and easier to express our minds with objects. In the past year, the industry has also been reflecting on whether ORM brings us convenience or trouble. Pointing to the famous Hibernate, have talked about its performance problems, we seem to reach such a consensus: "In the business logic complex place with SP, and general CRUD or Hibernate", even the world-renowned BearingPoint also have similar views. The following is a simple example that illustrates the drawbacks of traditional ORM tools. Let's consider a simple Student object like Listing 1:

Listing 1. Student class

public　class　Student　{
　 private　String　name;
　 private　int　age;
　 public　String　getName(){
　 return　name;
　 }
　 public　int　getAge(){
　 return　age;
　 }
}

Consider the following scenario: Find "all students younger than 20 years of age"?

Use the ORL implementation as shown in Listing 2:

Listing 2. ORL implementation

String　oql　=　"select　*　from　student　in　AllStudents　 where　student.age　<20";
OQLQuery　query　=　new　OQLQuery(oql);
Object　students　=　query.execute();

Use the JDOQL implementation as shown in Listing 3:

Listing 3. JDOQL implementation

Query　query　=　persistenceManager.newQuery(Student.class,　 "age　<20");
Collection　students　=　(Collection)query.execute();

There are some common problems with the above methods:

The modern integrated development environment does not check for semantic and grammatical errors in embedded strings. In all of the above query statements, the age field and the value 20 are considered numeric types, but none of the Ides or compilers can check their actual correctness. If the developer confuses the query code-―, for example, changing the name or type of the age field, it will cause-all of the query statements above are wrong in the run-time, without prompting at compile time.

Modern Agile development technology encourages continuous refactoring to maintain a clear and up-to-date class model to reproduce the evolving domain model accurately. If the query code is difficult to maintain, it delays the time it will take to determine the refactoring and inevitably introduces low quality code.

All of the queries listed are directly used by the private member of the Student class, rather than using its public interface Student.getage (), so they all break the object-oriented encapsulation rules, violate the interface and implement the object-oriented rules that should be separated.

All queries are not native to 100%.

Since there are so many problems, why not use a pure object-oriented database directly? Some developers may say: "It lacks mathematical model support and is not mature enough." Indeed, the RDBMS developed for decades to achieve today's achievements, has been very perfect. And the technological innovation is endless, the complacent will never keep pace with the change.

Let's take a brief look at the history of the object database (data from the Wiki Encyclopedia): The term object-oriented database system first appeared in 1985. Notable research projects include: Encore-ob/server (Brown University), Exodus (Wisconsin University), IRIS (HP), ODE (Bell Laboratory), ORION (MCC), Vodak (GMD-IPSI) and Ze Itgeist (Texas instruments). The largest number of papers were published in the ORION project. MCC's Won Kim compiles the most valuable part of these papers in a book and is published by MIT Press. The object database management system adds a lasting concept to the Object-oriented programming language. The first commercialized Odbms appeared in 1986, and was launched by Servio (now gemstone Company) and Ontos Corporation. Later (90), the Object Design (ODI), versant, objectivity, O2 Technology, poet, Ibex, Unisql and ADB MATISSE and other companies joined the pioneering ranks.

And today, a source-oriented database company db4objects from Silicon Valley, Calif., has brought us db4o, a purely object-oriented database of excellent performance, and the protagonist we will introduce in this and subsequent articles.

Db4o for us is an object-oriented approach to querying:

The native query language of 100% should be fully expressed in the implementation language (Java or C #) and fully follow the semantics of the implementation language.

The 100% object-oriented query language should be run in its own implementation language, allowing the normal collection to be performed without optimizations without customizing preprocessing.

The 100% type-safe query language should fully capture the characteristics of modern Ides, such as syntax detection, type detection, refactoring, and so on.