go backarticles

Articles of SQLschool.gr Team

Δεν είναι σπάνιο το φαινόμενο να πέφτω πάνω σε 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*/


Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios is a Data Solutions Consultant and Trainer. He has been working in IT since 1988. In his career, he has worked as senior developer, IT Manager, Solutions Architect and IT Consultant. Since 1995 he has been devoted on new technologies and software development tools, mainly by Microsoft, either by training company staff and colleagues or assisting them in design, development and implementation as a consultant or chief developer. He has focused in Databases and Data Science since 1995. He specialized in Microsoft SQL Server since version 6.0 in areas like SQL Server Internals, Database Design and Development, Business Intelligence and in 2010 he has started working with Azure Data Platform, NoSQL databases, Big Data Technologies and Machine Learning. He is an active member of many IT communities in Greece, answering colleagues' questions and writing articles in his web site. He is the owner of SQLschool.gr which is a community portal with a lot of information about Microsoft SQL Server. He has been a Microsoft Certified Trainer (MCT) since 2000. Microsoft honored him as MVP on Data Platform due to his activities in SQL Server since 2010. He holds a large number of Microsoft Certifications and Microsoft SQL Server Certifications since version 6.5.


Relative Articles

Leave your comment

COMMENT

FULL NAME

EMAIL ADDRESS

We use Gravatar

WEB SITE



captcha


 

Newsletter

If you want to receive updates from us subscribe below with your email.
Follow us in
PASS chapter logo

The Official PASS Local Group for Greece

About us Contact us Terms of Use Privacy Sing in Register
sql school greece logo
© 2010-2020 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.