Reprise du message précédent :
Plus je réfléchis à ton machin, et plus je me dis qu'avec une telle structure c'est peine perdue... Là je vois pas du tout comment tu peux faire...
A la limite en haut niveau (PS ou code PHP). Et même là tu vas en chier un max...

T'ain, ça y est, je crois que je viens de comprendre le coup du "CmpKeyWordsComponents". Vous avez rien trouvé de plus tordu ?
 
Vas-y la galère pour remplir la base, faut tout que je recommence mes données de test de A à Z
 
Ca bien un varchar le "CmpKeyWordID" ?
(ou du moins, il pointe vers une table de référence qui contient une liste de mots clés, c'est bien ça ?)
 
Si c'est bien ce que je crois, cette table devrait franchement être partagé (car il y a des doublons pour toutes les configs ou presque) plutôt que les attributs où c'est une horreur...
 
Monsieur Roche, sortez de ce corps !

Putain c'est vraiment la merde ton truc.
 
Ca doit faire deux heures que j'essaie de me constituer une base de tests, et là je m'apperçois que c'est pas possible de dupliquer une config sans faire une usine à gaz

En fait, y'a pas que "CmpKeyWordsComponents" qui devrait être partagée, mais aussi "Components"...
 
A la base "tous" les PC ont des disques, des cartes graphiques, etc.
Donc il devrait y avoir une table qui énumère les composants possible, plus une table qui fait la liaison avec la table configuration.
 
Là le modèle est purement incomplet, c'est une usine à gaz de travailler dedans

/me pète les plombs
 
fait être obligé de faire un script T-SQL pour réussir à dupliquer ces putains de configs

Bon, c'est trop la merde, je capitule. Je vais faire mes requêtes avec mes deux configuration saisies à la main (à raison d'une trentaine d'attributs pour chaque, hors de question que je m'en repaluche d'autres à la main )

Bon, je dois rien piger au modèle des données... Le coup du CmpKeyWordsComponents me laisse sceptique... A cause de l'interprétation que j'en ai, faut faire une usine à gaz dès que je fait un truc.
 
Genre je dis que le ComponendID 1 est CPU1 et le ComponentID 2 est le CPU2. Pour améliorer les critères de recherche, je dis qu'ils sont aussi tous les deux CPU.
 
Résultat, vas-y la requête pour avoir la liste des CPU de mes configs sans doublon et avec un semblant de tri...
Genre faut que je connaisse la liste des mots-clés génériques afin de les exclure des filtres, le truc impossible à la base.
La copie est à revoir complètement au niveau de la table Components à mon avis. C'est total n'importe quoi, et je comprends mieux pourquoi tu ne t'en sors pas !
 

Bon, allez, moi je capitule. C'est trop la merde pour pouvoir faire quoi que ce soit. A la moindre jointure, on se heurte à des conneries liées au modèle des données de conception aussi étrange qu'erronée.
 
Alors vu qu'à la base ton problème est particulièrement complexe, je ne vois pas du tout comment réussir à obtenir un résultat cohérent...

En tout cas, t'iras pas dire que je me suis pas cassé le cul à tenter de t'adider, j'y ai quand même passé plus de 2h30 ce soir

Salut MagicBuzz. Bon, je vois avec plaisir que t'a repris du poil de la bête et que tu vas mieux
 
Alors déjà, le modèle de données, c'est moi qui l'ai pondu et le produit sur lequel je travaille est fait maison. Pourquoi un tel modèle tordu? A la base, les futurs utilisateurs de l'outil de gestion de conf étaient partis sur un truc existant : Advitium. Le tout était que la boîte qui l'avait développé devait le modifier un peu pour le faire rentrer dans les besoins des utilisateurs (plus précisemment, le groupe de travail qui bossait sur les specs). A la fin, ils se sont retrouvés avec un gros bouzin qu'avance pas, avec une table pour chaque composant et un nombre de champs limités (issu d'un recensement le plus exhaustif possible). Or chaque calculateur a une conf bien particulière (les calculos sont des Bull, des HP, des PC et on a mêmes des Data General!) dont on cherche à tracer les évolutions au fur et à mesure que les versions de produits applicatifs installés évolus. Au final, pour une conf donnée, on se retrouvait avec pleins de champs qui ne servaient à rien (sauf pour la conf qui en avait besoin). Autre problème : impossible de faire évoluer les champs et les composants facilement Enfin, il fallait que l'ordre d'affichage des composants d'une conf se face dans un ordre prédéterminé mais qu'on puisse changer à tout moment. Et un autre point qui n'est pas des moindre : le groupe de travail est incapable de se mettre d'accord sur les composants/attributs qu'on doit mettre en conf (bien qu'on ait tous eu une formation ITIL)... Il fallait donc que je mette aupoint un outil qui soit le plus souple possible et le plus évolutif. Par ailleurs, ils ont mis 4 ans avant d'avoir Advitium et ils l'ont mis à la poubelle car trop lent et trop compliqué. On m'a laissé 4 mois pour faire un truc équivalent mais sans les inconvénients...Alors j'essaye de faire au mieux (oui, je suis tout seul pour faire tout de A à Z)
 
A la vue de tout ça, je me suis dit que plutôt que de gérer une arborescence de composants au sens strict du terme (un composant à un ou plusieurs composants enfants) car je sentais bien déjà que les requêtes pour récupérer une conf et effectuer une comparaison seraient très compliquées, je me suis dit :
- les composants, on va les voir comme de simples collections d'attributs
- pour pas compliquer les choses, un composant n'appartient qu'à une seule conf, comme ça si je modifie la composition d'un composant d'une conf particuière, je ne vais pas impacter les autres confs qui partageraient le même composant
- pour savoir à quoi sert tel composant, je lui associe un mot ou plusieurs mots-clés. Dans la pratique, on se limite à un seul (mais j'ai prévus plus large mon modèle, c'est la table CmpKeyWordsComponents qui fait le lien entre les composants et les mots-clés). Pour faire le // avec la POO, chaque mot-clé serait une Classe et les composants qui sont associés à ce mot-clé seraient des instances de cette classe.
- pour "émuler" la structure arborescente des composants, j'ai structuré la table des mots-clés sous la forme d'une arborescence, elle.
ex : pour faire le composant "Carte réseau Ethernet", j'ai dans ma table CmpKeyWords :
CmpKeyWordID | CmpKeyWordValue | CmpKeyWordParentID
---------------+------------------+---------------------
   1                          Carte                      Null
   2                          Réseau                   1
   3                          Ethernet                 2
--------------------------------------------------------
 
- je me suis dit aussi qu'un certains nb attributs identiques seraient partagés par plusieurs confs, d'où le fait qu'ils ne sont pas dupliqués dans la table Attributes. Un attribut peut donc appartenir à 1 ou plusieurs composants.
- la table ComponentsAttributes sert à faire le lien entre les composants et leurs attributs. Et pour répondre à ta question, oui, une conf peut avoir plusieurs instances du même mot-clés ce qui va se traduire dans la base par 2 ID de composants différents dans la table Components, mais dans la table ComponentsAttributes, ces 2 ID de composants seront liés aux même attributs.
- Maintenant, la table Attributes. Elle a un AttributeID (entier), un AttributeName (chaîne), un AttributeValue (chaîne), un AttributeType (entier, 0 ou 1 pour l'instant) et un AttributeCompareType (entier, 0 ou 1 aussi pour l'instant).
ex : Marque = AMD ("Marque" est le nom de l'attribut et "AMD" sa valeur
AttributeType indique la nature de l'attribut : 0 -> donnée simple (chaîne toute bête), 1 -> nom de fichier (chaîne aussi, mais pour les infos complémentaires, faudra aller chercher dans une autre table qui n'existe pas à l'heure actuelle).
AttributeCompareType indique la pertinence de l'attribut lors de la comparaison. En effet, les utilisateurs ne veulent pas avoir le résultat de la comparaison pollué avec des attributs qu'on sait pertinament qu'ils vont être différents
ex : @IP = 192.xxx.xxx.xxx Elle est forcémenent différente d'une conf à l'autre. Cet attribut sera donc nom pertinent (=> 0)
 
Et crois moi que les confs qu'on va mettre dans mon outil n'ont rien de commun avec des confs de PC bureautique. On va y trouver certains paramétres du noyau, des patchs, des paramétrages de jumpers de cartes mères, des cartes watchdog, des KVM, etc.
 
Maintenant, faire la comparaison via PHP, j'y ai pensé, mais j'ai peur que ce soit trop long. Avec mes 3 requêtes, je pense ne pas être trop loin du résultat final. Et comme tu le disais toi même, le SQL c'est simple, il siffit de formuler sa question en français et de la traduire en SQL etd ans 99% des cas, on a la requête optimale
 
En tout cas, je te remercie beaucoup pour avoir passé autant de temps sur mon pb . Pour le jeu de donné, je peux t'envoyer ma base de test par e-mail (200 ko) : 15 confs et je te dis pour 2 couples de confs le résultat attendu (les attributs/composants que tu dois trouver. Ca te va?

je me suis arrêté au milieu.
 
je ne remet pas en cause l'idée de base, à savoir modulatiser au maximum et rendre le modèle générique.
 
mais là, y'a des relations pour le moins étrange, et totalement fausses d'un point de vue analyse.
 
là je dois bosser sur un truc, je devrais avoir terminé dans l'après-midi. si tu veux, je regarderai comment améliorer ton machin. mais ça va t'obliger à tout péter
 
toujours est-t-il qu'actuellement, mise à part si ton explication que tu me fait me permette de comprendre une erreur que j'ai commis hier soir, je ne vois pas du tout comment t'en sortir. je ne comprend même pas comment tu arrives à comparer deux attributs d'une même configuration.

 
tu peux toujours me proposer une autre structure, mais vu que j'ai quasi fini l'appli dans sa V1, je ne vais pas pouvoir la mettre en oeuvre. Par contre, ça me permettra de voir une autre façon de faire et ça me fera progresser.  
 
Par contre, il n'est pas question de comparer des attributs d'une même conf. Il est question de comparer les attributs de 2 confs.
 
Dans mon explicaton, j'ai oublié de t'éclaircir sur le rôle de ConfigurationVersion, ConfigurationInternalVersion et ConfigurationDate.
ConfigurationVersion est une chaîne qui contient le "nom" de la version de la conf. C'est en qq sorte une version de communication qui correspond à qq chose dans le monde réelle.
ConfigurationInternalVersion est un entier (1 à n) qui contient la version de la conf mais interne à l'appli histoire qu'elle s'y retrouve : telle conf est la suivante de telle autre. Ce n° est incrémenté quand on modifie une conf existante d'une "famille" (cf le ConfigurationParentID). La première conf d'une "famille" a ConfigurationInternalVersion = 1 et ConfigurationParentID = NULL. Si je veut modifier le contenu de cette conf, j'en crée une nouvelle qui a alors ConfigurationInternalVersion = 2 et ConfigurationParentID = l'ID de la conf mentionnée précédemment.
ConfigurationDate est la date et l'heure à la quelle la nouvelle conf créée a été figée (plus possible de la modifier et elle devient visible pour les autres utilisateurs).
 
un ex : j'ai un calculateur qui se trouvait y'a 1 mois dans la conf ayant comme version "1002-3.5" (version interne = 1). Depuis, il est passé dans la conf ayant comme version "1002-4" (version interne = 2). Je veux savoir les différences qu'il y a entre ces 2 confs : les composants/attributs en +, en - et les valeurs qui ont été modifiées.
 
Pour les +, on cherche  :
- d'une part, les composants de la conf 2 qui sont liés à des mots-clés qui ne font pas partis des mots-clés liés aux composants de la conf 1
- d'autre part, les composants de la conf 2 qui sont liés aux mêmes mots-clés des composants de la conf 1 et dont la conf 2 a des attributs qui ne font pas partis des attributs de la conf 1. Autre condition dans ce cas là : si un mot-clé de composant apparaît plusieurs fois dans l'une ou l'autre ou les 2 confs (=> plusieurs instances du même type de composant), il faut compter le nombre d'instances de ce mot-clé dans chacune des 2 confs :  
         * si le nb est identique, on compare l'instance n°1 de la conf 2 avec l'instance n°1 de la conf 1, l'instance n°2 de la conf 2 avec l'instance n°2 de la conf 1...
        * si le nb dans la conf 2 est > à celui de la conf 1, on considère que les instances de la conf 2 > au nb sont des composants en +
 
Pour les -, c'est la même requête a priori que la précédente, sauf qu'on inverse la position de conf 1 et conf 2 dans la requête. Par rapport à ce qui est écrit précédemment conf 1 devient conf 2 et conf 2 devient conf 1
 
Pour les attributs de valeurs <>, on cherche les composants de la conf 2 qui sont liés aux mêmes mots-clés des composants de la conf 1 et dont les attributs de la conf 2 ont le même nom que les atttributs de la conf 1 mais dont leur valeur sont différentes. Autre condition dans ce cas là : si un mot-clé de composant apparaît plusieurs fois dans l'une ou l'autre ou les 2 confs (=> plusieurs instances du même type de composant), il faut compter le nombre d'instances de ce mot-clé dans chacune des 2 confs :  
         * si le nb est identique, on compare les attributs de même nom de l'instance n°1 de la conf 2 avec ceux de l'instance n°1 de la conf 1, ceux de même nom de l'instance n°2 de la conf 2 avec ceux l'instance n°2 de la conf 1...
        * si le nb dans la conf 2 est > à celui de la conf 1, on ne compare que les attributs de même nom des instances de conf 2 <= au nb d'instances de conf 1.

Je me rends bin compte que ce que j'ai appelé "autre condition" est assez complexe pour que tout puisse se faire en 1 requête.
On peut très bien faire 3 requêtes qui ne traitent que les composants dont le mot-clé n'apparaît qu'une seule fois dans chacune des 2 confs et en faire 3 autres qui gèrent le cas où le mot-clé apparaît plusieurs fois.
 
Je pense que je ferai aussi un test avec une comparaison faite par un script php qui charge les 2 confs.
 
Je pourrais aussi faire un mix des 2 : les comparaisons les plus simple avec SQL et les compsraisons les plus complexes avec php...

Ca me va moyennement : en fait, j'ai que SQL Server sur mon serveur, et je préfèrerais ne pas rajouter MySQL (j'ai besoin de mon serveur pour le boulot, donc je préfère éviter de tout péter malencontreusement).
Par contre, MySQL permet de faire des export au format SQL (create table et insert). Ca je veux bien, ça je pourrai jouer le script sur ma base de test
 
Mon mon email, regarde le lien sur "MagicBuzz" en bas de mon site perso.
 
Si avec tes données c'est mon bordelique qu'avec les miennes, je veux bien tenter de regarder de nouveau ce soir.

 
ben c'était de l'export SQL dont je parlais qui fait 200 ko... je te file ça au plus vite.

Bon, je t'ai envoyé mon jeu de test.
 
Voici un premier exemple de résultat de comparaison (ce que je veux avoir en résultat). D'abord le contenu des 2 confs
La conf ayant pour ID 1
Composant ID = 1
Attribute ID = 1 (Nb CPU)
Attribute ID = 2 (type CPU)
Attribute ID = 7 (Type Ram)
 
Composant ID = 6
Attribute ID = 8 (Nom lecteur)
 
Composant ID = 7
Attribute ID = 9 (Nom lecteur), attribut non pertinent
 
Composant ID = 8
Attribute ID = 10 (nom OS)
 
Composant ID = 9
Attribute ID = 11 (nom graphique)
 
Composant ID = 23
Attribute ID = 17 (vitesse lecture)
Attribute ID = 18 (Marque)
Attribute ID = 19 (Interface)
 
La conf ayant pour ID 7
Composant ID = 21
Attribute ID = 15 (Modèle CPU)
Attribute ID = 1 (Nb CPU)
Attribute ID = 3 (Type CPU)
 
Composant ID = 22
Attribute ID = 6 (capacite disque)
Attribute ID = 16 (nom disque)
 
Composant ID = 248
Attribute ID = 315 (port)
 
ps : entre (), j'ai mis le AttributeName de chaque attribut
 
Ce qu'il faut avoir en sortie quand on compare conf 7 à conf 1 (conf 1 étant la référence de comparaison), c'est :

 
Evidemment, ce résultat va être une concaténation par PHP du résultat des 3 requêtes SQL (voire peut-être plus). De toute manière, la mise en forme du résultat n'est pas un tableau mais une arborescence (la même représentation qu'une conf mais avec seulement les compsoants impactés par les différences).

Sinon, moi j'ai deux modèles des données à te proposer.
 
Le classique :
 
configuration (id, nom, nomcom, datcre, parent) -- mêmes champs que les tiens, mais renommés
composant (id, nom, parent) -- fk parent = id afin de faire des variantes; nom permet d'identifier simplement un composant sans passer par ses mots-clés, surtout pratique pour faire des requêtes de debug
attribut (id, nom, unite, type)
cmpattr (composantid, attributid) -- simple table de liaison qui permet de trouver la liste des attributs d'un composant. un même attribut peut alors être utilisé par deux composants différents)
confattr (configurationid, composantid, numpos, attributid, attrval) -- numpos s'incrémente pour les couples configurationid/composantid identiques, afin de gérer les doublons -deux disques dur par exemple-
cmpkwd (composantid, keywordid) -- lien entre un composant et un mot clé -comme ça un mot clé unique peut être utilisé pour plusieurs composants-
keyword (id, nom)
 
 
Voilà pour le modèle "classique"
On retrouve une structure assez proche de la tienne, mais avec des liens différents. Avec ce système, il est par exemple extrêment simple de faire le rapprochement entre le floppy disque d'une config1 et le floppy disque d'une config2, chose que je ne vois même pas comment faire avec ton modèle actuel. Je pense que le système est tout aussi générique que le tiens, tout en étant bien plus aisé à parcourir.
 
 
 
Second système. Sauce "Générix" (l'ERP sur lequel je travaille depuis pas mal de temps maintenant)
 
Il s'agit de standardiser un maximum les tables, afin de gérer une infinité de cas et de règles sans jamais devoir toucher à la base, ni même aux requêtes.
 
On va donc faire des tables totalement "multi-tâche", qui peuvent stocker tout et n'importe quoi, tout en conservant un maximum de simplicité pour les requêtes.
 
Je pars du principe ici que les versions ne sont pas importantes (pas un critère de filtre) alors que connaitre l'état d'une configuration à une date précise est vital.
 
Table PRO (Produit).
Tu n'as besoin que de (typpro, codpro, nompro)
=> TYPPRO = "CNF" pour une config, "CMP" pour un composant et "ATT" pour un attribut
 
Table QUE (qui/quoi/que/comment/quand en fait )
clés :
tqui/qui : "CNF/codpro", c'est à dire ta config.
tquoi/quoi : "CMP/codpro", c'est à dire un composant.
tque/que : "ATT/codpro", c'est à dire un attribut
datdeb : date d'ajout/modif du composant dans la config
datfin : date de retrait/modif du compoant
numpos : un compeur pour les quadruplets identiques qui/quoi/que/datdeb (exemple des disques)
valque : valeur de ton attribut
coduni : unité de ton attribut (pratique pour comparer "2800 MHz" et "2,8 GHz" )
 
On peut rajouter des champs dans "PRO" afin de gérer tes problèmes de tri par exemple, ou rajouter des tables aussi, tout comme on peut gérer une table de conversion des unités. Je ne vais pas non plus te poster tout le modèle des données de Générix, il est un peu protégé à la base
 
En tout cas, comme tu le vois, avec 2 bêtes tables toutes simples, tu peux parfaitement gérer 90% de ta problématique d'un coup.
Mieux, grace aux tqui/tquoi/tque tu peux t'amuser à stocker dans la table QUE des règles de gestion "tqui = CMP" et "tquoi = CMP" afin d'indiquer par exemple que deux composant doivent obligatoirement être mis ensemble dans une config, ou s'excluent mutuellement, etc.
c'est aussi avec un coup "tqui = CMP" / "tquoi = ATT / tque = null" que tu gèreras la liste des attributs possibles pour une configuration.
 
Bref, chuis amoureux de ce modèle, un peu chaud à prendre en main, mais qui permet de stocker tous les caprices des utilisateurs les plus chiants savoir avoirà revoir la structure de la base (ni même les requêtes/scripts, qui sont réutilisables à l'infini)

Bon, vu que t'as pas attendu, j'ai balourdé ton script sur le serveur Oracle de production du client
Comme ça au moins je foutrai pas mon serveur de dev par terre
 
Bon, je regarde ton bignou

Sur le premier modèle, je ne comprend pas bien l'intérêt de garder la table cmpattr (composantid, attributid) dans la mesure où la table confattr (configurationid, composantid, numpos, attributid, attrval) gère déjà la relation entre un attribut et un composant. Par ailleurs, la table cmpkwd (composantid, keywordid) n'a plus lieu d'être non plu puisque la table composant (id, nom, parent) gére et le nom des composants et l'arborescence de chaque composant.
 
Pour le coup, la comparaison sera peut-être plus simple sur ce modèle, mais alors la récupération d'une conf me paraît bien compliqué à faire en 1 seule requête avec la structure arborescente des composants.
 
Par contre, je dois dire que le 2ième modèle est assez intéressant Voir tout comme des produits, je n'y avais pas pensé. Par contre, le coup de l'unité, j'y avais pensé mais difficle à mettre en oeuvre car les 2/3 des confs sont issues d'un import XML qui provient lui même d'un script d'audit qui sort que du texte (y'a une moulinette qui converti la sortie texte en XML a postériori).
 
Le coup de numéroter les composants d'une même instance, ça me donne une idée : pourquoi, lors de ma comparaison, ne pas créer une table temporaire ayant une structure plus adapter qui stockerait les attributs et composants des 2 confs à comparer et numéroter les composants qui apparaissent plusieurs fois?

en fait, avec tes données comme avec les miennes, tu fais comment pour matcher les coposants issus de deux configs différentes (ou même de deux versions différentes) ?
 
parcequ'à la base, t'as que des ID différents. donc à partir de là, le seul moyen de les retrouver, c'est de passer par la table des mots clés, et c'est la merde. en plus du coup ça merde si t'as deux fois "le même" composant dans la même config. genre, t'as deux disques dur ? mais ils ne sont pas pareil. comment tu les identifies ? comment tu fais, au moment de la comparaison avec une autre config qui a les deux mêmes disques, pour savoir dans quel ordre comparer les trucs ? et si au contraire, des attributs de différents composants viennent se complèter et faire croire que t'as le même composant (genre 1 hd IBM de 9.1 Go, un 1 hd HP de 80 Go, comment être sur de ne pas croire que t'as un IBM de 80 Go ? en fait ton modèle est maxi-merdique à ce niveau, on sait pas qui correspond vraiment à quoi)

Essaie ça, ça m'a l'air de marcher :
 

 
Sur un vieux Serveur tout pourri (je rigolais, c'est pas le serveur de prod, c'est le serveur qu'on a mis à la retraîte il y a 15 jours ) Oracle me retourne un truc coéhrent (j'ai pas dit "juste" hein ) en 47 millisecondes.
 
Donc y devrait y avoir moyen de garder espoire niveau perfs.
(genre changer de SGBD )
 
Courage !
 
 
-- Edit : J'avais une grosse gourance dans mon script.
 
A noter que pour le coup des <>, c'est bien ce que je disais : tu pourras pas t'en sortir sans passer par des composants identifiables d'une config à l'autre (mêmes ID). là je vois qu'il y a des attributs identiques ou différents, mais c'est "prospère youpla boum !" pas moyen de les matcher correctement... A moins que... hmmmm, ça sent le prosac ça, je fais un test

Effectivement, j'utilise les mots-clés des composants. Et le pb que tu décrit (plusieurs intances d'un même mot-clé dans une conf) est effectivement celui sur lequel je bute.
 
Toi, avec ton modèle, tu le résouds en attribuant un n° de 1 à n à chaque composant. Puis, dans le cas de plusieurs instances d'un même  mot-clé tu vas comparer les composants de même n° entre eux.
Le seul souci, c'est que ce n° dépend de l'ordre d'insertion des composants dans la base (à moins que ce soit l'utilisateur qui le saisisse) ce qui me gêne car les mêmes composants ne sont pas forcément inséré dans le même ordre d'une fois sur l'autre (là, je parle de confs qui sont importées via XML)...
 
Sinon, pour le coup de 1 hd IBM de 9.1 Go, un 1 hd HP de 80 Go, j'ai pas de pb pour m'y retrouver puisque chacun est un compsoant différent :  
Composant 1 (rattaché au mot-clé "disque" ) :
ID      Name       Value
1      Marque      IBM
2     Capacité     9.1 Go
 
Composant 2 (rattaché au mot-clé "disque" ) :
ID      Name       Value
3      Marque      HP
4     Capacité     80 Go

Moi, ça prend 200 ms sur un PIII 700.
 
En tout cas, t'es plus bourrin que moi Moi, je faisais 3 requêtes pour éviter les UNION...

Ca me semble mieux
 

 
Mais je ne retombe quand même pas sur le résultat que tu attends.
Ceci dit, j'ai eu des erreurs lors du remplissage de la première table, et j'ai laissé pisser (MySQL qui génère des insert de goret sans mettre toutes les colonnes )

pour info, sur cet exemple là, mes 3 requêtes donnent le bon résultat. Le prochain exemple sera plus dur

oui, mais lors de la comparaison, du moins avec ma requête, le composant n'entre pas en jeu lors de la comparaison. on cherche juste s'il y a un attribut apparemant à un composant qui a un mot clé donné.
mais tous les attributs correspondant à un même mot clé sont mélangés, impossible lors de la comparaison de faire composant par composant

Ce coup ci, mais requete à l'air bonne
 

 
Par contre, y'a deux "<>" : le type de CPU et le type de RAM. toi t'en a qu'un (elles marchent pas tes requêtes )

Il ne peut y avoir qu'1 seul <> car Type Ram n'existe que dans la conf 1.
 
Par rapport à moi, t'as inversé la position des conf 1 et 7 dans les requêtes mais c'est pas grave : mes + sont tes - et inversement.

Dans ton résultat, il te manque l'attribut 15 qui doit être en diff + pour moi (- pour toi) et l'attribut 7 doit être en - pour moi (+ pour toi).

Autant pour moi pour les <>
 
J'ai ça maintenant (en effet, toujours à cause de tes keywords. c'est trop tordu pour moi, j'arrive pas à m'y faire )
 
J'en ai profité pour remettre dans le même sens que toi.
 
Je look pour ceux qui ont disparus

Corrigé
 
Même problème en fait.
Et ça confirme ce que je dis...
 
T'as essayé le cas que je t'ai indiqué ? Comparer deux HD (un IBM de 9.1 et un HP de 80, avec un IBM de 80). Je ne pense pas que ça puisse marcher...
 

 
 
PS: sinon, pour le coup de mes solution avec le NUMPOS pour différencier deux composants identiques, il suffit de rajouter un niveau (id, confid, cmpid) et mettre ce nouvel id à la place de confid/cmpid dans la table qui fait le lien entre la config et ses attributs.

Allez, je te sens chaud pour le 2ième exemple. Si celui passe, c'est dans la poche je pense
 
D'abord le contenu des 2 confs
La conf ayant pour ID 6
Composant ID = 15
Attribute ID = 1 (Nb CPU)
Attribute ID = 2 (type CPU)
Attribute ID = 7 (Type Ram)
 
Composant ID = 16
Attribute ID = 8 (Nom lecteur)
 
Composant ID = 17
Attribute ID = 9 (Nom lecteur), attribut non pertinent
 
Composant ID = 18
Attribute ID = 10 (nom OS)
 
Composant ID = 19
Attribute ID = 11 (nom graphique)
 
Composant ID = 20
Attribute ID = 14 (nom graphique)
 
 
La conf ayant pour ID 10
Composant ID = 87
Attribute ID = 1 (Nb CPU)
Attribute ID = 2 (type CPU)
Attribute ID = 7 (Type Ram)
 
Composant ID = 88
Attribute ID = 8 (Nom lecteur)
 
Composant ID = 90
Attribute ID = 10 (nom OS)
 
Composant ID = 91
Attribute ID = 11 (nom graphique)
 
Composant ID = 92
Attribute ID = 17 (vitesse lecture)
Attribute ID = 18 (Marque)
Attribute ID = 19 (Interface)
 
Ce qu'il faut avoir en sortie quand on compare conf 10 à conf 6 (conf 6 étant la référence de comparaison), c'est :

 
Avec mes requêtes, si je compare 10 à 6, je ne trouve que les 3 + et rien d'autre. Si je compare 6 à 10, je trouve les 3 + et les attributs 9 et 14 sont comptabilisés comme des <> à la place de -

 
 
C'est bon, cette requête est OK (tout y est). Elle met 0.1774 sec.
 
A voir si elle fonctionne pour le 2ième cas.
 
par contre, j'ai pas compris ton ps...

je viens de tester ta requête sur le 2ième ex : t'as le même résultat (erroné) que moi. Un coup y'a que les +, un coup y'a les - et 2 <>

-- ouais non j'ai rien dit --

 
t'as ça avec ta dernière requête? Bizarre, moi non avec ta dernière requête...

 
je me disais aussi...

Typiquement, c'est "normal".
 
Car comme je te dis depuis le début, pour les deux lecteurs de disque et les deux cartes graphiques par exemple, on n'a aucun moyen de faire la différence entre 2 disques et 1 seul disque. Mise à part faire une requête de tarré (et je suis même pas sûr que ça marche) je ne vois pas comment faire.
 
A partir de là, on ne peut isoler que les différences. Tous les doublons d'"attributenames" ne sont comptabilisés que comme des listes de valeurs, mais pas comme des objets séparés. en gros, t'as 1 seul floppy, qui a un attribut qui prend deux valeurs différentes. donc si on compare à un floppy qui n'a qu'un attribut, on ne voit que le fait qu'il existes un cas où la valeur n'est pas la même, on est incapable de voir qu'il manque une valeur.
on pourrait s'amuser à mettre de nouveaux sous-select avec des count() pour compter les attributs et vérifier, mais ça ne permettrait que de détecter le problème, pas de le résoudre.
 
je ne vois pas d'autre solution "simple". si on pouvait comparer les éléments par composant id, ce serait une grosse galère aussi, mais ce serait possible. là, j'en doute

en fait, seule solution (celle que j'avais adopté hier soir dans mon jeu de test), c'est de faire un keyword "FD0" et "FD1", afin de séparer le rôle de tes deux FD. à la base, je ne pense pas que ce soit gênant, parceque selon la place d'un composant dans un serveur, on ne pourra pas en faire la même chose : genre j'ai 30 HD dans un serveur, si ils sont regroupés 2 à 2 sur 15 interfaces SCSI, je ne pourrai pas faire de RAID. s'ils sont chacun sur un adaptateur SCSI, eux-même reliés à un autre adaptateur SCSI, je pourrai faire du RAID 5+0, ce qui change du tout au tout le rôle potentiel du serveur (storage dans le premier cas, et datawarehouse dans le second par exemple)

et faire une table temporaire plus adaptée pour la comparaison, ça te paraît jouable?

tu peux essayer. là je te laisse, j'ai aussi un travail et là j'ai un gros truc à faire pour demain, c'est pas gagné