Αφορμή για αυτό το post ήταν δύο γεγονότα τα οποία μου συνέβησαν το τελευταίο διάστημα. Το ένα ήταν μια «διαμάχη» με έναν συνάδελφο σχετικά με το γεγονός ότι πλέον δεν υποστηρίζεται πλέον στον SQL Server 2012 η sp_dboption, και το άλλο είναι ένα προσωπικό μήνυμα που έλαβα από κάποιον άλλο συνάδελφο σχετικά με το αν θα πρέπει να χρησιμοποιείται το semicolon στο τέλος των εντολών της T-SQL.
Δεν ξέρω αν το γνωρίζεται αλλά σε κάθε έκδοση του SQL Server που βγάζει η Microsoft μέσα στα books online υπάρχει ένα section το οποίο ονομάζεται Deprecated Features. Για τον SQL Server 2012 και για το Database Engine θα βρείτε αυτά στο link αυτό. Σε αυτό υπάρχει μια πλήρης λίστα αυτών που σε επόμενες εκδόσεις δεν θα υπάρχουν πλέον.
Τι σημαίνει όμως αυτό το σε επόμενες εκδόσεις;
Αυτό σημαίνει ότι μετά από δύο ή περισσότερες εκδόσεις του SQL Server αυτά που αναφέρονται θα σταματήσουν να υφίστανται. Χρονικά αυτό σημαίνει πάνω από 5 χρόνια, άρα έχουμε στην διάθεση μας αρκετό χρόνο ώστε να εναρμονιζόμαστε με αυτά χωρίς άγχος που δεν είναι σύμβουλος καλός όπως καλά γνωρίζουμε όλοι μας.
Θα είδατε ή θα δείτε από το link που αναφέρω παραπάνω ότι σε όλα σχεδόν αναφέρει και πως πρέπει να αντικατασταθεί το feature που γίνεται deprecated.
Γράφοντας αυτές τις γραμμές ήδη ακούω στα αυτιά μου τις φωνές και τις διαμαρτυρίες πολλών συναδέλφων ότι έτσι σπάει το backward compatibility. Σε αυτό όμως δεν θα συμφωνήσω αν και καταλαβαίνω ότι για να εναρμονιστεί κάποιος με όλα αυτά απαιτείται και χρόνος και χρήμα καθώς θα πρέπει να γαζώσει στην κυριολεξία τον κώδικα του εντοπίζοντας τα deprecated features και αλλάζοντας τα με τα νέα.
Δεν θα συμφωνήσω καθώς όπως είπα και παραπάνω το παράθυρο το οποίο έχουμε ώστε να κάνουμε τις αλλαγές αυτές είναι τουλάχιστον μια πενταετία. Χρόνος ικανός ώστε με την ησυχία μας να κάνουμε σωστά και με δοκιμές τις αλλαγές που χρειάζονται. Δεν μπορώ να δεχθώ με τίποτα όμως ότι σαν επαγγελματίες που είμαστε δεν κοιτάζουμε αυτά και δεν προνοούμε πριν μας σφίξουν τα γάλατα όπως λένε και στο χωρίο της μάνας μου.
Μα θα μου πει κάποιος εμείς δεν έχουμε πρόσβαση στον κώδικα καθώς έχουμε αγοράσει κάποιο έτοιμο πακέτο κλπ. Και εδώ πάλι την ίδια άποψη έχω καθώς ο κατασκευαστής είναι υποχρεωμένος να κάνει την έρευνα του και όπου χρειάζεται να προχωρήσει στις απαραίτητες αλλαγές.
Θα αναφέρω απλά ότι για την sp_dboption από την έκδοση του SQL Server 2005 έχουν πει ότι αυτή πρόκειται να «πεθάνει» όπως και έγινε στον SQL Server 2012. Άρα κατά την άποψη μου δικαιολογίες δεν υπάρχουν. Αλλά ακόμα και έτσι προς επίρρωση των λεγομένων μου θα θέσω ένα ερώτημα και ας το απαντήσει ο καθένας σας μόνος του αλλά τίμια μέσα του και αυτό είναι το εξής:
Πόσο είναι το κόστος σε ένα μεγάλο πρόγραμμα να συντηρώ κώδικα που έχει ξεπεραστεί επειδή έχω βρει και έχω υλοποιήσει καλύτερους τρόπους για να λύσω το πρόβλημα που αυτός έλυνε;
Ας έρθω όμως στο θέμα του post αυτού. Για τον ίδιο ακριβώς λόγο από την έκδοση του SQL Server 2008 η Microsoft έχει πει ότι θα πρέπει να τελειώνουμε τα statements μας με semicolon (;) και ότι αυτό θα είναι απαιτητό σε επόμενες εκδόσεις.
Επειδή αυτό είναι κάτι το οποίο το έχουν ήδη πει ήδη εδώ και 4-5 χρόνια αλλά ακόμα δεν έχει γίνει κανόνας ακόμα και στον SQL Server 2012 θεωρώ ότι θα γίνει στην επόμενη έκδοση. Για το λόγο αυτό καλό είναι να αρχίσει να μας γίνεται συνήθεια να τελειώνουμε αυτά που γράφουμε με semicolon.
Ο λόγος που γίνεται αυτό είναι το γεγονός ότι από τον SQL Server 2005 εμφανίστηκαν κάποιες εντολές όπως η WITH στα CTE ή SEND στο Service Broker που για να μη γίνει καμία παρανόηση στον parser έπρεπε μπροστά από αυτές να υπάρχει semicolon καθώς αυτές στέκονται σαν εντολές μέσα σε άλλα statements. Αναφέρω ενδεικτικά για την WITH την οποία μπορείτε να την βρείτε σε πολλά CREATE , ALTER statements αλλά και στις BACKUP/RESTORE εντολές.
Φυσικά μέσα στις φωνές για τις οποίες αναφέρθηκα παραπάνω ακούω και άλλες από συναδέλφους που εργάζονται με άλλα RDBMS και που αυτό το έχουν σαν απαίτηση εδώ και χρόνια, αλλά και αυτών που το επικροτούν καθώς έρχονται από ένα background C / C++ / C#.
Όπως και να έχει και παρόλη την πιθανή ταλαιπωρία θα πρέπει να επισημανθεί ότι αυτό είναι ANSI/ISO Standard και η χρήση του κάνει περισσότερο ξεκάθαρο τον κώδικα που γράφουμε αλλά και μας βοηθάει στον αποφευχθούν τυχόν προβλήματα ambiguity / assumptions στον parser.
Για όλους τους παραπάνω λόγους δεν είναι κακή πρακτική πλέον να αρχίσουμε σε ότι νέο φτιάχνουμε να το χρησιμοποιούμε ώστε να γίνει μέρος της ζωής μας και να το συνηθίσουμε και παράλληλα να διορθώνουμε σιγά σιγά το παλαιό μας κώδικα.
/*antonch*/
SQLschool.gr Old 