Commande SELECT pour plusieurs tables

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Commande SELECT pour plusieurs tables

par iclo » 20 mai 2005, 09:54

C'est bien gentil "beubeu" mais un mois et demi après, c'est peut-être un peu tard pour répondre à ce post...

par beubeu » 20 mai 2005, 03:39

$_POST["clef"]="exemple";

Euhhhhh :shock: :shock: :shock: , depuis quand on peux réaffecter une variable issue d'un formulaire ???

par david96 » 05 avr. 2005, 02:25

annonce :D

par Hubert Roksor » 05 avr. 2005, 02:24

Et... euh, c'est sur quelles tables déjà que tu veux effectuer ta recherche ?

par david96 » 05 avr. 2005, 02:21

Et bien merci à vous.
Hubert Roksor, le lien que tu m'as donné m'a l'air fort intéressant.

par Hubert Roksor » 03 avr. 2005, 23:06

Concernant la taille, c'est sûr que ça grossit vite... récemment je faisais des tests sur les tables d'un gros gros forum (3,1 millions de posts, 30 millions de rows dans la table "match") et les tables d'indexation font ~1Go, à comparer à un index Full-Text qui ne prendrait que ~350Mo. Avec des indexes compressés on gagne pas mal de place (dans les 20% je pense) mais ça reste de toute façon beaucoup plus gros qu'un index Full-Text du fait de la nécessité de stocker les informations en double: données des tables + index des tables là où un index Full-Text par définition ne stocke que l'index de la table.

En fait ce n'est pas une usine à gaz (une usine à gaz c'est un truc vieux, un peu poussif et qui sent pas bon) ce serait plutôt... euh... des éoliennes: c'est élégant, ça produit du courant mais c'est vrai que ça bouffe de la place. ;)

par iclo » 03 avr. 2005, 21:07

La table contenant les mots clé devient très vite très lourdes avec quasiment un tupe par mot. Et finit même par représenter la majeur partie du volume de la DB.
Je n'ai pas de solution idéale à proposer, je le reconnais, vu que je n'ai jamais eu le problême :D :D :D :D :P :P :P :P :P , mais je m'interroge sur la faisabilité de ce sytême sur des sites à très gros volume.

par Hubert Roksor » 03 avr. 2005, 18:15

La vraie question est: existe-t'il une relation entre les tables ? car jusqu'à présent je n'en vois pas dans ton code. Dans ce cas tu aurais mieux fait d'exécuter une requête par table, sinon il serait bon de poster la structure (simplifiée, inutile d'inclure tous les champs) des tables en questions et la vraie requête que tu utilises.

Quant à utiliser une table de recherche, je suis 100% pour. (d'ailleurs iclo, si tu voulais développer "ça devient très vite l'usine à gaz" ça m'intéresse) Pour indexer le texte contenu dans la table Machin la structure des tables pourrait ressembler à: (clés primaires en gras)
Table Machin
machin_id INT
machin_text TEXT

Table words
word_id INT
word_text VARCHAR(20)

Table match
machin_id INT (->Machin.machin_id)
word_id INT (->words.word_id)
Tu peux avoir une description de cette approche dans cet article de Frédéric Brouard [ Indexation documentaire & bases de données ].

Reste un problème: ce modèle ne peut servir qu'à indexer une seule table. Pour en indexer plusieurs tu dois avoir recours à une troisième table d'indexation (et modifier la seconde):
Table documents
doc_id INT
doc_type ENUM('Machin', 'Truc')
foreign_id INT (->Machin.machin_id, ->Truc.truc_id) (ce champs ne peut pas être une contrainte étant donné qu'il lie la table à plusieurs autres tables)

Table match
doc_id INT (->documents.doc_id)
word_id IN (->words.word_id)
Petit exemple, pour retrouver tous les documents (posts de ton forum, bio de tes utilisateurs, description d'un produit, etc...) comportant les mots 'flan' (word_id 8) ET 'caramel' (word_id 12) tu exécuteras:

Code : Tout sélectionner

SELECT word_id, word_text FROM words WHERE word_text IN ('flan', 'caramel')

Code : Tout sélectionner

SELECT d.doc_id, d.doc_type FROM match m1, match m2, documents d WHERE m1.word_id = 8 AND m2.word_id = 12 AND m2.doc_id = m1.doc_id AND d.doc_id = m1.doc_id
Ensuite, grâce aux IDs et au type de document doc_type tu pourras récupérer les textes en question si tu souhaites les afficher. Le cadeau bonux de cette méthode c'est que si quelqu'un tape un mot qui n'existe pas tu le sais très rapidement car il n'est tout simplement pas indexé. Si tu as des questions spécifiques j'essaierai d'y répondre quand je repasserai.

par Invité » 03 avr. 2005, 16:20

out dépend du volume de donnée, mais pour un forum phpbb ça devient très vite l'usine à gaz...

Sinon, tu n'as toujours pas répondu à ma question : tes tables ont-elles toutes une structure identique : même liste de champs ??
Elles ont tous en commun le champ ID

par iclo » 03 avr. 2005, 12:28

out dépend du volume de donnée, mais pour un forum phpbb ça devient très vite l'usine à gaz...

Sinon, tu n'as toujours pas répondu à ma question : tes tables ont-elles toutes une structure identique : même liste de champs ??

par david96 » 03 avr. 2005, 02:59

:lol:
Et que pensez vous de ma solution (Créer une table dédié aux mots clefs) ?

requête SQL:
CREATE TABLE 'mot_clef'
 (
'mot_clef_id' INT( 8 ) NOT NULL AUTO_INCREMENT ,
'mot_clef_nom' VARCHAR( 40 ) NOT NULL ,
PRIMARY KEY ( 'mot_clef_id' ) ,
UNIQUE ('mot_clef_nom')
);

par flitox » 02 avr. 2005, 20:22

mais laisse tomber. En fait je me suis compliqué la vie :lol:
On avait pas remarqué :roll: :wink:

par david96 » 02 avr. 2005, 20:02

Ouaich, en fait au lieu de me compliquer et en même temps vous prendre la tête :oops: .

Je vais créer une table spécial mots clefs, comme ça plus de souci :D

En tous cas merci à tous pour votre aide et votre patiente.

iclo elles ont toutes en commun une clef secondaire (ID), mais laisse tomber. En fait je me suis compliqué la vie :lol:

par iclo » 02 avr. 2005, 19:04

ok, mais ces différentes tables ont des structures identiques ?
Si oui, tu as problême, au niveau de la conception même de ta Db...

par flitox » 02 avr. 2005, 18:57

Je t'ai déjà expliqué que si tu utilises les champs de plusieurs tables, tu dois spécifier la table à laquelle il appartient.

table.champ

Sinon comment veux-tu qu'il sache à qui elle appartient?