What do you do with a one-off piece of data that needs to be persisted?

Recently I've been requested to add on something for the administrator of a site where he can 'feature' something.

For this discussion let's say it's a 'featured article'.

So naturally we already have a database model of 'articles' and it has ~20 columns as it is so I really do not feel like bloating it anymore than it already is.

My options:

1. Tack on a 'featured' bool (or int) and realize that only one thing will be featured at any given time

2. Create a new model to hold this and any other feature-creep items that might pop up.

3. I take your suggestions! ;)

What do you guys do in this instance? I come across this every now and then and I just hate having to tack on one more column to something. This information DOES need to be persisted.

From stackoverflow

• You could use an extensible model like having a table of attributes, and then a linking table to form a many-to-many relationship between articles and attributes. This way, these sorts of features do not require the schema to be modified.

• I'd probably just add a simple two-column table that's basically a key-value store. Then add a new column with values like (featured_article_id, 45) or whatever the first featured ID is.

  Edit: as pointed out in the comments by rmeador, it should be noted that this is only a good solution as long as things stay relatively simple. If you need to store more complex data, consider figuring out a more flexible solution.

  rmeador : I'd also take this approach, with the understanding that as soon as this "feature" grows to encompass more functionality, you will need to refactor to create a full solution. +1

• If only one article can be featured at a time it is a waste to add a bool column. You should go up a level and add a column for the FeaturedArticleID. Do you have a Site_Settings table?

  feydr : yeh... I was thinking about doing this just cause I see more stuff like this in the future happening....

• Have some kind of global_settings table with a parameter_name and parameter_value columns. Put featured article id here.

• For quick-and-dirty stuff like this, I like to include some sort of Settings table:

  CREATE TABLE Settings (
      SettingName NVARCHAR(250) NOT NULL,
      SettingValue NVARCHAR(250)
  )
  

  If you need per-user or per-customer settings, instead of global ones, you could add a column to identify it to that specific user/customer. Then, you could just add a row for "FeaturedArticle" and parse the ID from a string. It's not super optimized, but plaintext is very flexible, which sounds like exactly what you need.