db4o vs sql, sqlite in java server

Question

Im creating a java web server for storing JSON strings with location data (latitude, longitude and time) I wondering if there are any advantages(performance, scalability, maintenance, etc) for using db4o which seems easier to use in java instead of sql, sqlite. Also what are the differences between Hibernate and db4o;

Answer 1

DB4O works entirely differently than a traditional SQL-based RDBMS.

You need to define your requirements better. For instance, DB4O can follow graphs relatively easily -- a specific structure representing the JSON may fit very well in that domain. On the other hand, DB4O absolutely sucks for queries (especially reporting and aggregating) that don't fit into the previously defined graph.

Edit: The above is of my experience with DB4O (I use DB40 in conjunction with a SQL RDMBs) -- I do (and would) still use DB4O because I think it has lots of merits. However, I feel it's much more suited to specific applications which must be well-defined (claw hammer) while a traditional SQL RDMBs (sledgehammer) has a much broader scope and can cope relatively well with even poor or flat schemas and, barring performance considerations, is amendable to "slicing and dicing". Both are tools with overlapping but different purposes -- one can hammer in a nail with a sledgehammer (it might not be pretty) but good look trying to knock down down a cement wall with a claw hammer.

Answer 2

The "o" in "db4o" stands for "objects". It's an object database, so if you're problem isn't "true" object-oriented this may not be for you. Object databases work very well indeed for problems with deep object graphs, long reference chains (e.g., CAD or finite element geometric data).

Read their reference guide.

As far as storing JSON strings that you describe goes, I think any persistence technology will do. Be sure you know what you're doing when you give up SQL. I'm not arguing that SQL and relational databases are the only answer. I'd just caution you against assuming that you'll have problems with performance, scalability, -ilities in general, before you have some data to prove it.

Answer 3

If you are able to map your JSON strings to well-known object types (a class defined server-side with the same fields, and translate/map from JSON to those well-known types when a request is recieved) then db4o will work great for you. But so will a number of other solutions. There are also a number of NoSQL databases with specialized support for JSON objects and queries. (like Mongo DB or Couch DB) but (as duffymo stated already) when you choose a NoSQL database, you usually have to give up something else....like transactionality, composability (ability to query columns 1 and 3 and join on another random table), or other features that most people have come to assume from an database. (like Hibernate) db4o is like many others in this regard, db4o deals only with well-known object types and graphs. It doesn't let you get your objects out in any other shape but that they were in when inserted. But db4o does let you query any field on any object. (some NoSQL databases require you to predefine what/which fields are queryable values)