Les options 1, 2 et 3 partagent un défaut très sérieux :vous devez modifier le schéma sous-jacent de la table lorsque quelqu'un imagine un nouvel attribut. Dans le cas de l'option 1, le problème est aggravé par la possibilité qu'un nouveau type d'équipement soit introduit. Dans quelle mesure êtes-vous sûr que l'ensemble d'attributs est fixé pour toujours ? Serez-vous heureux de prendre des pannes ou de dire au client que non, vous ne pouvez pas avoir un nouvel attribut ?
Si vous êtes très susceptible de faire des requêtes sur des attributs communs, vous pouvez essayer un hybride de 3 et 4, avec un tiret de 2 lancé en fractionnant le type d'attribut plutôt que le type d'équipement, ce qui semble beaucoup plus volatil. L'option 4, si je comprends bien, est une version sous forme normale de l'option 1 qui résout tous ses problèmes inhérents (paresse et fragilité).
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.
