Question

I am a little confused about how I would restructure my database, currently I am engaged with three tables:

1. Items: which contains the basic information of an “item” (user.id, name, description, feature_1(bool), feature_2(bool) .. etc)

2. Feature_1: Which contains some optional values for an “item”, so if the user decides to have Feature 1 to his item we it will create a record in Feature_1 and fill in those values. 1 item cannot have more than one record in “Feature_1” table so either it has 1 record or none.

3. Feature_2: Same as Feature_1 but has different optional values, so the user could add Feature_1 to his Item and/or Feature_2. Again each item can have 0 or 1 Feature_2 record.

I am not sure if it is the best practice or not, one of the options was mashing all values in 1 table “Items” with many NULL values.

Any advice and pointers will be greatly appreciated.

Answer 1

Separating out values like this can be helpful in terms of dealing with locking issues. If you have multiple daemons/scripts running that are updating and those tables and holding locks on them, it can be an issue to keep all those values together on one table. Of course, now that the values for the ‘item’ are separated on to three tables, you are going to have issues with chasing them down if/when you need all of them. Generally it is fine to keep these tables split up like this.

Additional, before anyone goes down the road of splitting data like this, it is generally better to try/exhaust each of the following:

Use ‘with (nolock)’ as much as possible to prevent locking issues where you can.

Modify the scripts that maintain this data to use ‘begin tran’ type transactions as little as possible.

Modify the execution of the scripts that maintain the data so they are more likely to be called sequentially than concurrently. e.g. put them in the same job.