Question

I have a table with a large number of very specific columns which are mostly “Strings”. I believe this hardcoding of names will give me grief later on when rules changes. I am investigating the option of using a second table where each row is a column from the master table which could each have a lookup key for its name.

I know this may seem anti ER best practice, but it would be flexible. I could use views with subselects ie Select (SQL1), (SQL2) etc from Table1. Not sure if one can update a multitable view though in SQLServer.

Thoughts on the above greatly appreciated.

Thanks,

Ed

Answer 1

It sounds like what you’re looking for is something like an Entity-Attribute-Value (EAV) table.

EAV allows for a much more dynamic process when it comes to being flexible with regards to allowing further customization down the line, but poor implementation can mean that it doesn’t adhere well to the relational model. This SO question provides a good rundown of some of the issues inherent with that kind of solution.

You’d probably be better off refactoring your columns to use a less context-specific naming convention.