Discussion :

[bqyben]

Bonjour!

Merci pour l’intérêt que vous avez porté à mon problème, une fois résolue je ne suis pas revenu sur le topic..

Effectivement après mûre réflexion, notamment sur la nécessité de mes quartes table enfant et des valeurs qu'elles étaient censé contenir j'ai opté pour un modèle proche de celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
[ Appel ]--1,1----( )----0,n->[ Type_Appel ]
    ^
    |
    +--0,1----(est_un)----1,1--[ Problème ]
    |
    +--0,1----(est_un)----1,1--[ Information ]
    |
    +--0,1----(est_un)----1,1--[ Installation ]
    |
    +--0,1----(est_un)----1,1--[ Enlèvement ]

Proposé par Jphi, à la différence que j'ai fini par regrouper ces 4 tables en une seule "générique" qui va contenir mes valeurs (sans les nommer)..

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[ Appel ]--1,1----( )----0,n->[ Type_Appel ]
    ^
    |
    +--0,1----(possède)----1,1--[ Valeur ]

La raison est que peu importe le type d'appel, la majorité des informations nécessaires sont contenues dans la "Appel" et pour les autres, en fonction du type, elles vont de 1 à 3 valeurs..

au final : Ma jointure est unique (entre "Appel" et "Valeur" sur id_appel) et l'exploitation du résultat dépend de "type_appel".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
CREATE TABLE type_appel(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
type_libelle VARCHAR(45),
type_description VARCHAR(150))ENGINE=INNODB;

CREATE TABLE appel(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
appel_date DATE,
appel_heure TIME,
appelant VARCHAR(45),
cloture_date DATE,
cloture_heure TIME,
appel_prio INT,
appel_mag CHAR(4),
appel_type INT,
appel_motif INT,
appel_operateur INT,
FOREIGN KEY(appel_mag) REFERENCES magasin(matricule),
FOREIGN KEY(appel_type) REFERENCES type_appel(id),
FOREIGN KEY(appel_motif) REFERENCES motif(id),
FOREIGN KEY(appel_operateur) REFERENCES operateur(id))ENGINE=INNODB;

CREATE TABLE valeur_appel(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
id_appel INT,
val1 VARCHAR(150),
val2 VARCHAR(100),
val3 VARCHAR(50),
FOREIGN KEY(id_appel) REFERENCES appel(id))ENGINE=INNODB;

Que pensez vous d'un tel type de structure ? niveau développement, je présenterai donc mes données de "Valeur" en fonction du type de l'appel, cela dérange quelque peu, je n'ai jamais essayé le générique sur de la base de donnée, ne sait pas ce que ça vaut non plus, je suis pas loin de le découvrir..

Quoiqu'il en soit, Ben a du avancer dans son développement et tombera, sans doute, devant un "mur de conception", s'il existe. A partir de ce moment là, Ben ne devra surtout pas essayer de contourner ce mur par du code ou des suites de requêtes alambiquées !... Il devra retourner côté "conception" et reformuler ses règles de gestion, sinon Ben s'aventurera dans des contrées dangereuses...

Contrèes dangereuses... ME VOILA !

[CinePhil]

La raison est que peu importe le type d'appel, la majorité des informations nécessaires sont contenues dans la "Appel" et pour les autres, en fonction du type, elles vont de 1 à 3 valeurs..

Autrement dit, tu as la règle de gestion suivante :
Un appel peut avoir jusqu'à 3 valeurs supplémentaires et une valeur ne concerne qu'un seul appel.

Ce qui donne le MCD suivant :
Appel -0,3----avoir----1,1- valeur

Et la table valeur devrait avoir la structure suivante :
valeur (val_id, val_id_appel, val_valeur)

Chaque appel aura de 0 à 3 lignes correspondantes dans la table valeur.

En toute rigueur, pour empêcher l'insertion d'une quatrième valeur pour un appel, si ça ne doit jamais arriver, il faudrait un trigger avant insertion qui compte le nombre de valeurs déjà enregistrées pour l'appel et annule l'insertion s'il y en a déjà 3.

[bqyben]

Très bien

Ce qui donne le MCD suivant :
Appel -0,3----avoir----1,1- valeur

Et la table valeur devrait avoir la structure suivante :
valeur (val_id, val_id_appel, val_valeur)

Ne m'y connaissant absolument pas(encore) en ressource utilisé par les BDD je me suis dit naturellement qu'une ligne avec des champs potentiellement vides couteraient toujours moins de ressources qu'une ligne par valeur même si je préférai l'idée.
Je pense que je vais l'appliquer, sinon dans le principe, c'est une solution envisageable/propre ?

[CinePhil]

Il faut éviter le bonhomme NULL dans les BDD.
Le SGBD réserve de la place, même pour des valeurs vides.
Au final tu perds de la place et le SGBD devient moins performant.