CODEWITHSUNDEEP
c#database-design
Books
Books

Reputation: 5323

Database design for storing user settings

public interface IPlugin
{
    void Execute();
}

public class FirstPlugin : IPlugin
{
    public string SomeSetting1 { get; set; }

    public void Execute() { }
}

public class SecondPlugin : IPlugin
{
    public string SomeSettingA { get; set; }
    public string SomeSettingB { get; set; }
    public string SomeSettingC { get; set; }

    public void Execute() { }
}

I have a system that allows usesr to select one or more plugins. In the code above, I have an IPlugin interface that is implemented by many classes. Each class can have their own set of properties and each user can configure those properties.

For example, User A selects only the first plugin and configures SomeSetting1 to have a value of "ABC".

User B selects both plugins, but configures the first plugin's SomeSetting1 to have a value of "XYC".

public class User
{
    public User(IPlugin[] plugins)
    {
    }
}

When I instantiate a user, I want to get a list of plugins that the user has configured and those plugins should be hydrated with what the user has configured.

However, I'm drawing a blank on how to design the database to be able to store information in this format. I could have a table:

User  |  Plugin
----------------
A     |  ...
B     |  ...
B     |  ...

... where the plugin column would be the serialized representation of the plugin that I can deserialize back into a class. However, that seems like a terrible/hacky idea. Is there a better way to do this?

Upvotes: 0

Views: 374

Answers (2)

Aleksandar Vucetic
Aleksandar Vucetic

Reputation: 14953

If you don't have to query database by some of the properties serialized in Plugin column, I don't see it as a terrible/hacky idea. Also...you might consider using some non-schema database like mongodb. Anyway, I would do it with serializing (probably JSON object, if I will later consume that result from javascript, or some XML if that is more appropriate for your environment).

If you want to stay with more relational approach...then you will have a table with plugin properties...with columns: UserId, PluginId, PropertyName, PropertyValue...then, table with Plugins: PluginId, PluginName, and your table with users: UserId,...and some columns for users (this is just one way to design it) The problem is if you have some plugin properties that are complex objects...in that case, you will have to serialize them into PropertyValue column...

Upvotes: 1

Daveo
Daveo

Reputation: 19872

Tables 

User
-----
UserID
Name

Plugin
------
PluginID
PluginName

PlugInProperty   
------------------
PlugInPropertyId
PluginID

UserPlugin
------------
UserPluginId
UserId
PluginId

UserPlugInProperty
------------------
UserPluginId
PlugInPropertyId
Value

Upvotes: 0

Related Questions