Discussion :

[nakwakwak]

Bonjour,
je suis en train de construire un moteur de recherche PHP/MySQL sur une base assez important de membre (entre 100000 et 500000). Cette base contient un identifiant autoincrémenté (primary) et des champs de toutes sortes (SET, booléens, int, varchar, ...). À côté, j'ai d'autres tables qui permettent d'associer un rôle à chaque utilisateur (clé étrangère sur l'ID de l'utilisateur, puis clé étrangère sur le nom du rôle qui se situe dans une autre table).

Je souhaiterais faire un moteur de recherche sur cette base d'utilisateurs qui soit relativement simple à l'usage et qui permette de faire des recherches relativement complexes sur à peu près tous les champs + en rajoutant des contraintes sur lequel l'utilisateur ne peut pas avoir accès (limitation à une certaine ville par exemple).

J'ai donc imaginé un système de grille. On pourrait faire des "ET" en ajoutant une ligne et des "OU" en ajoutant une colonne. Sur chaque cellule de la grille, on peut définir le champ sur lequel on souhaite mettre la contrainte, un opérateur (field_in_set, NOT(field_in_set()), =, !=, >, >=, <, <=) et enfin l'argument de comparaison (Exemple : "Champ Nom", "=", "Dupont"). Ce système doit en théorie me permettre de couvrir la plupart des requêtes qui m'intéressent et être suffisamment intuitif pour l'utilisateur.

Problème : je sais très bien le faire sur la table la plus importante qui contient toutes les données, mais quand il s'agit de faire des requêtes un peu plus complexes qui font intervenir des jointures, c'est plus compliqué.
Par exemple sur les rôles. Si on souhaite mettre une contrainte juste comparer un seul rôle, je peux le faire avec un simple "=", ça ne pose pas de problèmes. Maintenant si je veux les utilisateurs qui sont à la fois "Modérateurs" et "Administrateurs" (exemple farfelu, au hasard), je ne peux plus le faire comme ça. En effet, dans ma liste, j'aurais quelque chose qui sera comme ça après jointure :

ID - nom - rôle
13 - Martin - Modérateur
13 - Martin - Administrateur
13 - Martin - Utilisateur
16 - Jean - Utilisateur
16 - Jean - Modérateur

Vous comprenez facilement qu'il faut que si je veux uniquement les utilisateurs à la fois "Modérateur" ET "Administrateur", je suis coincé avec mon bête "=". Il faudrait donc que je puisse faire une sorte d'intersection sur l'ID. Le problème est le même en "OU". Et pour compliquer encore, j'ai des jointures comme ça sur d'autres tables à faire.

Bref, pensez-vous qu'il est possible de faire un tel moteur de manière un peu plus simple, ou à défaut de m'aider un peu à solutionner mes soucis ?

Merci d'avance !
nakwakwak

[nakwakwak]

Bon, vu que mon problème a l'air de faire mouche (même si il n'a pas été posté il y a très longtemps, c'est beaucoup plus réactif d'habitude), j'imagine que je me suis mal exprimé car je ne pense pas que ce soit si compliqué que ça (jusqu'à ce qu'on me dise l'inverse évidemment ).

J'ai une table (après LEFT JOIN) qui ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
user_id - user_name          - role_name
----------------------------------------
12      - Yoda               - jedi
12      - Yoda               - master
15      - Obi-Wan Kenobi     - jedi

Deux questions :
1) Comment chercher les utilisateurs qui sont à la fois "jedi" et "master". (en gros, un équivalent de la fonction "FIELD_IN_SET" dans cette situation)
2) Si c'est possible directement avec MySQL, pensez-vous qu'il est mieux de le faire avec PHP (en stockant tous les résultats d'une première requêtes "peu filtrée" dans un tableau puis en vérifiant ce qu'il y a à vérifier avec quelques boucles sur ce tableau) ou directement avec MySQL, sachant que je devrais construire ma requête dynamiquement car il s'agit d'un moteur de recherche sur des utilisateurs.

Merci !
nakwakwak

[heretik25]

Étonnant qu'un utilisateur possède plusieurs rôles.

Pour moi un administrateur est forcément modérateur et utilisateur
Un modérateur est aussi un utilisateur.

Sur l'interface tu dois pouvoir faire une combobox multi choix ou des boutons radios.

Suite à cela tu récupère les différentes possibilités et tu construis ta requête dynamiquement en conséquence.

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT bidule FROM machin WHERE role ='Admin' OR role = 'Modo'

[nakwakwak]

Étonnant ? Pas tant que ça. Certes pour les rôles que tu décris (et ceux de mon premier post par la même, du coup, mon exemple n'était certes pas très bon), c'est le cas, mais ce n'est pas une pyramide hiérarchique "simple" à une colonne qu'il me faut. Certains rôles hiérarchiques peuvent être sur la même ligne, la pyramide peut-être plus complexe. Par exemple, un modérateur n'est pas forcément un newser mais peut l'être et les pages accessibles en deviennent différentes.

La solution que tu proposes ne répond donc pas à mes besoins.
Je pense cependant avoir trouvé une solution que se présenterait sous cette forme en gros :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT * FROM matable
WHERE role IN ('Administrateur','Newser')
GROUP BY id
HAVING COUNT(DISTINCT role) >=2

Voilà, je pense que ça devrait fonctionner ainsi. Mon problème semble s'appeler "division relationnelle". Ce site russe (en anglais, rassurez-vous :p ) semble l'expliquer : http://www.sql-tutorial.ru/en/book_r..._division.html .

Une question reste cependant ouverte pour ma part : n'est-il pas plus judicieux de traiter ce problème côté PHP vu que j'ai cette opportunité ? J'ai beaucoup de mal à me faire une idée claire là-dessus.

Merci !
nakwakwak

[k'amm]

Tout dépends de la dimension de ta table comme de tes données je pense : pour une forte volumétrie, je pense qu'il ne sera pas aberrent de passer par un traitement PHP pour éviter de trop solliciter ta base.
Dans le cas contraire, ta requête est bien plus lisible, maintenable et efficace (à condition de ne pas plus la complexifier) pour garder le traitement côté SQL

[nakwakwak]

Évidemment, j'ai beaucoup simplifié le cas . Rien qu'à la base, j'ai déjà 6 jointures à faire et au moins deux divisions relationnelles.

Mais si je gère côté PHP, ce n'est pas gagné non plus. En effet, si je souhaite faire de la pagination, je vais devoir faire les mêmes requêtes à MySQL (certes, sans les HAVING) de multiples fois, sur toutes les tables et sans clause LIMIT. Donc niveau optimisation, c'est encore pire il me semble.

Je pense que je vais le faire côté MySQL (vu que même si la base est grosse, le nombre de requêtes sur la base sera mineur). Et si les utilisateurs se plaignent de lenteurs, je porterai ça en PHP;

Merci à vous
nakwakwak