views:

596

answers:

4
A: 

LightSpeed allows you to specify an INamingStrategy that lets you resolve table names dynamically at runtime.

Andrew Peters
+1  A: 

Rather than use table prefixes instead have an application user that belongs to a scheme (in MS Sql 2005 or above).

This means that instead of:

select * from dbo.clientAProduct
select * from dbo.clientBroduct

You have:

select * from clientA.Product
select * from clientB.Product
Keith
A: 

@Andrew LightSpeed looks good and I really like having an INamingStrategy for tables. It looks like the Mindscape folks are doing some interesting work. Since the project I want this for is intended to be open source some day, it's not a fit for the exact situation. It is something to keep in mind for business dev, though.

@Keith That seems like a delay of the issue rather than a solution. It pushes the burden onto the user to create the scheme and get the connection string right (ugh), or it requires an OR/M that can be both scheme-aware and pull the required scheme from the config file. I admit that I haven't worked much with schemes, however, so that may be more viable than it seems on its face.

Jacob Proffitt
Beware of lightspeed - I bought a license last month and have hit several problems with their product - pretty big problems in fact, like:> Inability to specify a primary key on new entities.> Inability to handle composite keys as 1st class citizens> Serious performance degredation when using LINQ joins
Mark
A: 

I've now researched what it takes to do this in both Entity Framework and LINQ to SQL and documented the steps required in each. It's much longer than answers here tend to be so I'll be content with a link to the answer rather than duplicate it here. It's relatively involved for each, but the LINQ to SQL is the more flexible solution and also the easiest to implment.

Jacob Proffitt