EF4/5 autogenerates LocalDb databases: what's the SQL Server equivalent?

Question

I've been developing a web application that uses Entity Framework 5 as the ORM. EF5 will auto-generate a file for each new database I want (with its default behavior with no connection string but System.Data.Entity.Infrastructure.LocalDbConnectionFactory specified in the web.config). I've been generating a new database for each customer. I expect no more than 5000 total customers in my lifetime. How do I translate this functionality onto the big Sql Server? Do I need to write my own code to create databases on there? Where would that go?

Answer 1

At my workplace we generate and store a create script for each successive version of our application so that at any time we can spin up a database at any version. This would be my suggested method of creating new databases (code to make the database on the server and then running the create script). This code would run wherever you register new clients (perhaps delaying their registration notification until their database is ready?).

I think that running 5000 databases out of one SQL Server instance is an unreasonable large number, and you should consider how to split up your databases onto separate servers and how to manage pointing to the correct host.

Given an connection string to an existing database on SQL Server, and the proper initialization setting (CreateIfNotExist), your DbContext will work its magic and create the database structure for you. This of course will leave you lacking any non-table elements in your database (stored procedures, functions), so you would have to manage adding those after the fact (unless that is a feature of EF I don't know about).

You could also re-work your database structure so that all clients exist in one database with tables having a ClientID field. Since I don't know the details of your application it would be hard to say if that is a good solution or not.

Regarding EF and connection strings:

To specify a connection string in Entity Framework you have TWO options.

Option 1. Pass the actual connection string (as a string) into the constructor of your DbContext. You can also do method two this way, but instead of passing in the actual connection string you pass in the NAME of the connection string in your app.config (or web.config).

public class YourContext
{
public YourContext(string connectionString) : base(connectionString) { }
}

Option 2: Specify the connection string in the app.config of the application which is consuming your DbContext and pass in the NAME of the connection string in the app.config. This is my preferred method, and I usually hard-code the name into the DbContext class.

public class YourContext
{
  public YourContext() : base("YourContext") {}
}

in your App.Config

<connectionStrings>
<add name="YourContext" connectionString="Data Source=YourDataSource(SQLServerInstance);Initial Catalog=YourDatabaseName;User Id=selfexplanatory;Password=selfexplanatory" providerName="System.Data.SqlClient" />
<add name="GenericYourContext" connectionString="Data Source=YourDataSource(SQLServerInstance);Initial Catalog={0};User Id=selfexplanatory;Password=selfexplanatory" providerName="System.Data.SqlClient" />
</connectionStrings>

Answer 2

The "Big" SQL Server, can be controled by connection Strings without any problems. Your DBContext just has to pass the name of the connectionString ("name=yourconnectionStringNameHere") as parameter to it's superclass (in Constructor):

class MyDBContext : DBContext {
    public MyDBContext(String customerConnectionString) : base("name="+customerConnectionString) {}
}

This will lead to a Database per customer which can be autocreated. If you are using code-first (which i think, because you speak of autogenerating database) you (both of you ;)) should also take a look into EF-Migrations, which make change scripts on version updates and handle them in SQL for you.

Hope this helps