Good database design, variable number of attributes

后端 未结 4 1984
借酒劲吻你
借酒劲吻你 2021-02-04 10:16

I\'m trying to create a database that contains a list of equipment. All of the equipment will have certain common attributes (such as manufacturer, model #, serial #, etc.), the

4条回答
  •  -上瘾入骨i
    2021-02-04 11:13

    Options 1, 2, and 3 share one very serious flaw: you have to modify the underlying table schema when someone dreams up a new attribute. In the case of Option 1 the problem is compounded by the possibility that a new equipment type will be introduced. How sure are you that the set of attributes is fixed for all time? How happy will you be to take outages or tell the client that no, you can't have a new attribute?

    If you are very likely to do queries off common attributes, you might try a hybrid of 3 and 4, with a dash of 2 thrown in splitting on attribute type rather than equipment type, which seems much more volatile. Option 4, if I understand correctly, is a normal form version of option 1 which solves all its inherent problems (sparseness and brittleness).

    INVENTORY( id*, model, manufacturer, serial )
    ATTRIBUTE( id*, name, type, description )
    INVENTORY_FACT_STRING( inv_id*, attr_id*, value )
    INVENTORY_FACT_NUMBER( inv_id*, attr_id*, value )
    INVENTORY_FACT_LIST_STRING( inv_id*, attr_id*, ordinal*, value )
    

    etc.

提交回复
热议问题