tag:blogger.com,1999:blog-1098314322688642582.post623075615325450436..comments2007-11-16T15:30:13.171ZChris Brindhttp://www.blogger.com/profile/15060997991535798622noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1098314322688642582.post-59171001645637644382007-11-16T15:30:00.000Z2007-11-16T15:30:00.000ZHi Ced,<BR/><BR/>You have the option of both. DB4O is an Enterprise level database, you can either run it embedded app agains a file or you can run it standalone and use a client connection. Beyond opening the file or making the connection the interface is identical.<BR/><BR/>You need to see their website for information on scaling, etc. And its works with .NET too (not that you'll be bothered about that I suppose).<BR/><BR/>You'll love it! =)<BR/><BR/>Cheers,<BR/>ChrisChris Brindhttp://www.blogger.com/profile/15060997991535798622noreply@blogger.comtag:blogger.com,1999:blog-1098314322688642582.post-17853094288692207482007-11-16T14:55:00.000Z2007-11-16T14:55:00.000Zwhat do you mean about "disciplined"? eh? :-)<BR/><BR/>In term of database optimum stuff like index, tablespace, etc. I would have a separate SQL script which I would run after the hibernate hbm2ddl.<BR/><BR/>I'll have a look at db40 if I've got the opportunity to ditch Oracle... so if I've got it correctly, by using DB40, you don't have a separate box? is it all in the app server? what about scalability, load, etc.<BR/><BR/><BR/>Ced.Cedhttp://www.blogger.com/profile/15464475377545202793noreply@blogger.comtag:blogger.com,1999:blog-1098314322688642582.post-47988850352037655502007-11-16T14:30:00.000Z2007-11-16T14:30:00.000ZHi Ced,<BR/><BR/>It sounds like you have a disciplined approach at least, but how do you know your database design is optimal?<BR/><BR/>What happens if you determine your database design sub-optimal and you need to make an improvement some how.<BR/><BR/>Also, what about other database specific aspects like indexing and so on. Is this all done through your modelling? How do you know that what comes out the other end is valid?<BR/><BR/>Personally for those reasons alone, I think it's a bad idea to model both the database and application objects in a single place.<BR/><BR/>The best solution would be not have a database at all, which is what using an ODBMS is like. It's just persistent storage for your app's object. Further more your queries are <B>code</B>, not just strings in code, but actually compilable. A good ODBMS (e.g. DB4O) will optimize the query, but the important point is that it gets checked by the compiler and not at runtime. Cool eh?<BR/><BR/>Seriously, RDBMS and ORM are out of date. On your next green-field project consider using DB4O instead of an RDBMS (you can still use reporting tools like Bert so don't let that put you off).<BR/><BR/>Cheers,<BR/>ChrisChris Brindhttp://www.blogger.com/profile/15060997991535798622noreply@blogger.comtag:blogger.com,1999:blog-1098314322688642582.post-87298210043482698182007-11-16T14:17:00.000Z2007-11-16T14:17:00.000ZHi Chris,<BR/><BR/>For my past two projects, we've done it like this:<BR/> - write the hbm by hands<BR/> - generate the entities with "hbm2java"<BR/> - generate the database with "hbm2ddl"<BR/><BR/>So you are maintaining only one thing in the database layer: the HBMs.<BR/><BR/>I've integrated the generation by using maven so every cycle of build, I'm generating the entities (so I don't keep the entities in CVS/subversion).<BR/><BR/>The only disadvantage of that approach, you can't add behaviour to your entities (due to the generation cycle). To bypass this issue (when I need it), I've used the proxy pattern which encapsulate an entity and provide additional behaviour.<BR/><BR/>In my past experience the database is tight couple to only one application. Is there any reason why you talk to the inflexibility of the database structure with Hibernate if you are in that kind of scenario?<BR/><BR/>For me, designing the hibernate entities is the same of doing the database design.<BR/><BR/>With an MDA approach (my prefer solution), you are modelling the database/entities with UML and behind the scene it uses a combination of its own tools (AndroMDA) and the hibernate tools. You don't get the issue with inflexibility of adding behaviour to your model.<BR/><BR/>Obviously by using an ORM library, the database layer is a black box. Is not Java application and a separate database. You have to design/maintain the ORM layer instead of maintaining two separate things. Is that not a good thing? :-)<BR/><BR/>My 2 cents...<BR/>Ced.Cedhttp://www.blogger.com/profile/15464475377545202793noreply@blogger.comtag:blogger.com,1999:blog-1098314322688642582.post-89347417039992158932007-11-13T23:27:00.000Z2007-11-13T23:27:00.000ZHi German! <BR/><BR/>Well, yes... I would agree, but <STRONG>apparently</STRONG> our customers would see it as a barrier as they would expect to be able to use an RDBMS (i.e. so they can run their own queries if they want to). <STRONG>I</STRONG> realise that DB4O can be used with reporting tools like Bert, but convincing management is very tricky. :(<BR/><BR/>But, I'm fully behind ODBMS and especially DB4O and intend to push it whenever I can. =)<BR/><BR/>Cheers,<BR/>ChrisChris Brindhttp://www.blogger.com/profile/15060997991535798622noreply@blogger.comtag:blogger.com,1999:blog-1098314322688642582.post-66660974421276288642007-11-13T20:45:00.000Z2007-11-13T20:45:00.000ZHi!<BR/><BR/>Your explanation of the problems related to ORM (and particularly Hibernate) is excellent!<BR/>However, why replace db4o once everything is nicely set up with a cool ODBMS? =)<BR/><BR/>Best regards!<BR/><BR/>German Viscuso<BR/>db4o community managerGerman Viscusohttp://www.blogger.com/profile/05542920325440015442noreply@blogger.com