L'utilisateur peut rechercher par code postal (par exemple: L14, L15, L16) ou emplacement à partir d'une zone de texte.
Si Type d'utilisateur dans "Liverpool", il trouvera tous les magasins situés dans "Liverpool". Si le type d'utilisateur dans le code postal (par exemple: L15), il effectuera tous les magasins qui effectuent la livraison dans la zone de code postal L15. P>
Voir les tableaux ci-dessous: P>
+----+----------+-----------+----------+---------------+--------------+ | id | name | location | postcode | delivery_cost | AreaPostcode | +----+----------+-----------+----------+---------------+--------------+ | 1 | Shop One | Liverpool | L10 | 1.00 | L12 | +----+----------+-----------+----------+---------------+--------------+
4 Réponses :
Qu'est-ce que je manque?
Pourquoi ne pouvez-vous pas faire
Cela ne fonctionnerait pas correctement, sinon vous obtiendrez de nombreuses lignes de même noms de magasins. Jetez un coup d'œil à rejoindre s soiptement.
L'utilisation d'un ou peut tuer les performances en fonction de la manière dont les index sont utilisés. Je vais généralement scinder une requête en un "code> union comme ceci pour éviter un ou et obtenir le gain de performance substantiel d'utiliser un index dans chaque partie de l'union .
@DieGo, il vous manque une restriction quand il est shops.Location = "liverpool" .
Il suffit d'ajouter une autre contrainte sur le test de localisation pour éviter cela comme da.postcode = shops.postcode
Étant donné que toutes les tables et toutes les colonnes sélectionnées sont les mêmes, vous pouvez simplement le faire:
SELECT DISTINCT shops.*, DA.delivery_cost, DA.postcode AS AreaPostcode FROM shops
JOIN shops_delivery_area as DA on DA.shop_id = shops.id
WHERE (DA.postcode = "Liverpool")
OR (DA.postcode = shops.postcode AND shops.location = "Liverpool")
Veuillez essayer ceci:
SELECT DISTINCT shops.*,
DA.delivery_cost,
DA.postcode
FROM shops
JOIN shops_delivery_area as DA on DA.shop_id = shops.id
WHERE DA.postcode = "Liverpool"
OR (location = "Liverpool" and DA.postcode = shops.postcode)
Quel que soit votre choix, sachez que le code court n'est pas toujours un code optimal. Dans de nombreux cas, où vous avez une logique suffisamment divergente, l'Union des résultats est vraiment l'option la plus optimale (et parfois la plus propre, par programme).
qui dit, le suivant ou dans la clause où semble couvrir vos deux cas. . P>
SELECT DISTINCT
shops.*,
DA.delivery_cost,
DA.postcode AS AreaPostcode
FROM
shops
INNER JOIN
shops_delivery_area as DA
ON (DA.shop_id = shops.id)
WHERE
(DA.postcode = "Liverpool")
OR
(DA.postcode = shops.postcode AND shops.location = "Liverpool")
Merci! Alors, qui serait une meilleure option dans la performance sage? Coller avec union ou ou dans la clause WHERE
Je viens de faire des tests de performance. Il apparaît en utilisant Union est plus rapide.
@ user791022 Sayd Je viens de faire des tests de performance. Il apparaît à l'aide de l'Union est plus rapide. Je vous l'ai dit. Qu'est-ce qui est plus rapide deux hits d'index au milieu d'une table ou un scan de la table entière? Lorsque vous appliquez une pensée «Application» (réduisez le code redondant, etc.) à SQL, vous rencontrez des problèmes de performances.
@Km. - Pendant que je suis d'accord avec vous sur les détails techniques, je n'ai également appris que cette leçon en se révélant. Comme ma connaissance de SQL a grandi, j'ai cherché des moyens novateurs de raccourcir le code. C'est à ce moment-là que j'ai découvert des plans d'exécution et comment ils se rapportent (ou non) à ma compréhension de SQL. Je pense que c'est bien que l'OP cherche constamment mieux . Je suis même content que l'OP stimule ce que les autres disent et résolvent des preuves impérieuses contre les théories et ce que disent d'autres.
Quelle mission avez-vous pour éviter
union ? p.s. Je pense que vous pouvez supprimer les mots-clésdistincts carUnion est court pourUnion distinct .