Question

I have an EntiyFramework project for which i am storing settings in a table.

The setting supports different types but ultimately stores the settings in a string, and converts to the specific type (GUID, string, TimeSpan etc).

Everything works, i just would like to check:

1. Is there any better way to store application settings in the table (I can have multiple companies for which there are different settings for each)?

2. What if a setting, for example ‘default_reply_type’, type GUID, references another object primary key in the database?

   There might be a few settings like this where other objects are referenced, and this may increase in future.

   I appreciate there is no explicit referential integritary checking in the schema, but i could implement this manually as part of business logic – is this ok or a nasty fudge?

Regards,

Chris

Code is below.

public abstract class Setting
{
    [Key, Column(Order = 0)]
    public string SettingName { get; set; }
    [Key, Column(Order = 1)]
    public Guid CompanyID { get; set; }
    public virtual Company Company { get; set; }

    public string SettingValue { get; set; }
    public string Description { get; set; }

    public virtual void ConvertToType(string value, ref object outvalue)
    {
        outvalue = Convert.ChangeType(value, outvalue.GetType());
    }

    public virtual string ConvertToString(object value, Type type)
    {
        return Convert.ChangeType(value, typeof(string)).ToString();
    }

    public DateTime? UpdatedDateUTC { get; set; }
}

public class StringSetting : Setting
{
    // no need for any overrides as string is base type
}

public class TimeSpanSetting : Setting
{
    public override void ConvertToType(string value, ref object outvalue)
    {
        TimeSpan ts = new TimeSpan(Convert.ToInt64(value));
        outvalue = ts;
    }

    public override string ConvertToString(object value, Type type)
    {
        if(type != typeof(TimeSpan))
            throw new InvalidCastException(); // throw an error!

        return ((TimeSpan)value).Ticks.ToString();
    }
}

Answer 1

My own advice on this is as follows:

Represent Guids with the uniqueidentifier type in SQL. Represent TimeSpans with the bigint type in SQL and store ticks.

If the uniqueidentifier type is used for a non-primary-key column, consider setting the default value for the column to the empty GUID using CONVERT(uniqueidentifier, ‘00000000-0000-0000-0000-000000000000’) rather than allowing NULL values.

Review the SQL documentation on uniqueidentifier before using it as a primary key. There are some specific caveats to its use that the application and database designers must be aware of. The SQL Server Books Online topic Using uniqueidentifier Data is a good place to start.

If a uniqueidentifier is used for a primary key consider setting the column default to either NEWSEQUENTIALID() or NEWID(). The former is generally the preferred choice.

Foreign keys help the SQL optimizer decide some things, so it’s good to have them if possible, but sometimes there’s just no easy way to relate things that way.

You should try to avoid multi-column primary keys as they can introduce a range of problems, one of which is fragility of the designed schema, and another being that they are more costly to index and search.

To answer your question 1: One possible way to store setting information that has multiple variants is to store the settings in an xml column. See xml (Transact-SQL). In fact, you can even store objects in the database using an XmlSerializer (see XmlSerializer Class), which makes the content fairly human readable. There are also ways to extract information from xml serialized objects directly in SQL if necessary (See xml Data Type Methods).

To answer your question 2: It’s possible that you could design xml stored settings in such a way that it doesn’t need the reference. Barring that, be sure that your column containing the Guid is indexed if it’s not a primary key and make sure you thoroughly review the information on uniqueidentifiers that I referenced earlier so that you understand the impacts, performance and otherwise, of choosing to use Guid/uniqueidentifier.