Home/ Questions/Q 269797
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T23:53:40+00:00

I inherited a system that stores default values for some fields in some tables

  • 0

I inherited a system that stores default values for some fields in some tables in the database. These default values are used in the application to prepopulate control values. So, essentially, every field in every table in the database can potentially have a default value. The previous developer decided to store these values in a single table that had a key/value pair combo. The key represented by the source table + field name (as a varchar) and the default value as a varchar field as well. The Business layer would then cast the varchar field to the appropriate data type.

Somehow, I feel this is brittle. Though the application works as expected, there appears to be a flaw in the design.

Any suggestions on how this requirement could have been handled earlier? Is there anything that can be done now to make it more robust?

EDIT: I should have defined what the term “default” meant. This is NOT related to the default value of a field in the table. Instead, it’s a default value that will be used by the application in the front end.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    That schema design is fine. I’ve seen it used in commercial apps and I’ve also used it in a few apps of my own where the users needed to be able to change the defaults or other parameters around fields in the application (limits, allowable characters etc.) or the application allowed the users to add new fields for use in the app.

    Having it in a single table (not separate default tables for each table) protects it from schema changes in the tables it supports. Those schema changes become simple configuration changes in this model.

    The single table makes it easy to encapsulate in a Class to serve as the “defaults” configuration object.

    Some general advice:
    When you inherit a working system and don’t understand why something was designed the way it is – the problem is most likely your understanding, not the system. If it isn’t broken, do not fix it.

    Specific advice on the only improvements I would recommend (if they become necessary):
    You can use the new SQLVARIANT field for the value rather than a varchar – it can hold any of the regular data types – you will need to add support for casting them to the correct data type when using the value though.

    • 0