Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Performance using SP with LLBL Gen
 

Pages: 1
LLBLGen Pro Runtime Framework
Performance using SP with LLBL Gen
Page:1/1 

  Print all messages in this thread  
Poster Message
Viresh
User



Location:
Ahmedabad, India
Joined on:
28-Jan-2008 08:52:54
Posted:
31 posts
# Posted on: 23-Feb-2008 06:29:25.  
Hi,

I'm novice to LLBLGen Pro and I implemented LLBLGen in one of my small project. I'm impressed with this framework. But I've following major query before I move ahead. Kindly guide me.

Uptil now I was using typical 3 tier architecture which deals with Stored Procedures in database. I know it is possible to use SP with LLBLGen but will it be good to use SP with LLBLGen? or should I go without SP? Let's say if my project deals with millions to billions data, will LLBLGen give me a performance?

Please solve my query. Thanks in advance.



Regards,

Viresh Shah
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38081 posts
# Posted on: 23-Feb-2008 10:25:06.  
A stored procedure or a query generated by LLBLGen Pro are threated the same by the database: the SQL is interpreted and transformed into an execution plan, which is executed. The execution plan is cached. WHen the query is executed again on the client, the same execution plan is executed.

So there's no performance advantage for procs there.

What you should do is looking into ways to do as much as possible on the database when you're dealing with big sets of data: it's not efficient to read millions of rows to the client, process them there and send them back: it's then easier to process them on the database side. LLBLGen Pro allows you to write very complex queries so it's very often perfectly possible to use llblgen pro generated queries for this purpose. If you still need a big stored procedure to process data, you can, even for fetching entities (through projections)

So you're flexible in this: if you really need to go for a procedure because the query is very long and needs things like temptables, cursors etc. so you need a big procedure, you can offload that logic to a procedure and use that in your project. So it's flexible, it's up to you what to use where, you're not forced to use one over the other.

(prefetch paths and insert/update/delete queries are done with dynamic sql generated by llblgen pro. However this isn't a problem, most bottlenecks are in fetches, e.g. reports aggregating millions of rows)


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Viresh
User



Location:
Ahmedabad, India
Joined on:
28-Jan-2008 08:52:54
Posted:
31 posts
# Posted on: 23-Feb-2008 11:05:58.  
Thanks a lot Frans for a detailed explanation.
Regards,

Viresh Shah
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.