Benji,

I can do you one better - Drop me an email or give me a call (I use the same forum name on the crmsuccess.com forums) and I'll give you access to our EE account and let you see what I'm trying to do.

For the benefit of others: We have invoices integrated into Salesforce. The invoice itself is a child of the Account object, and has lookup relations to Contact, Opportunity, and our custom Installed Product object (asset tracking).

A single SQL-like query would be like this:

Select Invoice.*, Account.Name, Account.Address, Contact.Name, Contact.Address, Contact.Phone, Opportunity.Name, InstalledProduct__c.*, From Invoice JOIN Account ON Account.Id = Invoice.AccountId JOIN Contact ON Contact.Id = Invoice.ContactId JOIN Opportunity ON Opportunity.Id = Invoice.OpportunityId JOIN InstalledProduct__c on InstalledProduct__c.Id = Invoice.InstalledProductId Where Invoice.Id = '<>'

I can see a few other situations where 'simple' child to parent joins would save quite a few calls. Think of the times you would want to show a Contact record to a user but want to include the Account.Name field.... anyway back on topic... That SQL-like statment, if executed via the API would return all the bottom-up information I need from the invoice. What uses 5 calls right now would become 1. I would guess the biggiest question would be how that information would be returned. I would presume an array of sObjects. Then it comes down to being able to optimize the query on your side as not to kill performance on the DB end.

There are also several child objects, mostly what you'd expect: Line Items, Payments, Notes, and Tasks and Events. (The latter 2 being the biggest kludge... Can't hardly wait the 8 days to get rid of it.)

In the case of these invoices I have to pull down all the related child data for the invoice. So if I can make a hypothectial call like

sObject[] records = sfBinding.RetrieveWithChildren("");

and get the invoice object with all it's 1st-tier children (typecasting can be done by the IdPrefix and the DescribeSObject items) I can roll another 5 queries up into 1 retrieve call right there. I'd still need to do some other lookups. (Our line items contain links to the Product2 object and would be 2nd tier off the invoice).

The remaining API calls are unoptimized (the current kludge to attach activities is not optimized because it's going away in 8 days), or unoptimizeable. I.E. I call getUserInfo() and do a Retrieve() on that user to get his/her First and Last Name (we use initials not full names).

So I guess the totals would be like this:

Buttom up queries now 5, could be 1.

Top-Down queries now 5, could be 1.

Other (Product2, getUserInfo, and Retrieve User object) 3.

When we include the 12 describeSObject calls becomming 1 here's what we get:

25 calls now could become 6. If each calls has 1/3rd of a second of overhead (setup, SSL, teardown) and runs in series that's about 8 1/4 seconds of overhead now vs what could be 2 seconds -- a savings of 6 1/4 seconds or about 75% of the overhead.