If you’re writing custom code to access Salesforce.com data you interact with the API. This code can run inside Salesforce.com as S-Controls (Javascript and HTML pages), on your own webserver, or just about anywhere (like the Outlook add-in.)

If you want to query the data in Salesforce.com in your code (which you always want to do) you use Salesforce Object Query Language (SOQL). When people ask me about SOQL, I tell them “it’s like structured query language (SQL) without joins.” As of this week I’ll have to come up with a new description because SOQL is getting relationships in the new API.

We’ll now be able to query a table and get related data from another table. SQL figured out joins in 1934, so it’s great that SOQL is adding relationship support. But they’re not implementing SQL type joins. In SQL joins, your result set is flat–in SOQL it will be hierarchical. This means that if you’re used to doing SQL joins, somethings will be easier in SOQL, and other things will be harder. Sometimes a flat result set is just what you want. Other times it’s not.

I had a chance to play with the SOQL relationships a bit last year and this one feature alone will cut my API calls significantly. If I wanted data from one table and some related data I would often do it in one call to the main table and then individual calls to the related table for each row returned. So for 100 Opportunities that’s 101 API queries to find out all the Contact Roles on those Opps. I’ll now be able to do this in one query. Wow.

As the Salesforce Heretic says, Salesforce may see a big drop in API traffic when they implement these changes. They should remember that a drop in API traffic is probably a really good thing…