I've used it and even went through the struggle of getting it to work correctly in a concurrent-user servlet environment.
I've got to say...it was *very* appealing at first and I *really* wanted to like it...but in the end I found enough frustration and limitations w/ the technology (compared to RDBMS+ORM) that I dumped all efforts of building software w/ it.
The idea is great...but trading db4o for Hibernate (for example) is just ditching some problems for a whole new set of equally frustrating problems.
IMO, it's just not mature enough yet and has not got the market power that RDBMS technology has and will continue to have for the forseeable future. I see very little support for the technology and after my experience, I can understand why. I was quite relieved to get back to Hibernate + RDBMS.
There's my input.
Joined: Feb 08, 2005
It seems pretty clear that I wouldn't run any mission critical stuff on it, but I think it is a great tool for some stand alone apps. Data collector stuff, quick desktop catalogs etc.
I'm a long-time user of db4o, and after years of mundane coding against SQL Server, had a completely different experience using db4o. It's true that you have a different set of headaches when you use a different database. But in my case, most of those headaches came from trying to forget all the relational patterns that we have been brainwashed into using with relational systems. I had been unconcously trying to force db4o into the same patterns as a SQL Server, when the opposite was true. db4o freed me from the mundane pattern of brokers, m-v-c, and connection pooling.
Hibernate and the hibernate config files are a whole rats-nest of SQL code that must work flawlessly. You spend so much more time making sure that your class design is compatible with your mapping files that it's almost like writing all that O/R code yourself. db4o lets you focus on building good object designs, and lets you forget that you've even got to mess with a database at all. It lets you design your application in the manner that makes the most sense...and when you want to save an object, it's as easy as a single call.
That being said, there's still the age-old argument: use the right tool for the job. I love db4o, and I use it for almost all of my coding projects. But there are some times when you're stuck with legacy systems that you need to interface with, or sometimes a SQL server is just plain better for certain tasks (like user-defined reports).
db4o has it's fair share of issues when one is learning to use it. But I'd hazard a guess that most of them are just re-educating yourself about what good OO design really is, instead of trying to avoid it.
Joined: Feb 08, 2005
I have a question Erik. How do you migrate from one object oriented dbase to another. For example I can export to SQL commands and run those to move say from MySQL to MS SQL sever (NOTE: example case not something I'd really do!).
To use something like db4o in major production systems I would need a way to make sure my information isn't stuck in one format. Any experience with any other OODB other than db4o? If so which and how do you move info around? If not have you considered this problem down the road?
hi ,Gerardo. How migrating data from one object oriented dbase to another or to a relational db is not an impossible mission, in my opinion. Just like your example, migrating data from rdb to another rdb you could export to SQL commands and run those. So I can clear my question with the same way. The most different thing about our solutions is that while you use SQL commands as broker, I use a java code snippet such as belows:
Object o=OneOODB.getObject();//get data from one oodb Object o2=new Object();//create an instance that mapping another oodb o2.setValue(o.getValue());//trans data from one persistance to another AnotherDB.save(o2);//persist o2 in new oodb
I don't think the way will be more difficult than you and some problems we both would meet such as matching the data type between different db.
Oh,father,though im in the nutshell,i still the king of limitless space.<br /> <br />scjp 1.4,scwcd 1.4,scbcd 1.3