Structure de bdd, propriétés d'un élément avec types différents

Bonjour

J'ai besoin d'associer des caractéristiques à des appareils et j'ai un soucis de type de champ
Ci joint une structure pour illustrer mes propos

une table "appareils" définie les appareils, RAS
chaque appareil a un type (voiture, perceuse...)
quand on crée un appareil on va voir la table "CaracteristiquesParDefaut" et on rempli la table "Caracteristiques" avec toutes les caractéristiques par défaut de l'appareil qui vient d’être créé.

pour une voiture on va ainsi ajouter les caractéristiques "couleur", "modèle", "masse","nombre de places"...
pour la perceuse on ajoutera par défaut les caractéristiques "diamètre max", diamètre min", "Oui/non sans fil"...

cela nous donne les caractéristiques par défaut que l'utilisateur doit saisir à minima mais on peut ainsi ajouter des caractéristiques propres à un unique appareil : l'IDappareil 536, de type voiture aura par exemple une caractéristique "nom du propriétaire célèbre"

Jusque là c'est très clair pour moi, j'espère que ça l'est pour vous aussi ;)

Mon soucis est que toutes ces caractéristiques ne sont pas toutes du même type (du texte, des nombre entiers, des flottants, des booléens...) et que en fonction de ce type on ne peut pas définir les même limites (valeur max, valeur min..) que j'aimerais pourtant pouvoir définir dans ma base pour mettre en place des tests de validité au moment de la saisie par l'utilisateur.

Comment peut on gérer une liste ouvert de propriétés comme je le montre ici mais en gérant différents type de propriétés ?

Merci par avance

Je ne comprends pas votre souci, même pour des articles homogènes, vous pouvez avoir des valeurs mini et maxi différentes.

Par exemple, 2 perceuses de modèle différents, ont des mandrins de capacité différentes et du coup des diamètres de perçage mini et maxi différents

Il est donc illusoire de stocker en table des maxi-mini valables pour l'ensemble des articles d'un même type

Bonjour

Bon ben je n'ai pas réussi à m'expliquer :(

je recommence

Dans mon exemple la table "Caractéristiques" contient bien les caractéristiques d'un et un seul appareil ; la perceuse 2 aura un mandrin diametre maxi =13, la perceuse 569 aura un diamètre mandrin maxi =22.

Mon soucis est que dans cette table je voudrais associer à un 1 appareil n caractéristiques qui ne sont pas du même type.
par exemple :
IDcaracteristiques; IDappareil;NomCaracterstique;ValeurCaractéristique
1;1;diamètre max; un flottant
2;1;date achat; une date
3;1;modele; un texte
4;2;nombre de pôles ; un entier
5;2;référence ; un texte

Comment gérer ce type différent du champ "ValeurCaractéritique" ?

en espérant être plus clair :roll:

merci

Tu as trois possibilités :

• Une seule colonne de type VARCHAR, utilisée pour stocker toutes les valeurs.
  Une conversion sera nécessaire pour utiliser les valeurs.
• Une colonne de chaque type.
  Une seule colonne sera renseignée à chaque ligne (table creuse)
• Une série de tables liées, chacune comportant l'identifiant de la ligne et une colonne pour la valeur, avec un type par table.
  Il n'y a pas plus de lignes que nécessaire, mais il faut gérer les relations.

Bonjour et merci

J'avais plus ou moins imaginé ces 3 solutions mais elles sont tellement opposées que je cherche à éclaircir.

La solution 2 (un champ par type) je l'avais éliminé car trop grossier au niveau des données mais là en la revoyant présentée ainsi je me dis "oui mais si ça se trouve en terme de perf il y a moins à faire...?"
La première je l'ai identifiée comme la plus compliquée à gérer et la moins performante à cause des conversions, conversions à faire aussi sur les limites (valeur max et min)
La troisième solution c'est peut être celle là sur laquelle j’espérais un miracle de bonne pratique puissante et simple grasse à une méthodo inconnue (de moi) !

donc avec la solution 3 quand on veut afficher les propriétés d'un appareil il faut aller chercher une par une les propriétés dans chacune des tables.


pour les type vous prendriez quoi pour ne pas être coincé après ?
DATE
INTEGER
DOBLE PRECISION
BOOLEAN
VARCHAR(taille a définir)

Je gère tout avec ces types là ?

PS : .unaise ça complique de ne plus avoir que des caractéristiques définies de base dans la table "appareils " !

Merci

Bonjour,

Un article a lire : http://sqlpro.developpez.com/cours/m...etadonnees/#L2

Attention, un tel type est forcément moins performant qu'un modèle "classique", mais en fonction de vos contraintes, de votre volumétries, ça peut néanmoins le faire.

Une alternative serait d'utiliser une seule colonne de type XML :
- Vous pouvez définir des contraintes si vous typez votre XML
- Vous pouvez indexer pour les performances

Bonjour

merci pour ce lien, je l'ai parcouru en diagonale et il semble que ce soit le truc miraculeux que j'espérais à peine trouver en posant ma question !
Mon appli aura des volumes de donnée très faibles, la performance est très secondaire, d'autant que l'auteur semble dire que ce n'est pas si lent que ça.

Je vais me faire quelques crampes au cerveau pour comprendre tout ceci mais je crois bien que c'est le top pour moi !

Merci beaucoup