Discussion :

[CsJoe]

Bonjour,

Je me heurte à un problème que je pouvais résoudre jusqu'ici par programmation, mais dans le cadre d'une procédure un peu complexe je me demande si mes choix étaient bons.

En simplifiant disons que j'ai une table "achats" dans laquelle je regroupe un type d'objet avec un objet. Les objets de chaque type ont des propriétés différentes c'est la raison pour laquelle j'ai choisi de les gérer dans des tables distinctes. Pour obtenir une liste précise des achats je suis donc obligé de faire une première requetes pour récupérer tous les achats, puis de boucler sur le résultat pour trouver la table à interroger pour obtenir le nom de l'objet.

Je procédais ainsi à défaut de mieux. Mais j'ai besoin de savoir, à cause de nouvelles contraintes, s'il est possible avec MySQL que le nom d'une table dans une jointure soit dynamique pour chaque ligne. Autrement dit je voudrais que dans la requête suivante "table_dynamique" prenne comme valeur "objet_type1"/"objet_type2" ... en fonction de achats.typeid :

Code sql :

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

1
2
3
4
SELECT achats.*, types.nom , table_dynamique.nom 
FROM achats 
INNER JOIN types ON types.id = achats.typeid 
INNER JOIN table_dynamique ON table_dynamique.id = achats.objetid

Voici mes tables simplifiées :

Code sql :

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
CREATE TABLE IF NOT EXISTS `achats` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `typeid` int(10) unsigned default NULL,
  `objetid` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`id`),
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
CREATE TABLE IF NOT EXISTS `types` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `nom` varchar(20) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
CREATE TABLE IF NOT EXISTS `objet_type1` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `nom` varchar(100) collate utf8_unicode_ci NOT NULL,
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
CREATE TABLE IF NOT EXISTS `objet_type2` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `nom` varchar(100) collate utf8_unicode_ci NOT NULL,
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Merci.

[Zwiter]

Salut,
Ceci serait possible avec une fonction.

Pour revenir a ton histoire de type d'objet et de table, je pense qu'on devrait pouvoir normaliser tout cela : Je pense que tu ne devrais pas etre obligé de recourir a une telle astuce.

Je te propose :
achats (achat_id, objet_id)
objets (objet_id, type_id, objet_nom)
types (type_id, type_nom)

Ainsi :
achat_id -> objet_id, objet_nom
objet_id -> type_id, type_nom
objet_nom -> objet_id
type_id -> type_nom
type_nom -> type_id

Traduction :
A un achat correspond un ou plusieurs objet.
A un type correspond plusieurs objets.
Un objet correspond à un seul type.

Ceci correspond a une normalisation : la 3eme forme normale (3FN).

Z.

[CsJoe]

Merci pour ta réponse Zwiter.

Les objets de chaque type ont des propriétés différentes, ce qui se traduit par une table par type avec un nombre de champs différents. C'est la raison pour laquelle j'ai pensé qu'il valait mieux avoir des tables d'objets distinctes : c'est plus clair dans le code car je n'ai pas à mettre des NULL sur les champs à ignorer, et j'imagine que cela a un impact sur les performances de la base de données.

Ainsi je ne peux pas "normaliser" la situation car tous les objets devraient être dans une même table. Cependant j'avais sous-estimé la complexité que cela constituerait de rassembler les données lors de certaines situations.

Une "normalisation" est elle possible en tenant compte de la contrainte d'avoir plusieurs tables différentes pour les objets?

[Zwiter]

De nouvelles tables types pourront-elles voir le jour ?

Autrement, je sais que sous oracle et postgres, tu peux créer des nouveaux types (create type) qui resoudraient ton souci.

Autrement, en normalisant ce que j'ai compris de ton texte :
Si a un objet ne correspond qu'un seul type, et une propriété du type ne correspond qu'a un seul type :
type_properties(type_id, property_name)
type_def(type_id, type_name)
objet(objet_id, type_id, objet_name)

Si c'est pas ce que j'ai décrit, essais de mettre pas ecrit avec des phrases comme je l'ai fait en utilisant la syntaxe : A un <table 1> correspond [zero][un][plusieur][zero ou plusieur][zero ou un][un ou plusieur] <table 2>
(du genre : A un objet correspond un seul type. A un achat correspond un ou plusieurs objet)

Z.

[CsJoe]

De nouveaux types en effet pourraient voir le jour.

Ce que tu as écrit correspond à la description de mon problème. Mais cela poserait un autre problème si je suis bien : je ne pourrais plus obtenir ma liste d'achat en n'ayant qu'un seul résultat pour chaque objet qui de plus contiendrait toutes les propriétés de cet objet en fonction de son type? Car dans ce cas la jointure devrait parcourir la table des propriétés, ce qui retournera plus d'un résultat par objet.

[Zwiter]

tu pourrais :
Concatener les proprieter ? (http://www.developpez.net/forums/d58...iale-possible/)
Les traiter via php avant affichage ?
le faire en 2 requetes ? une pour les objets de l'achat, puis une pour les propriétés de chaque type d'objet.
Changer de sgbd pour postgres ?

Derniere solution, la plus moche, serialiser tes propriétés en 1 seul attribut, si tu ne compte pas faire de requete sur les propriétés.

Z.

[CsJoe]

Ah mais je vois que tu t'es déjà heurté au même genre de problème :-)
En fait on en revient à ça : est-il possible de faire faire à la base de données quelque chose que je fais par programmation parce que je ne sais pas s'il est possible de faire autrement.

Je ne sais pas encore si j'ai un problème de conception ou si cela ne peut tout simplement pas être résolu autrement que par programmation. D'après ce que j'ai compris tu as choisi cette voie.

[Zwiter]

J'ai réussi à faire cette requette, mais elle est assez lourde si il y a beaucoup de proprieter pour un type, mais je ne me souvient plus trop du code.
Je vais essayer de la refaire.
Z.

[Zwiter]

J'ai retrouvé le principe de ma requete, mais le souci est que j'avais des propriétés fixent. Tandis que les tiennent evolueront.
La solution la plus simple, et aussi la meilleur a mes yeux, serait donc de recuperer toutes les infos via des jointures, puis de faire un petit script php pour trier les propriétés.

Z.

[CsJoe]

Finalement je vais donc poursuivre sur la voie que j'avais prise, à savoir reconstituer les données par programmation. C'est peut-être un problème insoluble en SQL uniquement.
Merci pour ton aide Zwiter.