J'ai une table avec 3 colonnes :
mot_cle, mot_cle2, mot_cle3
Je voudrais récupérer tous les mots
des 3 colonnes, en évitant les doublons, (sachant q'un même mot
peut se retrouver dans mot_cle, mais aussi dans mot_cle2 ou dans mot_cle3).
En gros, faire un "SELECT DISTINCT mot_cle" un "SELECT DISTINCT mot_cle2" et "SELECT DISTINCT mot_cle3" en une seule requête !
Si je fais "SELECT DISTINCT mot_cle, mot_cle2, mot_cle3"
ça ne fonctionne pas
fonction_qui_filtre_les_lignes faisant le boulot de filtration. C'est à dire qu'il va manipuler le tableau pour qu'il n'y ai pas de doublon. Il va falloir boucler sur les lignes et comparer des valeurs. Avec un peu de réflexion tu peux y arriver.
Ceci dit, la table d'origine a un défaut de conception. Je verrais plutôt quelque chose dans ce goût là :
Donc, 2 tables liéées, tu as raison,
c'est sûrement le mieux.
Je dois me pencher sérieusement sur cette histoire de tables liéées, j'en ai pas encore fait !
Bref,
J'ai une autre question de newbie !
Je dois faire une sorte de médiathèque, avec des catégories, et dans chaque catégorie, des albums .
C'est quoi la solution ?
Créer une base de données pour chaque catégorie, puis les tables "albums"
ou (justement),
créer une table "album" et une autre table, liée, avec le nom de la catégorie ??
Sachant qu'il va y avoir plein de fichiers, et que je dois pouvoir ensuite, faire un moteur de recherche, dans les différentes catégories, et aussi assigner à tel ou tel membre, tel ou tel album
Ouf !
Merci à vous pour votre aide si précieuse !
Bonne journée
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
C'est une solution parmi d'autres. Il y a peut être plus élégant, plus puissant, plus performant, etc. C'est une question de goût, et surtout de besoin.
Il n'y a pas une seule solution. Le problème auquel tu veux répondre peut être traité de différentes manières, selon les ressources dont tu disposes, et des fonctionnalités que tu dois fournir. Ainsi que les performances attendues, la maintenabilité, l'évolutivité.
Ce qu'il faut que tu gardes à l'esprit, c'est que pour mieux régner, il faut diviser. Donc essaye de séparer au maximum les concepts, quitte à devoir dénormaliser par la suite.
Il faut aussi que tu acquiert le vocabulaire. Par exemple, on ne parle pas de tables liées, mais de jointures ou de relations. Comprendre et maîtriser ces mécanismes te permettrons de facilement modéliser ton application.
Essaye déjà de créer quelque chose de simple, teste, fais valider par les utilisateurs (ou commanditaires), en précisant que c'est un prototype (et précise ces limites, pour éviter d'être noyé dans les demandes de fonctionnalités). Puis rajoute les fonctionnalités progressivement, comme si tu incorporait du sucre à ton blanc d'œuf monté en neige : si tu ajoutes tout d'un coup, ta meringue est râtée. Dans le développement, c'est pareil : quand l'incorporation a échouée, vaut mieux jeter la préparation et recommencer. Ce qui est rarement faisable. Donc vas-y au fur et à mesure.
Ceci dit : c'est un développement professionnel ? Tu es seul à le réalisé ?
