Sometimes we make things more difficult for ourselves than they really need to be. Programmers

are no exception to this. For example, those of us of an object-oriented persuasion devote time

and expertise to creating a model of a problem domain in terms of objects. We produce solutions

that model real-world objects and that are highly extensible and reusable. And then we decide

that we need those objects to stick around after the program stops, so we go ahead and create

another, totally different model, just so that we can use a database. Our carefully designed

objects are then chopped and squeezed to fit this new data model.

In fact, most developers would argue that object persistence is a fundamental problem

that has yet to be adequately solved. While there are frameworks that hide some of the details

of the mismatch between object and data models from the programmer, none of them convincingly

make what should be a simple job really simple. We held the same opinion, until we found

out about db4o. db4o—the database for objects—simply stores native objects. “Native” means

that these are the objects that your C# or Java program creates, stored exactly as they are. There’s

no need to create a database schema, no need to map objects to tables, no need to do anything

really, except store objects. Problem solved!