COMMON DATA MODELING PROBLEMS - A Developer's Guide to Data Modeling for SQL Server - page 177

F IGURE 8.6 A poor product entity design, supporting different attributes for
different products
How do you store the different attributes of the instruments without
making your database look like an overgrown Excel spreadsheet? There
are a few options. You could make a different entity for each type of in-
strument, but this solution would be very inflexible. If the company de-
cides to carry a new type of instrument, you would need to add new
entities; if it decides to track something else about an instrument, you
would need to add attributes to an entity. To solve this problem for
Mountain View, we add another entity called Product Attributes, as shown
in Figure 8.7.
Setting up a two-table solution builds flexibility into the design and al-
lows for a more optimal use of storage. In this example, all the product at-
tributes are records of the Product Attributes entity, and anything that is
common to all products is stored in the Products entity. Using this model,
we can add products and product entities at will. However, more important
than the added flexibility, we got rid of that repeating attribute monstrosity.