Il serait préférable de réécrire la requête comme suit:
SELECT payments.*
FROM customers
JOIN payments
ON payments.id_customer = customers.id
WHERE customers.id_project = 5
Bien que cela semble moins concis et qu'un bon planificateur de requêtes verra ce que vous essayez de faire et exécutera votre sous-requête corrélée comme la jointure ci-dessus à la place, un mauvais planificateur de requêtes peut finir par faire un balayage d'index de payments.id_customer
(en supposant que vous avez un index pertinent ) (ou pire, l'analyse de table) au lieu de faire les choses de la manière la plus efficace. Même un bon planificateur de requêtes peut ne pas voir l'optimisation si l'arrangement de cette requête est enveloppé dans quelque chose de plus compliqué. Exprimer la relation sous la forme d'une jointure plutôt que d'une sous-requête peut faire plus de différence que de modifier votre structure de données.
Comme Jeff le dit, toute dénormalisation doit être considérée avec soin - elle peut apporter des gains de performances faciles, en particulier à certaines fins de génération de rapports, mais peut entraîner des incohérences en raison de bogues dans la logique métier de support.
En remarque: de toute évidence, je ne connais pas votre entreprise, donc je pourrais manquer quelque chose, mais vos relations avec la table me semblent étranges. Ils impliquent que vous ne pouvez jamais avoir plus d'un projet avec le même client, ce qui n'est généralement pas vrai dans mon expérience, au moins sur une longue période.
customer project payment
-------- -------- -------
pa_id
pr_id <-- payment
cu_id <-- customer
ou si elle est moins normalisée (bien que je doute que cela soit nécessaire):
customer project payment
-------- -------- --------
pa_id
pr_id <-- payment
cu_id <-- customer
`------------- customer
Bien sûr, cela exclut toujours la possibilité d'un projet commun avec deux clients ...