Hi everyone,

I'm currently taking a tour of your product. It has some great features but there is just one thing that worries me about the Prefetch paths system.

According to the help, using prefetch paths results of SQL subqueries being generated. Would it be possible to have the framework generating a JOIN statement instead?

No sub queries are always used.

Review this thread

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=4494&HighLight=1

Frans said

I've done various experiements with all kinds of setups how to pull data for prefetch paths and which one would be more efficient, and subqueries were the most efficient. With Marcus' optimization code, this is optimized a lot in 1.0.2005.1

Although I'd be interested on his thoughts now?

Joins are not more efficient than subqueries. Most modern rdbms's will show an equal execution plan for a join compared to an equivalent subquery.

Joins have two problems:

1) in 1:n situations, you'll get duplicates. This can be a problem to filter out, because the resultset might contain a DISTINCT violating type. 2) joins make it impossible to fetch multi-branched graphs.

LLBLGen Pro does everything it can to optimize the query to use. In the upcoming v2.5 (now in beta) we have added additional optimizations which often don't refer to any related table at all (so just have IN clauses on the same table, which is much faster than any join ).

Thanks for answering, Ok, I was almost sure that joins were more efficient than subqueries when dealing with large amounts of data... If that's wrong or at least not very true, there is no need to worry then .

I'm looking for an ORM because I have realised that some of my previous .Net projects are nightmares to maintain. I have done the mistake of mixing the business logic of my apps with data access code by using the MS standard dataset architecture. As a result, any single change can take days because the code has become too confusing and it's now hard to modify anything without the risk of generating new bugs.

Your product is very interesting to me because it's the first to offer the advantages of both object-oriented thinking and design-time GUI binding, so I think it could be the answer. The problem is that I can't afford to completely sacrifice performance for ease of use and productivity, this is why I ask that kind of question.

The problem is that I can't afford to completely sacrifice performance for ease of use and productivity, this is why I ask that kind of question.

Please read the help, reference manual and this forum and you'll be aware of the performance of this great tool Please ask us any worry of performance you would have.

Thanks daelmo,

I have been running different tests since Monday. It looks very positive so far; I have been able to have LLBLGen generating exactly the sql statements I would have written myself in most cases!

Amazing...