Δεν είναι σπάνιο το φαινόμενο να πέφτω πάνω σε databases που έχουν σχεδιαστεί στην κυριολεξία στο πόδι. Σε πολλές από αυτές, άλλοτε εύκολα, άλλοτε  με σχετικά μη επώδυνο τρόπο,  κατάφερα να αλλάξω τον σχεδιασμό τους. Υπάρχουν όμως  αρκετές που αυτό δεν ήταν εφικτό.

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

Κατά τον σχεδιασμό μιας database δεν φτάνει μόνο να αποτυπώσουμε τις οντότητες (entities/tables) που θα την αποτελέσουν, αλλά θα πρέπει να σκεφτούμε και να συμπεριλάβουμε σε αυτό και στοιχεία όπως το πώς θα ερωτηθούν οι οντότητες αυτές, πώς θα γίνονται τα transactions σε αυτές, αλλά κυρίως να λάβουμε σοβαρά υπόψη την αρχιτεκτονική του RDBMS στην οποία αυτή η database θα ζει.

Δυστυχώς στην πράξη σπάνια αυτά λαμβάνονται υπόψη, με αποτέλεσμα στην πράξη να έχουμε databases με κακή απόδοση, δύσκολα συντηρήσιμες και κυρίως να μην μπορούν να καλύψουν 100% τις ανάγκες για τις οποίες είχαν σχεδιαστεί.

Δεν μπορώ όμως να κατηγορήσω κανέναν για αυτό. Όλοι μας  έχουμε κάνει λάθη. Κάποια στιγμή όμως πρέπει να σταματήσουμε να τα κάνουμε. Για να γίνει αυτό δεν χρειάζεται να κάνουμε τίποτα ιδιαίτερο, απλά να σταματήσουμε να θεωρούμε τις databases σαν κουβά και τον σχεδιασμό αυτών  task χωρίς ενδιαφέρον.

Μέσα από τις σπουδές μας ή την προσωπική μας επιμόρφωση έχουμε μάθει ότι οι databases διέπονται από κανόνες και αρχές. Θα έχετε ακούσει, μάθει, διαβάσει για normalization schemas, rules κλπ. στοιχεία/πράγματα που έχουν καθιερωθεί από τους πατεράδες των databases Codd και Date. Ναι  αυτά πρέπει να τηρούνται. Ναι πρέπει να τα ξέρουμε. Ναι είναι η αλφαβήτα και κανείς δεν τα αμφισβητεί.

Αυτό όμως που με τα χρόνια εμπειρίας έμαθα με το σκληρό τρόπο, και το οποίο με κάθε ευκαιρία διατυμπανίζω, είναι όταν σχεδιάζουμε μια database πρέπει να λάβουμε σοβαρά την αρχιτεκτονική του RDBMS που αυτή θα ζήσει.

Καλώς ή κακώς το κάθε RDBMS έχει τις αρχιτεκτονικές του ιδιαιτερότητες, οι οποίες επηρεάζουν τον τρόπο ζωής της κάθε database.

Μου είναι αδιανόητο να καταλάβω συναδέλφους που ενώ δίνουν βάση στην αρχιτεκτονική και στις ιδιαιτερότητες μιας γλώσσας προγραμματισμού ή μιας τεχνολογίας, δεν κάνουν το ίδιο με τις ιδιαιτερότητες του RDBMS που χρησιμοποιούν. Δεν μπορώ να καταλάβω γιατί θεωρούν όλα τα RDBMS όμοια ενώ αν τους πεις ότι η C# και η VB είναι ίδιες σηκώνουν λάβρους επαναστατικούς και σε κατακεραυνώνουν.

Για μένα τα παραπάνω δεν ισχύουν. Ο σωστός σχεδιασμός μιας database είναι σίγουρο ότι θα εξασφαλίσει την επιτυχία στο έργο για αυτό και δίνω την προσοχή μου 1000%, ιδιαίτερα σε αυτά που αφορούν την αρχιτεκτονική του RDBMS. Η ρήση του σχεδιάζω database ώστε να παίζει σε όλα τα RDBMS γιατί ο πελάτης μπορεί να έχει το Χ, ή το Y δεν με ακουμπά καθόλου, δεν την ασπάζομαι, δεν την ακολουθώ. Εάν βρεθώ στην περίπτωση που θα πρέπει να σχεδιάσω μια database που θα φιλοξενηθεί στο X ή στο Y φροντίζω να την σχεδιάσω για το κάθε ένα ξεχωριστά ώστε να εκμεταλλευτώ στο έπακρο τις δυνατότητες και ιδιαιτερότητες που το κάθε ένα έχει. Φυσικά κάποιος θα πει, μα καλά τόσο σημαντικές είναι που θα επηρεάσουν τόσο την απόδοση της databases. ΝΑΙ ΕΙΝΑΙ και δεν με απασχολεί αν το impact θα είναι 0,000001% ή 100%. Το impact είναι impact τελεία και παύλα.

Μάλιστα θα αποκλείσω αυτούς που λένε ότι σε μικρές databases δεν έχει σημασία. Για όλες έχει σημασία. 

Είμαι σχεδόν σίγουρος ότι όσοι διαβάζεται το post αυτό έχετε ήδη σκεφτεί ότι αυτό είναι διπλή ή τριπλή δουλειά όταν πρέπει να υποστηρίξω πολλά RDΒMS. Ναι ξέρω ότι έχετε σκεφτεί ότι αυτό σημαίνει ότι πρέπει να συντηρώ περισσότερο κώδικα, και πολλά ακόμα. Θα τα δεχθώ ως ένα βαθμό, χωρίς να σημαίνει ότι τα αποδέχομαι καθώς είμαι πεπεισμένος ότι αυτό που όλοι επιζητούμε είναι το αποτέλεσμα και η απόδοση του συστήματος.
Φυσικά αυτό έχει ένα κόστος αλλά το όφελος είναι μεγαλύτερο και σημαντικότερο. Όπως και να έχει πάντως πρέπει να τονίσω ότι κάποια πράγματα που αφορούν την συντήρηση κώδικα, αλλαγών και λοιπά μπορούν να ελαχιστοποιηθούν ή και να μηδενιστούν με την χρήση views, functions, stored procedures και application servers. Είναι όλα θέμα καλής θέλησης και θετικής σκέψης και κυρίως να πείσουμε τον εαυτό μας ότι το performance είναι το σημαντικότερο όλων.

Γιατί τώρα γράφω αυτό το post; Απλά για τονίσω για ακόμα μια φορά ότι τα σχεδιαστικά λάθη στο physical design  (και όχι μόνο στον SQL Server) έχουν αντίτυπο στο performance όχι μόνο της βάσης αλλά και γενικότερα του SQL Server (γενικότερα του DB Server). Γνωρίζω ότι σε κάποιους δεν θα αρέσουν, αλλά πρέπει να επισημανθούν. Είναι πράγματα τα οποία βγαίνουν από την 16ετή μου εμπειρία με το προϊόν.

Πως αποφεύγονται αυτά; Η απάντηση είναι απλή μαθαίνουμε και κατανοούμε 100% την αρχιτεκτονική και τα μυστικά που έχει το κάθε RDBMS που θα δουλέψουμε και στην δικιά μας περίπτωση του SQL Server.

Επίσης πρέπει να καταλάβουμε ότι άλλο είναι τα logical design μιας database και άλλο το physical design, και δεν σημαίνει ότι όπως σχεδίασα κάτι στο logical έτσι ακριβώς πρέπει να είναι και στο physical.

Όλα αυτά τα χρόνια έχω δει πολλά σχεδιαστικά λάθη από μικρά μεχρι…

Έχω δει βάση ERP να έχει πίνακες όπως ακριβώς ήταν όταν το ERP ήταν με sequential index files με κάθε πίνακα να έχει primary key composite με 16 πεδία και να θέλει 20 λεπτά να εκδοθεί τιμολόγιο.

Έχω δει βάση να μην έχει foreign key constraints γιατί είναι αργά και δεν ενδείκνυνται.

Έχω δει βάση να έχει όλα τα string fields nvarchar(max) λες και το τηλέφωνο πχ μπορεί να είναι 2GB σε χαρακτήρες ενώ παγκοσμίως είναι 16. Που θα πάρεις τηλέφωνο ρε φίλε; Ποιο σύμπαν θα καλέσεις;

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

Έχω δει βάση που τα αρχεία της να είναι σε δίσκους με μικρότερο από 64ΚΒ cluster size.

Έχω δει βάση που δεν έχει indexes.

Έχω δει βάση που σε πίνακες έχει primary key που έχει data type float.

Έχω δει βάση που δεν έχει view, functions, stored procedures επειδή είναι κακές σε απόδοση.

Έχω δει βάση που…

Δεν ζητάω πολλά. Αυτό που ζητάω είναι να ασχοληθείτε πραγματικά με το σχεδιασμό όσο και αν οι χρόνοι παράδοσης είναι σφικτοί. Βιβλιογραφία υπάρχει δόξα το Θεό μπόλικη.

Θυμηθείτε στην βάση αποτυπώνεται τα business logic της εφαρμογής σας.

Ευχαριστώ

/*antonch*/