Αυτό το "κάτι" λέγεται ORM: οποιοδήποτε ORM υποστηρίζει σχέσεις μεταξύ των κλάσεων μπορεί να φτιάξει τα κατάλληλα statements εκμεταλλευόμενο αυτά τα relations.
Από ένα χύμα select είναι πολύ δύσκολο να το κάνεις αυτό επειδή δεν είναι ποτέ ξεκάθαρο ποιές είναι οι σχέσεις. Ένα join μπορεί να σημαίνει ότι δύο πίνακες συνδέονται άμεσα (π.χ. order και orderline) χωρίς όμως να φαίνεται ποιός είναι ο parent (που πρέπει να γίνει πρώτα insert/update, τελευταίος delete) και ποιός ο child (το αντίστροφο). Μπορεί πάλι η σύνδεση να γίνεται μέσω ενός many-to-many πίνακα, οπότε στην ουσία γίνονται join τρεις πίνακες, και είναι ο μεσαίος που πρέπει να πειραχτεί πρώτα κλπ, κλπ, κλπ.
Johnny, αυτό που ζητάς λύθηκε οριστικά όταν εμφανίστηκαν τα ORMs. Πριν από αυτά, τον καιρό της VB6, μπορούσες να δώσεις ένα select statement σε ένα recordset και να δεις ποιοί πίνακες χρησιμοποιούνταν. Και πάλι όμως, εκτός και αν έκανες ανάλυση των foreign keys ή αν βασιζόσουν σε naming conventions, δεν μπορούσες να φτιάξεις τα statements με ασφάλεια. Αν βέβαια σχεδίαζες εσύ τη βάση φρόντιζες τα ονόματα να είναι τέτοια ώστε να καταλαβαίνεις τί γίνεται.
Μετά, βγήκαν οι code generators οπότε από ένα μοντέλο με τα κατάλληλα στοιχεία (πίνακες, πεδία, parents, children, many-to-many) μπορούσες να φτιάξεις τους πίνακες, τα stored procedures και τον κώδικα που τα καλούσε με τη μία. Φυσικά, κάθε φορά που άλλαζε το σχήμα της βάσης έπρεπε να ξανακάνεις generate τον κώδικα.
Τέλος, ήρθαν τα ORM τα οποία ουσιαστικά κάνουν τη δουλειά του generator στο runtime και εσύ φροντίζεις μόνο να είναι σωστό το μοντέλο σου.
Αυτό που ΠΟΤΕ δεν έπαιξε σοβαρά ήταν ο SqlCommandBuilder. Όποιος χρησιμοποιούσε datasets δεν τον χρειαζόταν ενώ όποιος είχε πιο προχωρημένες ανάγκες που χρειάζονταν χύμα SQL δεν τον ήθελε γιατί το μόνο που μπορούσε να σου δώσει ήταν απλά-χαζά statements.
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos