Je ne travaille pas dans mySQL mais je n'écrivent souvent SQL extrêmement complexe et voici comment je l'aborde. Tout d'abord, il n'y a pas de substitut pour comprendre parfaitement la structure de votre base de données.
Ensuite, j'essaie de décomposer la tâche en blocs. Par exemple, supposons que j'écrive un rapport concernant les détails d'une réunion (la société pour laquelle je travaille s'occupe de la planification des réunions). J'aurai besoin de connaître le nom de la réunion et le représentant des ventes, le lieu et les dates de la réunion, les personnes qui ont surveillé et les informations sur le conférencier.
D'abord, je détermine laquelle des tables aura l'information pour chaque champ dans le rapport. Maintenant, je sais ce que je vais devoir réunir, mais pas encore exactement comment.
Alors d'abord, j'écris une requête pour obtenir les réunions que je veux. C'est la base de tout le reste du rapport, alors je commence par là. Maintenant, le reste du rapport peut probablement être fait dans n'importe quel ordre, bien que je préfère travailler à travers les parties qui devraient avoir une relation en premier, alors je vais ajouter les jointures et les champs qui vont m'obtenir tous les représentants associés. information. Supposons que je ne souhaite qu'un seul représentant par réunion (s'il y a plusieurs représentants, je veux seulement le représentant principal), je vérifie que je retourne toujours le même nombre d'enregistrements que lorsque je disposais d'informations de réunion. . Si ce n'est pas le cas je regarde mes jointures et décide lequel me donne plus d'enregistrements que j'ai besoin. Dans ce cas, il peut s'agir de la table d'adresses car nous stockons plusieurs adresses pour le rep. Ensuite, j'ajuste la requête pour en obtenir une seule.Cela peut être facile (vous pouvez avoir un champ qui indique l'adresse unique spécifique que vous voulez et donc seulement besoin d'ajouter une condition où) ou vous devrez peut-être faire quelques fonctions de regroupement et d'agrégation pour obtenir ce que vous voulez.
Puis je passe au segment suivant (en travaillant d'abord à travers tous les morceaux qui devraient avoir un 1-1 relationshisp aux données centrales dans ce cas la réunion). Runthe requête nd vérifier les données après chaque ajout.
Enfin, je passe à ces enregistrements qui pourraient avoir une relation un-plusieurs et les ajouter. Encore une fois, je lance la requête et vérifie les données. Par exemple, je pourrais vérifier les données brutes pour une réunion particulière et m'assurer que ce que ma requête renvoie est exactement ce que je m'attends à voir. Supposons que dans un de ces ajouts d'une jointure, le nombre de réunions distinctes ait diminué. Oups, alors il n'y a pas de données dans l'une des tables que je viens d'ajouter et je dois changer cela pour une jointure à gauche.
Une autre fois, je peux trouver trop d'enregistrements retournés. Ensuite, je cherche à voir si ma clause where doit avoir plus d'informations de filtrage ou si j'ai besoin d'utiliser une fonction aggreagte pour obtenir les données dont j'ai besoin. Parfois, j'ajouterai temporairement d'autres champs au rapport pour voir si je peux voir ce qui cause les données dupliquées. Cela m'aide à savoir ce qui doit être ajusté. La vraie clé est de travailler lentement, de comprendre votre modèle de données et de vérifier les données après chaque ajout de nouveau morceau pour s'assurer qu'il renvoie les résultats comme vous le pensez.
Parfois, si je retourne beaucoup de données, je mettrai temporairement une clause additonal where sur la requête pour la limiter à quelques éléments que je peux facilement vérifier. Je suggère également fortement l'utilisation de l'ordre par, car il vous aidera à voir si vous obtenez des enregistrements en double.
Merci d'avoir partagé votre approche. C'est bien. :) – Das123