Une "grosse" table ou deux plus petites

[ChriGoLioNaDor]

Bonjour,

Je me pose une question existentielle ^^

J'ai deux types d'utilisateurs. D'un côté, des acheteurs, de l'autre, les vendeurs.

J'hésite entre deux solutions :
1/ créer une table "inscrit" reprenant les informations communes (nom, prénom, civilité, adresse), puis une table pour chaque type de compte (une table "acheteurs", et une autre "vendeurs") avec les informations spécifiques à ce type de compte;
2/ ne créer que les tables "acheteurs" et vendeurs", avec pour chaque table les champs nom, prénom, civilité etc.

La première solution me permet d'avoir un identifiant unique pour chaque utilisateur, quel que soit son type de compte. C'est pratique pour les pages accessibles à la fois aux vendeurs et aux acheteurs, pour les repérer. De plus, si un utilisateur a à la fois un compte acheteur et un compte vendeur, les modifications faites sur un compte pourraient affecter le second (par exemple en cas de changement d'email).
Par contre, je dois utiliser des jointures à chaque fois que je recherche uniquement des vendeurs ou des acheteurs, ou encore pour afficher la fiche d'un acheteur ou d'un vendeur. Je sais bien que des jointures bien gérées ne sont pas bien gourmandes en ressource (si on a des index et des clés bien placées), mais j'essaie de les éviter tant que possible afin de gagner en lisibilité de mes requêtes, et pour éviter d'avoir 36 jointures par requête.

La seconde solution évite ces jointures, et me permet d'avoir deux tables bien distinctes et plus petites à parcourir. Par contre, ne pas avoir d’identifiant "universel" est un peu gênant, car si le fait de savoir que l'utilisateur n°35 a laissé un message sur le livre d'or ne permet pas de savoir s'il s'agit du vendeur n° 35 ou de l'acheteur. Je suis donc obligé de "ruser" en ajoutant une lettre à l'identifiant dans certaines tables afin de différencier les vendeurs des acheteurs (si l'utilisateur v35 a laissé un commentaire, je sais vais chercher le nom de l'utilisateur 35 dans la table "vendeurs"). Ça fonctionne bien, mais je dois à chaque fois repérer s'il s'agit d'un vendeur ou d'un acheteur, pour ensuite adapter ma requête.
Enfin, je me retrouve avec deux tables (acheteur et vendeur) ayant une majorité des champs quasi similaires.

Bref, j'aurais besoin d'un point de vue extérieur. D'après vous, quelle est la meilleure solution en termes de performances et de maintenabilité?

[qi130]

La 1ère bien sûr !

Ca évite la redondance (nom, prénom, etc.); et puis tes jointures ne feront pas 3 kilomètres, vu la simplicité du modèle

[ChriGoLioNaDor]

Merci de ta réponse.

Concernant la simplicité du modèle, j'ai bien entendu simplifié la chose pour aller à l'essentiel et simplifier la compréhension du problème. Par exemple pour l'affichage d'un article, j'ai besoin de données dans les tables "utilisateurs", "vendeurs", "biens_en_vente", "frais_de_port", ... Donc si je veux faire une unique requête me sortant toutes les données, je me retrouve avec des fois 3 ou 4 jointures.

Justement, je me demandais si dans ce cas, il vaut mieux faire une requête "complexe" me sortant l'ensemble des informations, ou exploser ma requête en plusieurs (une cherchant les infos concernant le vendeur dans les tables "utilisateurs et vendeurs", une autre recherchant les infos de l'objet vendu, et une troisième recherchant les frais de port en fonction de la localisation du vendeur par rapport à l'acheteur...
Je me rends compte que j'ai tendance de plus en plus à faire plusieurs requêtes "simples" car c'est plus lisible, plus facile à déboguer, et ça me permets de stocker les choses dans des variables séparées (pratique ensuite pour la relecture, quand on a une variable $avis qui regroupe les avis, $vendeur qui regroupe les infos sur le vendeur etc ^^). Mais je me demande si au niveau de php, le fait de faire plusieurs requêtes ne consomme pas plus de ressources...

[Maljuna Kris]

Saluton,
KISS, l'info qu'il faut, quand il faut, là où il faut.

[CinePhil]

Pour ne pas avoir à faire, parfois plusieurs fois des requêtes avec de multiples jointures dans ton code, utilise des vues.

[ChriGoLioNaDor]

Maljuna Kris > En effet, je suis d'accord sur le principe qu'il faut privilégier la simplicité à l'optimisation à outrance. Cependant, je pense qu'il est important de connaître l'impact de ses choix sur les performances du système, afin de privilégier les solutions "optimisées", quand elles ne nuisent pas ou peu à la simplicité.

CinePhil > Oui en effet, les vues peuvent être pratiques dans certains cas. Mais ma question était plus axée sur les performances : est-il plus coûteux d'avoir des requêtes "complexes" avec 3, 4, 5 jointures (sur des clés primaires ou des index), ou plusieurs requêtes "basiques" avec moins de jointures?

En effet, j'ai déjà entendu les deux versions : certains semblent dire que si les jointures sont bien faites (sur des index et des clés primaires), le fait de ne faire qu'une seule requête évite de devoir contacter plusieurs fois le serveur MySQL pour chaque requête; d'autres semblent dire qu'en faisant de grosses requêtes, ça consomme plus de mémoire et donc le serveur peut plus rapidement saturer... Donc j'aurais aimé avoir des avis complémentaires de personnes expérimentées

[CinePhil]

Envoyé par ChriGoLioNaDor

est-il plus coûteux d'avoir des requêtes "complexes" avec 3, 4, 5 jointures (sur des clés primaires ou des index), ou plusieurs requêtes "basiques" avec moins de jointures?

La jointure est l'opération la plus optimisée dans un SGBD.

Imaginons :
- 3 tables concernées A, B, C de, respectivement, 2000 lignes, 30 lignes, 150 000 lignes ;
- Une clause WHERE qui va filtrer 10% de la table A et 10% de la table B ;
- Un résultat final de 100 lignes de 100 octets.

Solution 1 : une requête avec 3 deux jointures
1) Envoi de la requête au serveur => flux de quelques centaines d'octets.
2) Plan d'exécution de la requête :
- filtrage des données pour réduire le nombre de lignes à traiter
- jointures
- recherche du résultat
3) Envoi du résultat au programme => 100 lignes de 100 octets.
4) Le programme n'a plus qu'à présenter les données à l'utilisateur.

TOTAL : 10 000 et quelques centaines d'octets

Solution 2 : requêtage séparé des trois tables et traitement des données par le programme
1) Envoi de la requête sur A => flux de quelques dizaines d'octets.
2) Exécution de la requête et envoi de 10% des lignes de A => 200 lignes de quelques dizaines d'octets.
3) Requête sur B => Flux de quelques dizaines d'octets.
4) Exécution de la requête et récupération de la totalité de la table B => Flux de 30 x quelques dizaines d'octets.
5) Requête sur C => Flux de quelques dizaines d'octets.
6) Exécution de la requête et récupération de 10% des lignes de C => 15 000 x quelques dizaines d'octets.
7) Traitement des données par le programme pour assembler les données et obtenir les 100 lignes de résultat voulues.
8) Présentation des données à l'utilisateur.

Est-il besoin que je fasse le calcul de la seconde solution ?

Conclusion : Le traitement des données, c'est le boulot du SGBD !
Certes, il arrive que certaines requêtes soient grosses et longues à exécuter mais souvent, avant de se demander s'il ne vaudrait pas mieux le faire en plusieurs requêtes, il est bon de vérifier si on ne peut pas modifier la requête, vérifier l'indexation des tables impliquées, voire même réviser son modèle de données si on en a la possibilité sans casser tout le programme déjà en production.
D'où l'intérêt encore des vues car si les programmes n'interrogent que des vues, on peut modifier le modèle de données sans influence sur les programmes.

Donne un exemple précis de ce que tu souhaites faire et dont le traitement t'inquiète et nous te donneront des pistes de solutions appropriées.