Configurable Table Prefixes with a .Net OR/M?

Question

In a web application like wiki or forums or blogging software, it is often useful to store your data in a relational database. Since many hosting companies offer a single database with their hosting plans (with additional databases costing extra) it is very useful for your users when your database objects (tables, views, constraints, and stored procedures) have a common prefix. It is typical for applications aware of database scarcity to have a hard-coded table prefix. I want more, however. Specifically, I'd like to have a table prefix that users can designate—say in the web.config file (with an appropriate default, of course).

Since I hate coding CRUD operations by hand, I prefer to work through a competent OR/M and have used (and enjoyed) LINQ to SQL, Subsonic, and ADO.Net. I'm having some thrash in a new project, however, when it comes to putting a table prefix in a user's web.config file. Are there any .Net-based OR/M products that can handle this scenario elegantly?

The best I have been able to come up with so far is using LINQ to SQL with an external mapping file that I'd have to update somehow based on an as-yet hypothetical web.config setting.

Anyone have a better solution? I tried to make it happen in Entity Framework, but that turned into a mess quickly. (Due to my unfamiliarity with EF? Possibly.) How about SubSonic? Does it have an option to apply a table prefix besides at code generation time?

Answer 1

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.

Answer 2

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

Answer 3

Rather than use table prefixes instead have an application user that belongs to a schema (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