Bonjour et bonne année.
 
Une petite question pour bien démarrer 2007:
Je suis sous Access.
J'ai fait une base de données d'équipements, avec leurs caractéristiques. Comme ces équipements pouvaient avoir des caractéristiques différentes, j'ai réalisé
-une table contenant tout mes équipements
---> Avec comme seul champ le nom de ce dernier (qui est suffisant pour l'identifier de manière unique et me sert de clé)
 
-une table contenant les types de caractéristiques possibles qui me sert à alimenter une liste de choix
---> Avec comme seul champ le nom de la caractéristique
 
-une table contenant les caractéristiques des équipements
---> Avec comme champs: le nom de l'équipement
                                     le nom de la caractéristique (choisi dans la table précédente)
                                     la valeur de la caractéristique
 
J'ai ensuite fait un formulaire listant les équipements, qui me permet en cliquant sur un équipement de faire apparaitre ses caractéristiques via une requête SQL dans une liste.
 
Je souhaiterais pouvoir trier les caractéristiques dans un ordre bien précis (longueur largeur puis poids par exemple) pour tous les objets. J'ai donc pensé à ajouter un champ dans ma table avec les types de caractéristiques, et qui me permettrait d'associer un numéro et de trier mes résultats par l'ordre de ces numéros. Mais la commande ORDER que j'utilises ne peut faire son tri que sur les données récupérées, et mon champ qui permettrait de classer n'est que dans la table qui sert de source pour la liste déroulante, pas dans celle contenant les caractéristiques, donc pas de tri.
 
Des idées?
 
Merci d'avance.

déjà, tu devrais éviter d'utiliser comme clé primaire une chaîne de caractères pour identifier tes équipements. Un ID numérique serait mieux, à commencer par le fait que comme le nom apparaît en tant que clé étrangère dans la table contenant les caractéristiques des équipements, ça va prendre bien plus de place. Et si tu change le libellé du nom de l'équipement, va falloir répercuter la modif partout. Bonjour la galère
 
A qq exceptions près, la clé primaire est très souvent un ID entier (par contre, plus ou moins long, tout dépend du contenu de ta table). Les exceptions, ce sont les n° de sécu, les plaques minéralogiques, les codes barres...Et encore, on mettrait un ID entier, ça ne serait pas une hérésie (de mon point de vue).
 
pour répondre à ton pb, tu fais une jointure entre les 2 dernières tables que tu citais.

+1 rufo , les clés primaires en full texte c'est signé pour des ennuis ...  
 

 
Je ne comprends pas le sens de cette phrase. A quoi servent les requêtes croisées alors (tu sais ce que c'est un INNER JOIN rassure-moi ? )

 
 
Non, je débute.

alors, un petit tour sur www.commentcamarche.net t'aideras pour acquérir les bases du SQL
 
http://www.commentcamarche.net/sql/sqlsel.php3

et un article assez clair (en anglais) sur les jointures :  
 
http://www.w3schools.com/sql/sql_join.asp
 
Si tu es anglophobe tu devrais pouvoir trouver ton bonheur sur Google ...

Merci beaucoup, je galérais la dessus depuis hier et je sais pas pourquoi dans mes recherches j'étais passé complètement à côté de ces histoires de jointures. Mais bon ça me semblait louche, d'où mon post.
 
Pour les histoires d'ID, est-ce vraiment dangereux/génant? Si quelqu'un de plus pro que moi doit retravailler sur la base derrière, va-t-il s'arracher les cheveux?

oh oui. C'est dangereux, ça gaspille de la place dans la BD et je pense que côté perfs, on doit y gagner avec un ID sous forme d'entier que de chaîne. Comme tu débutes, je pense que tu devrais regarder les notions de clé primaire, de clé étrangère, d'équi-jointure, de jointure externe et de MCD (modèle conceptuel de données). Si tu veux pas qu'un jour, un pro des BD te sorte "c'est quoi ce modèle conçu par un mongolien" (hein Magicbuzz ), tu sais ce qu'il te reste à faire...
 
Sur ce, bonne lecture.

 
Dans un petite base de données tu ne verras aucune différence de perfs ... mais il vaut TOUJOURS mieux travailler proprement dès le début. C'est comme quand tu apprends à conduire ; si tu roules comme un bourrin dès que tu commences, tu auras un mal fou à conduire correctement par la suite et tôt ou tard, ça te mènera plus vite à un accident, qu'un conducteur attentif.
(désolé, skill de métaphore pas en forme aujourd'hui   )
 
Et comme le dit très bien Rufo, lorsque quelqu'un d'averti tombe sur une base de données structurée comme ça, il s'en arrache les cheveux, littéralement  

Je suis d'accord, j'ai tendance à être très rigoureux quand je fais de l'info, donc je me suis mis à la correction. Heureusement que j'avais pas mis beaucoup d'entrées encore...
 
Merci encore.

dans la foulée, ça serait bien que tu nous postes ici ton MCD. Comme ça, si y'a d'autres choses qui clochent, on pourra te le dire...

C'est très sympa de ta part. Et dire que j'avais bien fait gaffe sur mon CV pour ce stage de dire que je maitrisais Word et Excel, mais pas tout Office...
 
Voici le lien
 
http://dl-3.free.fr/52616e646f6d49 [...] pments.mde

 
c'est pas ton fichier access qu'on veut, juste le modèle de données -> une image donc de ton mcd.

http://dl-1.free.fr/52616e646f6d49 [...] 34/MCD.PNG
 
Voici.

 
bon, déjà :
- dans le MCD, on ne fait pas apparaître dans les tables, les clés étrangères. Elles sont symbolisées par les relations entre les tables (les traits et les cardinbalités). Bien sûr, au moment d'implémenter ton MCD, il ne faudra pas les oublier.
- faut surtout pas nommer des champs avec des espaces ou des accents! Acces le permet mais c'est une hérésie  
- y'a un pb avec la modélisation de ta relation entre EquipementFamilies, EquipementTypes et Equipements : la clé étrangère IDFamily apparaît dans 2 tables, c'est pas possible car y'a redondance. y'a donc une relation de trop...