Χαίρετε, καιρό είχατε να με ακούσετε ε;

Δυστυχώς αυτά συμβαίνουν όταν αλλάζεις δουλειά.

Όμως σιγά σιγά βρίσκω τα νέα βήματα μου οπότε επανέρχομαι δριμύτερος.

Σήμερα θέλω να σας κουράσω με κάτι που δεν είναι στο administration του SQL Server αλλά στο programming του. Αυτό ακούει στο όνομα Stored Procedures.

Είμαι σίγουρος ότι αν όχι όλοι οι περισσότεροι τις ξέρετε. Είμαι σίγουρος ότι υπάρχουν φανατικοί υποστηρικτές τους, όπως επίσης και άλλοι που όταν ακούνε το όνομα τους βγάζουν σπυράκια.

Εάν έχετε ποτέ εμπλακεί σε μια τέτοια κουβέντα, σίγουρα θα έχετε πάρει το μέρος κάποιας πλευράς. Όπως συμβαίνει όμως πάντα σε αυτή τη ζωή η αλήθεια είναι πάντα στην μέση. Ίσως σε αυτή την περίπτωση να γέρνει λίγο περισσότερο στην μία μεριά αλλά καλύτερα αυτό να το αποφασίσετε εσείς μετά από όλα όσα σας πω σε αυτό το post μου.

Μια σειρά από αλήθειες και μύθους έχουν φτιάξει την διαμάχη αυτή. Νομίζω όμως ότι είναι καιρός να βάλουμε τα πράγματα στην θέση τους όπως ακριβώς έχουν.

Οφείλω να ομολογήσω ότι και εγώ προσωπικά έχω εμπλακεί σε αυτή την διαμάχη, όπως οφείλω να ομολογήσω ότι είμαι θερμός υποστηρικτής της μίας εκ των δύο.

Ας πάρουμε τα πράγματα από την αρχή.

Μία Stored Procedure είναι ένα σύνολο από T-SQL statements τα οποία είναι compiled μέσα σε ένα single execution plan.

Επειδή ενδεχομένως κάποιος συνάδελφος να ρωτήσει τι είναι το execution plan παραθέτω το παρακάτω link για περισσότερη μελέτη.

http://msdn.microsoft.com/en-us/library/ms181055.aspx

Με την χρήση των SPs μπορώ να μεταφέρω την λογική που θα έγραφα μέσα σε κάποια εφαρμογή η οποία έχει να κάνει με τα δεδομένα πάνω στον SQL Server, στο σημείο δηλαδή που τα δεδομένα υπάρχουν. Απλά από την εφαρμογή μου καλώ την SP.

Το παραπάνω αποτελεί ένα από τα βασικά σημεία τριβής των εμπλεκομένων στην διαμάχη αυτή.

Οι καταγγέλλοντες τις SP λένε: "Με αυτό τον τρόπο έχω σπάσει το business logic σε πολλά διαφορετικά σημεία (data tier, middle tier) και έτσι μου γίνεται δύσκολη η ζωή στην περίπτωση που θέλω να το αλλάξω γιατί απλά δεν θα ξέρω που θα το βρω. Επίσης δεν μπορώ να έχω κάποιο έτοιμο documentation όπως αν θα το έκανα μέσα από το Visual Studio με τα διάφορα εργαλεία που αυτό έχει. Άσε που με T-SQL δεν μπορώ να κάνω όλα όσα μπορώ να κάνω με C# π.χ. Και εντάξει να κάνω χρήση των SPs αλλά τι θα γίνει στην περίπτωση που ο SQL Server είναι εξαντλημένος από resources; Η/Οι SP(s) δεν θα ανταποκρίνονται για αυτό κάνω το query/ τα queries μου και φέρνω τα δεδομένα στο middle ¨η στον client και κάνω μια χαρά την δουλειά μου."

Οι υποστηρικτές λένε: "Μα τι λες τώρα. Ίσα ίσα αυτό είναι καλό διότι η λογική μπορεί εύκολα να μοιρασθεί σε περισσότερες εφαρμογές μια και δεν θα χρειασθεί να γραφτεί ξανά μέσα σε αυτές με τον κίνδυνο του λάθους να καραδοκεί. Επίσης επειδή η SP εκτελείται στον SQL Server στο σημείο που είναι τα δεδομένα έχω καλύτερο performance και φυσικά αποσυμφορίζω το δίκτυο από traffic να μεταφέρω τα δεδομένα από τον database server στον application server και σε κάποιες περιπτώσεις και στον client με σκοπό να γίνει η επεξεργασίας τους και μετά να τα επιστρέφω στον database server, αλλά και τον client από φόρτο εργασίας."

Και τώρα μάλιστα, τα πιάσαμε τα λεφτά μας. Ποιος από τους δύο έχει δίκιο;

Εδώ λοιπόν θα βρούμε μερικούς μύθους και μερικές αλήθειες.

ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 1.

Όντως η T-SQL δεν είναι τόσο δυνατή γλώσσα όπως η C#, αλλά ο σκοπός της δεν είναι να κάνει ότι κάνει η C#. Ο σκοπός της είναι να ασχοληθεί με τα δεδομένα και σε αυτό είναι η τέλεια γλώσσα.

ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 2.

Όντως η δυνατότητα για documentation που δίνει ο SQL Server είναι αρκετά φτωχή σε σχέση με τα XML Remarks που έχω στην C#. Όμως έχω το Microsoft Visio, το Microsoft Visual Studio Database Developer Team Suite, και φυσικά μια πληθώρα από άλλα εργαλεία πχ το SQL Toolbelt της Red-Gate ή τα εργαλεία της Apex.

ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 3.

"Με αυτό τον τρόπο έχω σπάσει το business logic σε πολλά διαφορετικά σημεία (data tier, middle tier) και έτσι μου γίνεται δύσκολη η ζωή στην περίπτωση που θέλω να το αλλάξω γιατί απλά δεν θα ξέρω που θα το βρω."

Όντως αυτό είναι ένα πιθανό σενάριο που όμως θα συμβεί από κακό documentation ή κακό σχεδιασμό. Δηλαδή όταν έχει στο middle tier X τον αριθμό από classes, web services κ.λ.π. δεν έχει σπάσει την λογική σε Ν σημεία; Εκτός και αν μιλάμε για Client-Server αρχιτεκτονική όπου όλα τα έχει στον client (Fat client), όπου αφού κάνει την αλλαγή θα πρέπει να την κάνει deploy σε n clients με ότι αυτό συνεπάγεται από χρόνο και κόστος.

ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 4.

"Επίσης επειδή η SP εκτελείται στον SQL Server στο σημείο που είναι τα δεδομένα έχω καλύτερο performance και φυσικά αποσυμφορίζω το δίκτυο από traffic να μεταφέρω τα δεδομένα από τον database server στον application server και σε κάποιες περιπτώσεις και στον client με σκοπό να γίνει η επεξεργασίας τους και μετά να τα επιστρέφω στον database server, αλλά και τον client από φόρτο εργασίας."

"Και εντάξει να κάνω χρήση των SPs αλλά τι θα γίνει στην περίπτωση που ο SQL Server είναι εξαντλημένος από resources; Η/Οι SP(s) δεν θα ανταποκρίνονται για αυτό κάνω το query/ τα queries μου και φέρνω τα δεδομένα στο middle ¨η στον client και κάνω μια χαρά την δουλειά μου."

Οι υποστηρικτές σε αυτό το σημείο έχουν δίκιο όσο και οι καταγγέλλοντες που μιλάνε για την περίπτωση που ο SQL Server εξαντληθεί από resouces. Αυτό όντως θα γίνει αν ακολουθήσουμε την γενικότερη λογική των δεύτερων δλδ όχι SPs μόνο queries. Βέβαια υπάρχει και η περίπτωση που έχουμε κάνει λάθος εκτίμηση αναγκών, δηλαδή εκτιμήσαμε λιγότερο φόρτο εργασίας από αυτόν που έχουμε, ή αυτός που έγραψε την SP δεν είχε ιδέα από SQL άρα έγραφε όπως ήθελε με αποτέλεσμα να ζητάει το σύμπαν από resources. Αν τίποτα από όλα αυτά δεν συμβεί τότε NAI κερδίζω σε performance όπως επίσης και σε network traffic.

Ας δούμε όμως τι κερδίζω από την χρήση των SPs σε σχέση με την χρήση των προγραμμάτων που εκτελούν μέσα τους T-SQL.

Το αντιγράφω όπως είναι από τα BOL του SQL Server, δεν θέλω να το αλλάξω για να μην υπάρξει έστω και η παραμικρή αλλοίωση του νοήματος.

1. They are registered at the server.

2. They can have security attributes (such as permissions) and ownership chaining, and certificates can be attached to them.

3. Users can be granted permission to execute a stored procedure without having to have direct permissions on the objects referenced in the procedure.

4. They can enhance the security of your application.

5. Parameterized stored procedures can help protect your application from SQL Injection attacks.

6. They allow modular programming.

7. You can create the procedure once, and call it any number of times in your program. This can improve the maintainability of your application and allow applications to access the database in a uniform manner.

8. They are named code allowing for delayed binding.

9. This provides a level of indirection for easy code evolution.

10. They can reduce network traffic. An operation requiring hundreds of lines of Transact-SQL code can be performed through a single statement that executes the code in a procedure, rather than by sending hundreds of lines of code over the network.

Προσωπικά δεν μπορώ να φανταστώ μια εφαρμογή που δεν χρησιμοποιεί SPs.

Βέβαια ξέρω τι θα μου πει η άλλη πλευρά.

"Ναι αλλά θέλω να έχω την δυνατότητα να μιλάω από την εφαρμογή μου με τα διάφορα ORM tools (Object Relational Models) όπως LINQ, Entity Framework και οι SPs δεν μου δίνουν όλα μου δίνουν οι πίνακες". Η απάντηση μου είναι ότι δεν είναι ακριβώς έτσι τα πράγματα, σίγουρα υπάρχουν κάποια πράγματα τα οποία χάνεις όμως η εφαρμογή αγαπητοί μου συνάδελφοι δεν είναι μόνο User Interface και δεν μπορώ να θυσιάζω τα πάντα για αυτό.

Εξάλλου εάν έχω distributed εφαρμογές όλα αυτά τα εργαλεία που πραγματικά είναι ΦΟΒΕΡΑ δεν έχουν νόημα χρήσης στο UI μιας και μεσολαβεί το middle το οποίο είναι αυτό το οποίο κάνει την επικοινωνία με την βάση. Άρα η χρήση τους περιορίζεται σε αυτό και με άλλους τρόπους (δικά μας object, object lists) μεταφέρουμε τα δεδομένα στο UI.

Ελπίζω να σας έπεισα και να κάνετε χρήση των SP.