Παράδειγμα πρώτο (Χωρίς χρηση Virtual Table):

 SELECT * FROM myTableName_1 WHERE ID IN (SELECT ID FROM myTableName_2)

Παράδειγμα Δεύτερο (Με χρήση Virtual Table):

 SELECT a.* FROM myTableName_1 a,(SELECT ID FROM myTableName_2) AS b WHERE a.ID = b.ID

Παράδειγμα τρίτο (Nesting Virtual Table):

 SELECT a.*  FROM myTableName_1 a, (SELECT ID FROM myTableName_2 t,(SELECT c.eID FROM myTableName_3) AS c
WHERE t.ID = c.eID) AS b WHERE a.ID = b.ID

---

Ιωάννης Μανουσάκης

Μήπως να τα εξηγούσες λίγο περισσότερο;

---

Χρήστος Γεωργακόπουλος

Και για ποιον λόγο να μην κάνεις join τους πίνακες που είναι πιο απλό;

Aν μεταφέρουμε τα queries στην Northwind, για παράδειγμα το πρώτο και το δεύτερο γίνονται:

SELECT od.* FROM [order details] od ,(SELECT OrderID FROM Orders) AS O WHERE od.OrderID = o.OrderID

SELECT od.* FROM [order details] od INNER JOIN Orders o
ON od.OrderID = o.OrderID

παράγουν το ίδιο execution plan όπως το

SELECT od.* FROM [order details] od INNER JOIN Orders o
ON od.OrderID = o.OrderID

Το query engine του SQL Server είναι απίθανο! Μία από τις φάσεις που περνάει το statement όταν πρόκειται να το εκτελέσει είναι το optimization. Ενδεχομένως σε κάποια άλλη database να παίζει ρόλο αν θα γράψεις το query με τον έναν ή τον άλλον τρόπο, αλλά στον SQL Server όλοι οι τρόποι οδηγούν στα joins

Άρα λοιπόν θα πρέπει να λύνεις κάποιο συγκεκριμένο πρόβλημα για να μην επιλέξεις joins, πχ να γράφεις cross db platform statements. Εσωτερικά τώρα, τα joins υλοποιούνται με διάφορους τρόπους από το query engine, ανάλογα με τα περιεχόμενα των πινάκων που γίνονται join. Ένας από τους τρόπους αυτούς είναι με χρήση hash tables - πολύ χοντρικά κάτι σαν virtual tables - αλλά ο τρόπος που θα επιλέξει τελικά να κάνει join εξαρτάται από τα ίδια τα περιεχόμενα τών πινάκων (τι indexes έχουν, αν είναι ταξινομημένα ή όχι, τι κατανομή έχουν οι τιμές, κλπ).

Παρεπιπτόντως, το query engine συνεχώς βελτιώνεται όχι μόνο από έκδοση σε έκδοση αλλά από SP σε SP. Η ομάδα του SQL Server σε συνεργασία με μεγάλους οργανισμούς που χρησιμοποιούν SQL Server, λαμβάνει δείγματα από πραγματικά δεδομένα και τα queries που χρησιμοποιούν και βελτιστοποιεί συνεχώς τον τρόπο που δουλεύει το engine!

---

Vir prudens non contra ventum mingit

Δέν θα διαφωνίσω μαζί σου.

Απλά ανέφερα την τεχνική των Virtual tables που ουσιαστικά είναι ένα select query αναφερόμενο ώς πίνακας στο where clause του select statement .

Απλά νομίζω χρησιμοποιώντας τα Virtual tables έχουμε είνα πιο αποδοτικό από την χρησιμοποίηση Temp Tables ή ένα ΙΝ (SELECT ...) μέσα στό select statement.

Ξέρω οτι το παράδειγμα που έδειξα είναι απλοϊκό αλλά εάν περάσεις σε πιο σύνθετα queries και σχέσεις πινάκων αυτός είναι ένας βολικός τρόπος.

---

Ιωάννης Μανουσάκης

Από Temp Tables σίγουρα, από IN clause πάλι παίζεται...

Γενικά, τα περισσότερα queries που γράφουμε υλοποιούνται με πολλούς εναλλακτικούς τρόπους και γι αυτό είναι καλό να γνωρίζει κανείς να ερμηνεύει το execution plan έτσι ώστε να δοκιμάζει μερικούς από αυτούς τους τρόπους και να βρίσκει τον καλύτερο. Επίσης, σημαντικό είναι να θυμόμαστε ότι μια τεχνική που παίζει καλά σε έναν πίνακα, μπορεί να μην είναι η καλύτερη για κάποιον άλλον καθότι αυτό που παίζει ρόλο είναι, όπως προανέφερα, η φύση των δεδομένων.

---

Vir prudens non contra ventum mingit

KelMan wrote:

Γενικά, τα περισσότερα queries που γράφουμε υλοποιούνται με πολλούς εναλλακτικούς τρόπους και γι αυτό είναι καλό να γνωρίζει κανείς να ερμηνεύει το execution plan

Μάνο δεν ρίχνεις κάτι σχετικό με την ερμηνεία των plans όταν προλάβεις;

---

Πάνος Αβραμίδης

Είναι καλό project... Αλλά δεν μπορώ να υποσχεθώ για κάτι άμμεσο...
Μπαίνει στο ToDo list.

---

Vir prudens non contra ventum mingit

Δεν μπορώ να πω ότι κατάλαβα την τεχνική. Φαίνεται σαν μια προσπάθεια να αναγκάσεις τον optimizer να κάνει το query με συγκεκριμένο τρόπο. Αυτό όμως δεν πιάνει καθώς ο optimizer του SQL Server δημιουργεί το ίδιο execution plan για όλες τις περιπτώσεις, όπως ανέφερε ο Kelman. Η μορφή του execution plan εξαρτάται από τα στατιστικά των πινάκων και των indexes, όχι από τη μορφή του sql.

Ο optimizer μπορεί να επιλέξει οποιοδήποτε τρόπο για να εκτελέσει το query με το γρηγορότερο τρόπο, ακόμα και να δημιουργήσει temp tables. Ο πιο αποτελεσματικός τρόπος για να βελτιώσεις την απόδοση του query είναι να δημιουργήσεις καλύτερα indexes και να βελτιώσεις το σχήμα της βάσης.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Και ο Μάνος και εσύ Παναγιώτη έχετε δίκιο τελικά.
Λάθος μου που δέν κοίταξα το EXECUTION PLAN

---

Ιωάννης Μανουσάκης