Version imprimable
bonjour
Je suis en train de tenter de faire un petit moteur de recherche pour mon site perso avec un formulaire qui lance un php qui lance des requêtes !
La recherche se fait sur 2 tables une d'auteurs et une de titres. Pour ça elles sont "jointurées" (je ne sais pas comment on dit que deux tables font l'objet d'une jointure ...)
Sauf que je voudrais que le message ne soit pas le même selon la table d'où provient le résultat.
Comment faire ? Je n'ai pas trouver d'exemple dans les tutos.
Bjr,
Pas le même message ???
C'est un moteur de recherche ou un chatbox ? Soit plus clair stp,
Tu veux savoir de quel table provient le résultat , mais pk ?
Est-ce que c'est une vraie jointure (avec une clause JOIN ou un produit cartésien FROM table1, table2), ce qui consiste formellement à les mettre côte à côte, donc avec des colonnes propres à chacune, ou s'agit-il d'une UNION qui, elle, consiste plutôt à les placer l'une après l'autre, donc avec des colonnes communes ?Citation:
Envoyé par noradan
Si c'est une vraie jointure, il te suffit de choisir la bonne colonne. Si c'est une union, soit tu réécris ta requête au propre pour effectuer des jointures, soit tu intègres dans chaque SELECT un identifiant constant propre (par exemple un numéro comme 1 ou 2) qui te permettra d'identifier la source de chaque tuple et de les discriminer ensuite avec WHERE.
Montre-nous ta requête, s'il-te-plaît.
Heu...
C'est une colle !
Je n'avais pas pensé à ces distinctions.
En fait j'ai une table avec des auteurs et une référence vers une page html contenant des infos sur l'auteur et une table avec des titres d'oeuvres et bien sûr une colonne avec les auteurs.
Donc par exemple si on écrit en recherche "victor hugo" on doit avoir comme réponse aussi bien "Victor Hugo -- Auteur" qui sera un lien cliquable mais aussi
"Les Misérables par Victor Hugo, Notre-Dame de Paris par Victor Hugo etc
Déjà je ne sais pas très bien compte tenu de ce que tu as dit quel est le type de jonction le mieux adapté.
J'ai l'impression que c'est une union...
donc il suffirait que j'ajoute une colonne supplémentaire avec un identifiant (c'est l'idée bête je j'avais eu mais je me suis dit qu'il y avait peut-être plus intelligent).
Bonjour,
Non, c'est bien une jointure. Et dans cette situation, ton résultat est bien une table de n lignes et m colonnes. Chaque ligne correspond à une possibilité de ta requête et donc, à chaque fois, cette ligne contient à la fois l'auteur et le nom de l'ouvrage.Citation:
Envoyé par noradan
C'est effectivement comme ça que l'on fait et, mieux encore, on pose ensuite les contraintes d'intégrité en déclarant notamment la colonne « auteur » de la table des ouvrages, qui contient l'identifiant de l'auteur, comme « clé étrangère » référençant la clé primaire de la table des auteurs.Citation:
donc il suffirait que j'ajoute une colonne supplémentaire avec un identifiant (c'est l'idée bête je j'avais eu mais je me suis dit qu'il y avait peut-être plus intelligent).
Concrètement :
Tu composes d'abord une table « auteurs » :
id_auteur nom description 1 Victor Hugo (1802 - 1885) 2 Albert Camus (1913 - 1960) … … …
Tu composes ensuite une table « ouvrages » :
id_ouvrage id_auteur titre url description 1 1 Les misérables https://quelquepart.com/lesmiserables (…) 2 1 Notre-Dame de Paris https://quelquepart.com/nddp.php … 3 2 L'étranger https://autrepart/letranger.html … 4 2 La peste https://ailleurs.com/lapeste.php … 5 … … … …
Dans cet exemple, on désigne la première colonne de chaque table comme clé primaire. Elle contiennent donc un identifiant unique pour chaque ligne qui, à lui seul, permet de retrouver et d'isoler avec certitude la ligne entière et son contenu. Cet identifiant peut prendre n'importe quelle forme tant que l'unicité est respectée mais le plus naturel consiste bien sûr à utiliser un numéro, lequel est en général automatiquement attribué et incrémenté par le SGBD si on a pris soin de lui demander de le faire à la création de la table.
La deuxième colonne de la table « ouvrage » est une « clé étrangère ». Si tu la définis comme telle, tu indiques au serveur que :
- Ce qu'elle contient est officiellement un des ID de la table « auteur » (donc que la ligne référence un auteur donné) ;
- Qu'on ne peut y insérer que des valeurs qui existent déjà dans la première colonne de la table « auteur », faute de quoi l'insertion de la ligne entière doit échouer ;
- Qu'on ne peut supprimer de « auteurs » une ligne qui est référencée par une ou plusieurs lignes de « ouvrages » (il faut d'abord faire le ménage dans « ouvrages » si on souhaite le faire).
Les contraintes d'intégrités sont optionnelles mais fortement conseillées. Si tu ne l'as pas fait, cela ne t'empêchera cependant pas d'effectuer une requête quand même.
Tu interroges ensuite ta base comme suit, en établissant une jointure entre tes deux tables :
Code:
2
3
4
5
6
7
Ce faisant, tu indiques ici que les deux tables doivent être associés en fonction d'un critère commun, ici le champ « id_auteur ». Comme tu peux très bien avoir m lignes correspondant à une valeur donnée dans une table et n lignes correspondant à la même valeur dans l'autre, la base effectue un produit cartésien, c'est-à-dire qu'elle va en gros composer toutes les combinaisons possibles, donc m×n combinaisons en tout. Mais comme ici (comme dans la plupart des cas), la colonne concernée est la clé primaire de l'une des tables (où chaque valeur est unique), tu obtiens 1×n combinaisons, c'est-à-dire le nombre de lignes correspondantes de l'autre table. Le WHERE s'applique ensuite comme filtre sur le résultat entier, en ne sélectionnant que les lignes qui t'intéressent, soit ici les lignes dont l'auteur est « Victor Hugo ».
Tu obtiens alors :
id_auteur nom description id_ouvrage id_auteur titre url description 1 Victor Hugo (1802 - 1885) 1 1 Les misérables https://quelquepart.com/lesmiserables (…) 1 Victor Hugo (1802 - 1885) 2 1 Notre-Dame de Paris https://quelquepart.com/nddp.php …
Au sein de cet ensemble complet, tu peux alors sélectionner les colonnes qui t'intéressent (d'où le nom).
Code:SELECT nom, titre, url…
nom titre url Victor Hugo Les misérables https://quelquepart.com/lesmiserables Victor Hugo Notre-Dame de Paris https://quelquepart.com/nddp.php
… qui est bien un sous-ensemble du résultat ci-dessus.
Voilà pour une jointure élémentaire. Tu auras très bien besoin des jointures ouvertes, mais chaque chose en son temps.
Maintenant, qu'entendais-tu exactement par :
… ?Citation:
Sauf que je voudrais que le message ne soit pas le même selon la table d'où provient le résultat.
Merci pour le cours privé sur les jointure !
j'envisageais la chose de façon plus simple car je n'ai pas l'intention de récupérer des infos de la table auteur lors d'un succès dans la table ouvrage.
Les deux tables seraient complètement indépendantes
Une table "auteur" comme tu as fait
id - nom - lien
mais j'envisageais la table "ouvrage" plus simplement
id - auteur - titre - lien
où au lieu de faire référence au même identifiant pour les auteurs qu'à la table "auteur" ce qui en effet pour ce que j'ai compris nécessite une jointure
j'écris le nom explicitement
la requête se faisant d'abord sur les auteurs puis sur les ouvrages et (c'est là le coup du message) et renvoie
Auteur VICTOR HUGO (1802-1885) lien_vers_une_page
Ouvrage LES MISERABLES par Victor Hugo ( en gras par exemple) lien_vers_une_page
etc
Une requête sur "misérables" retournant uniquement
Ouvrage LES MISERABLES par Victor Hugo lien_vers_une_page
Comme je ne récupère rien de la première table lorsque je j'affiche un succès sur la deuxième je me dis que dans l'esprit c'est plutôt une union mais dans la pratique...
Les tuto parlent toujours de jointure (ce qui en effet est plus sophistiqué).
Du coup il y a un souci car je viens de lire des choses sur UNION or le succès sur la table "auteur" ne retourne pas le même nombre de colonne que sur la table ouvrage puisqu'un succès dans celle-ci retourne le nom de l'auteur en plus
Pour en faire une il faudrait que j'ajoute une colonne vide à la table auteur portant le même nom que celle des auteurs dans la table "ouvrage" (j'espère que tu as compris LOL!)
Evidemment il y a la solution idiote de faire deux requêtes sauf que je voudrais bénéficier du classement par pertinence sur les deux car dans mon cas concret (des groupes de musiciens (p.ex. Nirvana, Les Beatles, Indochine etc) et des titres d'albums) il pourrait y avoir un nom de groupe (souvent un seul mot ou deux) qui coïncide avec un titre d'album d'un autre parfois même du même groupe (c'est parfois le cas lors du premier album).
Mon problème est-il plus claire ?
Il a fallu que je m'accroche un peu mais j'ai fini par comprendre ton angle de vision des choses : tu as deux tables a priori indépendantes (auteurs et ouvrages) même si l'on peut établir une relation entre les deux, ces deux tables exposent chacune un champ humainement lisible et ton interface propose un champ « universel » qui permet de faire une recherche sur tout ce qui contient du texte à travers la base. C'est effectivement à la mode et j'en ai moi-même écrit une, qui restreint le contenu d'une liste initialement complète au fur et à mesure que l'on tape.
En ce sens, ce serait effectivement une UNION, mais ce n'est pas forcément la meilleure approche à suivre.
On rappelle déjà que les unions en SQL sont en fait un des opérateurs ensemblistes UNION, INTERSECT et EXCEPT. Lorsque tu associes deux sous-ensembles (les tables) en un seul, les éléments (les lignes, ou tuples) doivent tous être de même type, ou à tout le moins compatibles : même nombre de colonnes, dans le même ordre et donc les types doivent être respectivement compatibles (texte avec texte, nombre avec nombre…), justement pour pouvoir être rassemblés au sein d'une même table.
Pas dans la table elle-même, mais dans la requête, c'est tout-à-fait envisageable. Tu peux également introduire un champ constant dans chacune des tables qui permette justement d'en distinguer la source. Tu peux écrire par exemple :Citation:
Pour en faire une il faudrait que j'ajoute une colonne vide à la table auteur portant le même nom que celle des auteurs dans la table "ouvrage" (j'espère que tu as compris LOL!)
Tu obtiendrais alors :Code:
2
3
4
5
6
7
8
9
source id libelle url auteurs 1 Victor Hugo null ouvrages 1 Les misérables, par Victor Hugo http://quelquepart.com/lmis.html ouvrages 2 Notre-Dame de Paris, par Victor Hugo http://quelquepart.com/nddp.html … … … …
… par contre, cela n'est intéressant que si tu agrèges des extraits qui proviennent déjà de la même table ou, au contraire, si tu veux rassembler des éléments provenant de sources qui n'ont rien à voir entre elles mais dont lesdits éléments ont des traits communs sur la forme.
En revanche, s'il existe une table « auteurs », aller écrire explicitement Victor Hugo en toutes lettres dans un champ de la table « ouvrages » :
id auteur titre url 1 Victor Hugo Les misérables https://quelquepart.com/lmis.html
… ça, c'est vraiment la chose à ne pas faire du tout avec un SGBD. Surtout si c'est pour éviter d'avoir à faire une jointure qui, dans ce cas particulier, resterait à la fois le plus simple et le plus indiqué.
grâce à tes réponses toujours très pédagogiques ça commence à s'éclairer (un peu et très doucement parce que j'ai l'impression que ça n'est quand même pas facile.... :koi:
Je conçois qu'avoir une colonne qui reprenne les noms d'auteurs ne soit pas informatiquement judicieux (principe de base de l'info "On ne répète jamais, les machines sont faites pour ça")
MAIS
tu écris pourtant explicitement l'auteur dans les libellés ... Quelle est alors la différence ?
Pour moi qui vais remplir ma table ça m'a l'air plus simple, plus "rangé" d'avoir une colonne avec l'auteur.
D'autant que si je mets le texte "ouvrage par machin" j'ai l'impression qu'il n'est plus utile de distinguer les tables par une colonne constante
Quand à la méthode du début : comment faire pour mettre le bon identifiant numérique d'auteur ? Fabriquer la table d'ouvrage devient quelque chose de très compliqué ou alors il y a une méthode magique ... pour éviter d'avoir à parcourir sa table 1 pour remplir la table 2
Quand à ton truc qui restreint la liste au fur et à mesure, ça m'intéresse évidemment mais ce sera pour après (c'est la "complétion automatique" ou quelque chose comme ça si je ne m'abuse )
Tout-à-fait. Sauf bien sûr en cas de redondance volontaire pour tolérance aux pannes mais dans ce cas, ces données sont gérées autrement (et par les machines aussi).Citation:
Envoyé par noradan
Ici je le faisais exprès pour illustrer ma requête et te permettre de confirmer que l'on parlait bien de la même chose…Citation:
MAIS tu écris pourtant explicitement l'auteur dans les libellés ... Quelle est alors la différence ?
Donc si tu as un titre composé qui contient — en autres choses — le nom de l'auteur sans que la base en ait officiellement conscience, il peut être justifié de faire une recherche « tous azimuts » et d'agréger les résultats (ici avec UNION) même s'ils n'ont rien à voir entre eux. Par contre, si tu as d'un côté un table « auteur » et de l'autre, une colonne « auteur » dans une table ouvrage, donc si cette colonne référence officiellement l'auteur de l'ouvrage (et rien d'autre), alors il n'y a aucune raison de ne pas référencer la table « auteur » à l'aide d'un ID interne.
Plus précisément, si on souhaitait le faire quand même, il faudrait être capable d'expliquer précisément pourquoi et dans cette situation, on n'exhibe en général que des mauvaises raisons. La première est qu'en général, les jointures ont l'air compliquées et qu'on essaie en général d'éviter d'y recourir (alors qu'il faudrait au contraire s'y plonger presque dès le départ), la seconde est que les gens gère cela comme s'ils le faisaient sur papier ou pire… dans un tableau Excel ! (pas que les tableurs soient de mauvais outils, au contraire, mais ce sont tout sauf des bases de données et on ne compte plus le nombre de scientifiques, notamment, qui les utilisent de cette façon quand même).
Autre point important : le SQL a été conçu pour utiliser un langage aussi naturel que possible. Le Shell Unix et la ligne de commande DOS qui en découle, en principe, devaient l'être aussi. L'objectif inatteignable de l'époque était de pouvoir formuler une requête au système de la même façon qu'on le fait à une IA aujourd'hui. C'est une bonne chose parce qu'interroger une table avec des opérateurs mathématiques auraient été une plaie. Par contre, cela doit s'arrêter là : l'interface utilisateur doit se situer un cran avant le SQL car il faut absolument concevoir une base de façon à ce que son modèle de données soit cohérent, et surtout pas pour qu'elle soit facile à interroger ! (en fait, elle doit l'être un peu quand même, sinon c'est peut-être le signe que la base est intrinsèquement mal conçue).
Si par la suite, tu veux interroger fréquemment ta base directement en SQL pour obtenir plus ou moins les mêmes réponses (comme si tu consultais un registre papier), alors SQL te permet de mettre en place des vues de façon standard, qui répondront à ce besoin.
Pas en interne, pour les raisons que tu as exposées toi-même en début de commentaire.Citation:
Pour moi qui vais remplir ma table ça m'a l'air plus simple, plus "rangé" d'avoir une colonne avec l'auteur.
Pour un lecteur humain non, pour une machine si. Et c'était surtout là la réponse à ta question initiale.Citation:
D'autant que si je mets le texte "ouvrage par machin" j'ai l'impression qu'il n'est plus utile de distinguer les tables par une colonne constante
Pour consulter cette table, les VIEW sont tes amies, comme expliqué ci-dessus. Pour la remplir, il n'y a pas de méthode magique, malheureusement.Citation:
Quand à la méthode du début : comment faire pour mettre le bon identifiant numérique d'auteur ? Fabriquer la table d'ouvrage devient quelque chose de très compliqué ou alors il y a une méthode magique ... pour éviter d'avoir à parcourir sa table 1 pour remplir la table 2
De toutes façons, INSERT INTO… n'est déjà, en soi, pas trivial. Il faut spécifier les bonnes colonnes, utiliser VALUE et passer les bonnes données en une fois, dans le bon ordre et suivant le bon format.
Donc, effectivement, tu peux récupérer les ID à la main et utiliser là où tu aurais écrit l'auteur en toutes lettres, tu peux également insérer de la sorte le résultat d'un SELECT (sur la même table ou sur une autre) pour reprendre l'essentiel d'une entrée existante et ne modifier que ce qui doit l'être ou tu peux mettre en place une fois pour toutes une fonction ou une procédure stockée à laquelle tu transmets les paramètres que tu aurais passés à SELECT et qui se charge de faire le travail pour toi.
Mais le mieux, là encore, consiste à utiliser une interface graphique qui te permette d'exploiter ta base. L'avantage est que, dans ce cas, cette interface est généralement capable de reconnaître les contraintes d'intégrité et les prendre en charge elle-même : par exemple, si tu as déclaré une clé étrangère en bonne et due forme (par exemple, une référence vers la table « auteur »), il est possible qu'elle te propose elle-même une liste déroulante contenant déjà le contenu de la table référencée, s'il n'est pas trop important ou un champ de recherche dans le cas contraire, qui te permettra de sélectionner facilement l'entrée ciblée, qu'elle référencera elle-même ensuite.
Ce n'est pas de la complétion automatique mais je ne sais plus quel nom ça porte, ni même si ça en a un, en réalité…Citation:
Quand à ton truc qui restreint la liste au fur et à mesure, ça m'intéresse évidemment mais ce sera pour après (c'est la "complétion automatique" ou quelque chose comme ça si je ne m'abuse )
Quoi qu'il en soit, ça ne concernera plus du tout le SQL et comme il faut que ce soit rapide, il faudra probablement le faire en front end et ça ne concernera donc plus le serveur non plus.
Bonjour,
Je souscris aux réponses précédemment fournies et j'y ajoute que :
- certains ouvrages n'ont pas d'auteur connu (ouvrages anciens) ;
- certains ouvrages ont plusieurs auteurs (ex : Paris brûle-t-il de Dominique Lapierre et Larry Collins) ;
- certains auteurs écrivent sous plusieurs pseudonymes (ex : André Ruellan alias Kurt Steiner alias André Louvigny alias Luc Vigan...) ;
- il existe des auteurs différents qui portent le même nom (homonymes, ex : Alexandre Dumas père et fils).
Il faut en tenir compte dans la modélisation !
EDIT : il faudrait préciser quelles informations sont renvoyées par l'URL associée à un ouvrage, car, selon l'édition et la collection, les informations relatives à un même ouvrage sont différentes (préface, postface, ISBN, illustrateur, nombre de pages, dimensions...)
Bon, alors ça progresse doucement mais ça progresse
D'abord, pour remplir la base avec le Id du groupe à la place du nom, j'ai bricolé ça
Mais je n'arrive pas à me dire que c'est mieux que d'écrire le nom explicitement.Code:VALUES (NULL,'nomdelalbum',(SELECT ID FROM groupes_index WHERE groupe='nom_explicite_du groupe'),'une_url');
Ensuite pour la requête j'ai bricolé ceci
J'ai fait ensuite une fonction d'affichage qui teste le numéro de tableCode:
2
3
4
5
6
7
8
Ca marche ... presque parfaitement.Code:
2
3
4
5
6
7
8
Le bémol vient que le classement par pertinence se fait séparément sur chaque table (ce qui d'ailleurs me paraît logique) or il me semble plus logique pour mon usage d'avoir une pertinence sur les deux ensembles.
Comme les noms et les titres sont en général très court (la plupart du temps 2 ou 3 mots) une recherche sur un nom d'album rique de "matcher" partiellement avec des noms de groupes qui vont donc se trouver avant le "match" 100% sur le nom de l'album
Comment peut-on avoir la pertinence sur le résultat total de la recherche ?
(PS J'espère que la réponse sera suffisamment courte pour qu'il n'y ait pas besoin d'ouvrir un nouveau sujet)
D'accord, donc on passe ici d'une bibliothèque à une « audiothèque ». Il faudrait préciser le schéma exact de ces nouvelles tables mais on va faire sans pour le moment.Citation:
Envoyé par noradan
En fait, pour insérer une ou plusieurs lignes dans une table, il faut passer à cette table… une ou plusieurs lignes ! :aie: Pour ce faire, il faut passer à INSERT INTO des données qui soient déjà formatées comme des lignes, donc des tuples (…,…,…).
Pour obtenir ces tuples, tu peux :
- soit les composer explicitement avec VALUES, ce qui te permet accessoirement de passer plusieurs lignes en séparant chaque tuple par des virgules : (…,…,…),(…,…,…) ;
- Soit passer directement un extrait de table si ses colonnes sont au bon format, extrait que tu peux obtenir normalement avec SELECT;
Autrement dit, après INSERT INTO, tu peux utiliser soit VALUES soit SELECT, ce qui te permet ici de gagner une étape et d'éviter d'avoir à recourir à une sous-requête au sein d'un tuple. Tu peux donc écrire directement :
Code:
2
3
4
5
Si tu n'en vois pas l'usage, c'est que tu n'as pas besoin d'une base de données relationnelle. Un fichier texte serait probablement suffisant dans ton cas, mais il serait ensuite plus compliqué d'écrire des fonctions dédiées pour le parcourir et extraire ses infos que remplir initialement une table ordinaire et l'interroger ensuite avec du SQL.Citation:
Mais je n'arrive pas à me dire que c'est mieux que d'écrire le nom explicitement.
Quoi qu'il en soit, c'est une très bonne chose de pratiquer le SQL (ne serait-ce que pour savoir écrire proprement ses requêtes) et d'interroger son serveur mais comme indiqué plus haut, de la même façon que tu utilises une interface client pour parcourir ta base, c'est une interface administrateur qui devrait te servir à la remplir. Dans cette situation, tu n'écris ta requête qu'une seule fois.
Tu n'es pas obligé non plus de faire cela en une seule opération, même si cela reste une bonne idée pour garantir l'intégrité des données si tu n'as pas posé les contraintes dans ta base, ainsi que l'atomicité de l'opération qui sont deux des quatre propriétés ACID.
Les WHERE s'appliquent effectivement à chacune des requêtes individuellement. Par contre, tu peux ensuite utiliser ORDER BY pour trier l'ensemble du résultat comme tu le ferais avec une requête ordinaire.Citation:
Ensuite pour la requête j'ai bricolé ceci…
Ca marche ... presque parfaitement.
Le bémol vient que le classement par pertinence se fait séparément sur chaque table (ce qui d'ailleurs me paraît logique) or il me semble plus logique pour mon usage d'avoir une pertinence sur les deux ensembles.
C'est un autre problème car il faut alors calculer la pertinence de chaque entrée et pour cela, il te faut une fonction qui en définisse les critères. Par la suite, tout comme avec MATCH … AGAIN qui est spécifique à MySQL, ta fonction sera utilisable à l'intérieur du SELECT, dans le WHERE, le ORDER BY et éventuellement GROUP BY et HAVING.Citation:
Comme les noms et les titres sont en général très court (la plupart du temps 2 ou 3 mots) une recherche sur un nom d'album rique de "matcher" partiellement avec des noms de groupes qui vont donc se trouver avant le "match" 100% sur le nom de l'album
Comment peut-on avoir la pertinence sur le résultat total de la recherche ?
Il se trouve que la doc indique que MATCH…AGAIN est renvoie déjà une valeur de pertinence : https://dev.mysql.com/doc/refman/8.4...-language.html
Par conséquent, tu dois pouvoir écrire ORDER BY MATCH…AGAINST. Dans le cas contraire, il faudra peut-être ouvrir un sujet dédié, en effet.
si vous allez régulièrement ajouter des entrées manuellement, le plus pratique est de faire un formulaire en php et html qui va simplifier la saisie.Citation:
Envoyé par noradan
par exemple pour simplifier le choix de l'auteur, il peut y avoir un menu déroulant avec tous les auteurs et donc lors de l'envoi du formulaire, le menu déroulant enverra l'identifiant de l'auteur au code php. et la dernière étape sera le code php qui fait une simple requête sql INSERT ... sans avoir besoin de requête imbriquée par exemple.
cette interface va dépendre des utilisateurs de votre application et de leur fonctionnalités. dans le 1er message, vous parlez de votre site personnel donc j'en déduis que vous serez le seul à remplir et mettre à jour ces données ?
Bonjour,
Nous sommes passés de la gestion d'une bibliothèque dans la question initiale à celle d'une audiothèque, une partie des remarques que j'avais formulées précédemment saute, mais il en reste.
Par exemple, il faut savoir que plusieurs groupes de musique différents peuvent porter le même nom
voir ICI
Et il y a bien évidement de très nombreux morceaux différents, d'auteurs différents, qui portent le même titre
voir LÀ
Si vous construisez un modèle de données sans tenir compte de ces faits, vous vous engouffrez dans une impasse dont il sera difficile de sortir.
Revoir la modélisation des données après avoir conçu les traitements coûte beaucoup plus cher.
Donc oubliez pour l'instant le "comment", c'est à dire les requêtes, l'utilisation ou pas de fenêtres déroulantes, etc. finalisez d'abord le "quoi"
(désolé je n'ai pas trouvé comment faire des citations "envoyé par")
En fait, mon intention est d'avoir un formulaire que des visiteurs vont remplir et je vais faire traiter ce que je reçois par un programme en python qui va fabriquer des fichiers php et htmlCitation:
le plus pratique est de faire un formulaire en php et html qui va simplifier la saisie.
J'ai lu en effet que MATCH / AGAINST calculait une pertinence et seulement et que le SELECT ne retournait que les >0 mais je ne vois pas comment concrètement rédiger cet ORDER BY MATCH avec deux tables
En l'état de mes connaissances embryonnaires sur le sql je ne vois pas d'autre façon que refaire un select * sur le tableau de résultat avec un truc du style WHERE MATCH truc AGAINST bidule OR MATCH machin AGAINST chose
en espérant que OR puisse s'utiliser comme ça. Et puis ça nécessiterait (?) de créer une table avec le tableau.
Je vais créer un sujet parce que ça m'a quand même l'air intéressant de faire une sortie par pertinence sur une union.
en bas de chaque message à droite, à coté de "répondre avec citation", il y a un bouton avec un "+" qui permet de faire cela.Citation:
Envoyé par noradan
les cas où il y a besoin de générer du code sont très rares donc il y a surement possibilité de simplifier cela.Citation:
Envoyé par noradan
n'hésitez pas à créer une nouvelle discussion à ce sujet en donnant des détails sur les différentes étapes et on pourra peut-être vous donner des conseils.