4 replies to this topic

[Wolvendeer]

I'm currently working on designing a database for a software project I'm working on. This is my first software project using a database, though, and I'm not exactly sure how I should go about storing program configuration information. I would like to store it inside of a table in the database as opposed to a separate configuration file, but I'm not sure about how to implement a table that would be prepared for any new settings I might add at a later date while keeping 3NF. Should I just go with something like [Key] | Setting Name | Setting Value?

[WingedPanther]

I would start with the settings you currently have, and the nature of them. If you want to store things like "component name" "property" "value", then it could vary from simple to psychotic (some properties are objects of other data types).

Your choice of language will also be important, as some languages support access to an objects name, and others don't. Some make it simple to loop through objects/properties, others don't.

[Wolvendeer]

I see. My language of choice is Tcl/Tk, but I'm not sure if it allows the access to an objects name you were talking about. For different data types, would it be bad practice to store all of the data as strings regardless of whether the properties were integers, floats, or strings?

The type of data I can foresee at the moment would be what version of the program the use is running (to handle necessary operations when they upgrade the program, theming data (basically color values and what the user is applying the value to), and data on what range of information a user wants to display in the chart (probably a mix of integers and boolean values).

[WingedPanther]

The one other issue you will need to be aware of is field lengths. You probably don't want to use a blob to store properties, but some properties are strings, and could be quite long.

Overall, it shouldn't be too hard to implement.

[LuthfiHakim]

Basically you can get away with your current structure (Key | Setting Name | Setting Value), and use strings for setting name and setting value fields. However I recommend to add another field to indicate the actual type of the value. This way, if you want to, you can validate the values. If your db supports user functions, then you can wrap a specific setting into a function and making the conversion transparent. In this case, the "value type" field would allow you to create an abstract function as the base for other specialized functions.