http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660__The only way of doing this with RDBMS is using joins (in a single statement), which is going to cause Cartesian product, which is expensive in the DB and have to be dealt with in the app layer. Why does it "have to be dealt with in the app layer" ? If you have either .SelectMany() from Repository or some way to say that you want to preload all posts/comments (considering that you do want to preload them and lazy load does not work well enough), why should the app layer care about how the Repository does it? http://ayende.com/3704/the-fallacy-of-irepository#comment19http://ayende.com/3704/the-fallacy-of-irepository#comment19Mon, 17 Nov 2008 07:34:26 GMTTobin, Yeah, this could just be some loose terminology. Extremely jealous of your guitar setup! http://ayende.com/3704/the-fallacy-of-irepository#comment18http://ayende.com/3704/the-fallacy-of-irepository#comment18Sun, 16 Nov 2008 23:46:59 GMT@Andrew Thanks. Wouldn't an outer join just ensure rows are return even if a join condition is not satisfied? it wouldn't result in a cartesian product would it? Maybe I need to hit the SQL books again!... Heard the news about Microsoft btw, congrats :) http://ayende.com/3704/the-fallacy-of-irepository#comment17http://ayende.com/3704/the-fallacy-of-irepository#comment17Sun, 16 Nov 2008 23:09:14 GMT@Tobin,, It's because he's referring to an Outer Join. @Ayende, Sure, but it is a single _call_. And, one that returns much less redundant data and can span a wider/deeper load graph. http://ayende.com/3704/the-fallacy-of-irepository#comment16http://ayende.com/3704/the-fallacy-of-irepository#comment16Sun, 16 Nov 2008 22:58:07 GMTI thought that a query with join conditions isn't a cartesian product? Basically, I thought the cartesian product would be this: select * from Blog, Post http://ayende.com/3704/the-fallacy-of-irepository#comment15http://ayende.com/3704/the-fallacy-of-irepository#comment15Sun, 16 Nov 2008 22:49:53 GMTThanks Ayende http://ayende.com/3704/the-fallacy-of-irepository#comment14http://ayende.com/3704/the-fallacy-of-irepository#comment14Sun, 16 Nov 2008 22:27:54 GMTBunter, something like that would take _time_. I don't have much of that. http://ayende.com/3704/the-fallacy-of-irepository#comment13http://ayende.com/3704/the-fallacy-of-irepository#comment13Sun, 16 Nov 2008 19:02:10 GMTRyan, You just made my point. In particular, the part about using the DB locally vs. remotely has huge implications on the application. http://ayende.com/3704/the-fallacy-of-irepository#comment12http://ayende.com/3704/the-fallacy-of-irepository#comment12Sun, 16 Nov 2008 19:00:52 GMTAndrew, That is not a single statement. You can see that I referred to that latest in the post. http://ayende.com/3704/the-fallacy-of-irepository#comment11http://ayende.com/3704/the-fallacy-of-irepository#comment11Sun, 16 Nov 2008 18:56:59 GMTTobin, Huh? select * from Blog join Post on Blog.Id = Post.BlogId will result in Cartesian product of each blog being repeated for each of its posts. http://ayende.com/3704/the-fallacy-of-irepository#comment10http://ayende.com/3704/the-fallacy-of-irepository#comment10Sun, 16 Nov 2008 18:56:06 GMTSimon, [ayende.com/.../Future-Query-Of-implemented.aspx](http://ayende.com/Blog/archive/2008/01/24/Future-Query-Of-implemented.aspx) Check this and also the implementation in that link. http://ayende.com/3704/the-fallacy-of-irepository#comment9http://ayende.com/3704/the-fallacy-of-irepository#comment9Sun, 16 Nov 2008 15:23:29 GMTI guess it would depend on the way you work. Personally for every service I develop, I first start with the building the domain model, i.e. a set of POCO classes that represents the domain of the application I'm creating with all the data and relations it needs to maintain. The end result is the 'ideal domain model' without any considerations for a RDBMS back end or UI front end. To persist the domain objects to a RDBMS I would translate it to a set of nHibernate data classes (which are mapped 1:1 with a db table) and save that. Basically my nHibernate data classes *do not* represent my domain model, they are just relational data objects I use to persist to a RDBMS. To move to an OODB I just do away with the translator classes and just persist the domain model directly. DB4O is a very functional OODB, with transactional support and optional client/server access. I use it for all my transactional and 'process services' (i.e. transient data) though for my repository/catalogue db's I still opt to use a RDBMS as I still like the security/ future proofing/full-text searching that a mature RDBMS can provide. http://ayende.com/3704/the-fallacy-of-irepository#comment8http://ayende.com/3704/the-fallacy-of-irepository#comment8Sun, 16 Nov 2008 15:20:05 GMTWhy not just prove it - create a sample application supporting first OODBMS and then switch it to RDBMS... It doesn't have to be even UI based, just little if core going beyond two table/object setup and some real world queries as test cases. Lot of warm air would be spared... http://ayende.com/3704/the-fallacy-of-irepository#comment7http://ayende.com/3704/the-fallacy-of-irepository#comment7Sun, 16 Nov 2008 14:30:04 GMTUsing db4o remotely appears to be a relatively rare scenario, batching becomes much less useful when everything is in process. The repository interface I have chosen where I intend to take db4o into production is narrower than Rob's - my generic base only supports fetches of aggregates by their identifier. It's just too dangerous to expose its pretty immature linq support (it's quite possible to confuse it with even simple queries that involve generics) outside of the repository, as well as it lacking index support in some scenarios. It can't construct an index on object types for one thing, and I have an EAV scenario where the types of some things cannot be known at compilation time. I am building a Lucene index on commit and using that for complex queries, as well as supporting projections from stored index fields to avoid activations in situations where I do not want to have drill into a large numbers of returned aggregates. http://ayende.com/3704/the-fallacy-of-irepository#comment6http://ayende.com/3704/the-fallacy-of-irepository#comment6Sun, 16 Nov 2008 14:20:35 GMTYou mention that your current IRepository implementations uses the future pattern. Have you got an example of it up anywhere I could read, please? http://ayende.com/3704/the-fallacy-of-irepository#comment5http://ayende.com/3704/the-fallacy-of-irepository#comment5Sun, 16 Nov 2008 13:52:39 GMTWhy not stick with the OODB? Depending on your needs of course but collage's have been very happy with Cache on a large project and it was faster then Oracle or SQL Server. And that can of course be bad query design :) -Mark http://ayende.com/3704/the-fallacy-of-irepository#comment4http://ayende.com/3704/the-fallacy-of-irepository#comment4Sun, 16 Nov 2008 12:50:20 GMT"The only way of doing this with RDBMS is using joins (in a single statement), which is going to cause Cartesian product, which is expensive in the DB and have to be dealt with in the app layer" Not true. Batched nested result sets is another approach. http://ayende.com/3704/the-fallacy-of-irepository#comment3http://ayende.com/3704/the-fallacy-of-irepository#comment3Sun, 16 Nov 2008 12:29:31 GMTCorrection, I think a Cartesian product is where you *don't* have a join? http://ayende.com/3704/the-fallacy-of-irepository#comment2http://ayende.com/3704/the-fallacy-of-irepository#comment2Sun, 16 Nov 2008 12:28:38 GMTLinq would make this transition easier, i think. Linq provides another level of abstraction so that you don't have to do joins _manually_. Even though this is the case, this assumption is usually not really good, i have to admit because not all the providers are perfect, and one has to workaround for one provider and not for the other. I mean db4o may not fail for one specific expression but linq 2 sql would(or yield in perf problem such as n+1), this thing would hide the problem when transition to sql occur. http://ayende.com/3704/the-fallacy-of-irepository#comment1http://ayende.com/3704/the-fallacy-of-irepository#comment1Sun, 16 Nov 2008 09:56:57 GMT