Question

Is there any way to alter the underlying database using EF using Code First approach?

I have 2 tables which have a static model:
Users and Info1.

I also have another table which Ill call info2.

I would like to be able to add and remove columns from Info2 from the admin section of my website.

My goal is to have a website which can dynamically be altered as you go, adding and removing fields as the user likes, without the user having to know anything about coding.

I’ve considered using a separate database outside of the one specified in the model of my MVC3 project and do straight SQL requests to that instead.

This could also be accomplished by having a table with the dynamically created fields, and another with the data, but this gets messy fast.

Has anyone done anything like this? Is it a bad idea?

Answer 1

I’d recommend not trying to expand the table horizontally, that’s an operation that you should make a conscious decision to have.

Instead, I’d recommend that you store the values as name/value pairs. You can have tables that have specific types (let’s say you needed an integer value paired with a key), and then you would select those into a dictionary for the user.

You’d also have a table which has the keys, if you are concerned about replicating key values.

For example, you’d have a UserDefinedKey table

UserDefinedKeyId (int, PK)     Key (varchar(?))
--------------------------     ----------------
                         1     'My Website'
                         2     'My favorite color'

Then you would have a UserDefinedString table (for string values)

UserDefinedStringId  UserId     UserDefinedKeyId  Value
(int, PK)            (int, FK)  (int, FK)         (varchar(max))
-------------------  ---------  ----------------  --------------
                  1          1                 1  'http://stackoverflow.com'
                  2          1                 2  'Blue'
                  3          2                 2  'Red'

You’d probably want to place a unique index on the UserId and UserDefinedKeyId fields to prevent people from entering multiple values for the same key (if you want that, have a separate table without the unique constraint).

Then, when you want to add a value for users, you add it to the UserDefinedKey table, and then drive your logic off that table and the other tables which hold the values.

Another benefit of storing the values vertically is that you aren’t wasting space for columns with values that aren’t being used by all users.

For example, assuming you take the approach of modifying the table, for the attributes above, you would get:

UserId  WebSite                   Color
------  -------                   -----
     1  http://stackoverflow.com  Blue
     2  (null)                    Red

Now let’s say a third user comes along, and adds a Favorite Sports Team value, and they are the only one who uses it, the table then looks like:

UserId  WebSite                   Color  FavoriteSportsTeam
------  -------                   -----  ------------------
     1  http://stackoverflow.com  Blue   (null)
     2  (null)                    Red    (null)
     3  (null)                    (null) Yankees

As the number of users and attributes grows, the amount of sparse data that you have will increase dramatically.

Now, assuming you are using SQL Server 2008, you could use sparse columns, if you don’t, your table is going to get huge but not have much data.

Also, using sparse columns doesn’t take away from the fact that it’s pretty dirty to use data definition language (DDL) to change the schema on the fly.

Additionally, Entity Framework isn’t going to be able to adapt it’s object model to account for the new attributes; every time you have an attribute added, you will have to go and add the attribute to your object model, recompile, and redeploy.

With a vertical approach, it takes more work, granted, but it will be infinitely flexible, as well as utilize your database space more efficiently.