オプション1、2、および3には、非常に重大な欠陥が1つあります。誰かが新しい属性を思いついたときに、基になるテーブルスキーマを変更する必要があります。オプション1の場合、新しい機器タイプが導入される可能性があるため、問題はさらに複雑になります。属性のセットが常に固定されていることをどの程度確信していますか？停止したり、クライアントに「いいえ、新しい属性を設定することはできません」と言って、どれほど幸せになりますか？
一般的な属性からクエリを実行する可能性が非常に高い場合は、3と4のハイブリッドを試してみてください。機器タイプではなく、属性タイプに分割して2のダッシュをスローします。これは、はるかに不安定に見えます。オプション4は、私が正しく理解していれば、オプション1の正規形バージョンであり、固有のすべての問題（まばらさおよび脆弱性）を解決します。
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 )
など