New Posts New Posts RSS Feed: Why perform a SELECT * when I bind to a property of a related object?
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Why perform a SELECT * when I bind to a property of a related object?
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
Customer View Drop Down
Senior Member
Senior Member
Avatar
User Submitted Questions to Support

Joined: 30-May-2007
Location: United States
Posts: 260 		Post Options Post Options   Quote Customer Quote  Post ReplyReply Direct Link To This Post Topic: Why perform a SELECT * when I bind to a property of a related object?
    Posted: 12-Jul-2007 at 3:58pm
Why is it that when I bind to a relation, it performs a SELECT * rather than just retrieving the property I want?   I might just make a view in this situation.   Your thoughts?
Back to Top
IdeaBlade View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 30-May-2007
Location: United States
Posts: 353 		Post Options Post Options   Quote IdeaBlade Quote  Post ReplyReply Direct Link To This Post Posted: 12-Jul-2007 at 3:58pm
I realize that you often want to bind only to a single property of a related object (e.g., the CompanyName of the Customer object related to the Order object on screen). You are disheartened that we fetch the whole related Customer object rather than just the property you will show. Isn't that inefficient?
 
DevForce always returns whole objects. You can fake it out (with dynamic objects for example) but that is not the norm and you have to work at it a bit to to get less than the whole object. Thus binding to the "CompanyName" property of an Order - via 'Customer.CompanyName" - results first in execution of something like "anOrder.Customer" - which returns a Customer object - and then binds to the "CompanyName" property of that Customer.
 
It would be inconsistent to do otherwise.
 
It would also be non-performant to do otherwise in many cases. Imagine that I bound to Customer.HqAddress.Street, Customer.HqAddress.City, Customer.HqAddress.Province, and Customer.HqAddress.PostalCode.  If we retrieved "just the properties", we'd be making at least four separate queries here.
 
Multiple roundtrips to the database are almost always more expensive than getting a little more data than you think you will need (e.g., bringing the whole Customer down rather than just the Customer.CompanyName). Caching saves many trips. Span queries (in which you fetch an Order's related Customer object at the same time that you fetched that Order) can save many more trips.
 
I hope this helps.
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down