Question

I’m looking for opinions on the following localization technique:

We start with 2 tables:

tblProducts : ProductID, Name,Description,SomeAttribute
tblProductsLocalization : ProductID,Language,Name,Description

and a table-valued function:

CREATE FUNCTION [dbo].[LocalizedProducts](@locale nvarchar(50))
RETURNS TABLE
AS (SELECT a.ProductID,COALESCE(b.Name,a.Name)as [Name],COALESCE(b.Description,a.Description)as [Description],a.SomeAttribute
from tblProducts a 
left outer join tblProductsLocalization_Locale b 
on a.ProductID= b.ProductID and b.[Language]=@locale)

What I plan to do is include the the function whenever i need localized-data returned:

select * from LocalizedProducts('en-US') where ID=1 

instead of

select * from tblProducts  where ID=1 

I’m interested if there are major performance concerns arround this or any showstoppers. Any reasons I shouldn’t adopt this?

Edit: I’ve tagged this SQL2005 , altough I develop this using 2008, I think the deployment target only has SQL2005. I could upgrade to 2008 if the need arises though.

Later edit:

I have created a view, with identical content, but without the parameter:

CREATE VIEW [dbo].[LocalizedProductsView]
AS
SELECT b.Language,a.ProductID,COALESCE(b.Name,a.Name)as [Name],
COALESCE(b.Description,a.Description)as [Description],a.SomeAttributefrom tblProducts a 
left outer join tblProductsLocalization_Locale b on a.ProductID= b.ProductID 

I then proceeded to run some tests:
Estimated execution plan looks identical to both queries:

select * from LocalizedProducts('us-US') where SomeNonIndexedParameter=2

select * from LocalizedProductsView where (Language='us-US' or Language is null) and SomeNonIndexedPramaters=2

Final Question that arrises is: Should I understand that the TVF is computing the translations on ALL the products, regardless of the WHERE parameters? is the View doing the same thing ?

Answer 1

I wanted to come back with an answer to this after doing a lot more testing.
It appears to me that SQL2008 is actually looking inside the TVF when performing the query plan and optimizing accordingly:

For instance:

select pr.* from LocalizedProducts('en-US') pr inner join LocalizedPhotos('en-US') ph on 
ph.ProductId=pr.Id where pr.SomeUnindexProperty= 5

This query needs to touch 4 tables:

Products
Products_Localization
Photos
Photos_Localization

The way the query plan looks is that (let me see if I can format this):

Product gets a Clustered Index Seek 
        -- >>  Products gets nested loop with Photos 
                              -->> nested loop Products_Localization -
                                          ->> nested loop Photos_Localization. 

Which is not what you would expect if the TVF would be a black box. The simple fact that Product gets an index SEEK would suggest to me that the query will not interpret blindly the entire TVF.

I ran a lot of performance tests, and on average the “localization” TVF are between 50% – 100% slower than using direct table-queries, but that would be expected as twice as many tables are involved in the TVFs than in the normal queries.