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

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

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

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

Κακή πρακτική αριθ. 1: Αγνοώντας τον σκοπό των δεδομένων

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

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

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

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

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

Κακή πρακτική αρ. 2: Κακή κανονικοποίηση

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

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

τι είναι η δοκιμή μονάδας με παράδειγμα

Εάν σκοντάψετε με τραπέζια που δεν συμμορφώνονται 3ΝΡ , 2NF ή ακόμα και 1NF, εξετάστε το ενδεχόμενο επανασχεδιασμού αυτών των πινάκων. Η προσπάθεια που επενδύετε για αυτό θα αποδώσει πολύ σύντομα.

Κακή πρακτική αριθ. 3: Απόλυση

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

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

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

Κακή πρακτική αρ. 4: Κακή ακεραιότητα αναφοράς (περιορισμοί)

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

Κακή πρακτική Νο. 5: Μη αξιοποιώντας τις δυνατότητες του κινητήρα DB

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

• Προβολές που παρέχουν έναν γρήγορο και αποτελεσματικό τρόπο για να δείτε τα δεδομένα σας, συνήθως την απενεργοποιείτε για λόγους ερωτήματος χωρίς να χάνετε την ορθότητα των δεδομένων.
• Ευρετήρια που βοηθούν στην επιτάχυνση των ερωτημάτων στους πίνακες.
• Συγκεντρωτικές λειτουργίες που βοηθούν στην ανάλυση πληροφοριών χωρίς προγραμματισμό.
• Συναλλαγές ή μπλοκ των προτάσεων αλλαγής δεδομένων που εκτελούνται και διαπράττονται ή ακυρώνονται (επαναφέρονται) εάν συμβεί κάτι απροσδόκητο, διατηρώντας έτσι τις πληροφορίες σε μια διαρκή σωστή κατάσταση.
• Κλειδαριές που διατηρούν τα δεδομένα ασφαλή και σωστά κατά την εκτέλεση των συναλλαγών.
• Αποθηκευμένες διαδικασίες που παρέχουν δυνατότητες προγραμματισμού που επιτρέπουν πολύπλοκες εργασίες διαχείρισης δεδομένων.
• Λειτουργίες που επιτρέπουν εξελιγμένους υπολογισμούς και μετασχηματισμούς δεδομένων.
• Περιορισμοί που βοηθούν στην εγγύηση της ορθότητας των δεδομένων και στην αποφυγή σφαλμάτων.
• Ενεργοποιήσεις που βοηθούν στην αυτοματοποίηση ενεργειών όταν συμβαίνουν συμβάντα στα δεδομένα.
• Βελτιστοποίηση εντολών (πρόγραμμα εκτέλεσης) που τρέχει κάτω από την κουκούλα, διασφαλίζοντας ότι κάθε πρόταση εκτελείται στο καλύτερό της και διατηρώντας τα σχέδια εκτέλεσης για μελλοντικές περιπτώσεις. Αυτός είναι ένας από τους καλύτερους λόγους για τη χρήση προβολών, αποθηκευμένων διαδικασιών και λειτουργιών, καθώς τα σχέδια εκτέλεσης διατηρούνται μόνιμα στο DBE.

Η μη γνώση ή η παράβλεψη αυτών των δυνατοτήτων θα οδηγήσει την ανάπτυξη σε μια εξαιρετικά αβέβαιη πορεία και σίγουρα σε σφάλματα και μελλοντικά προβλήματα.

Κακή πρακτική αρ. 6: Σύνθετα πρωτεύοντα κλειδιά

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

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

Προσοχή, ωστόσο, εάν ο πίνακας σας με ένα σύνθετο πρωτεύον κλειδί αναμένεται να έχει εκατομμύρια σειρές, ο δείκτης που ελέγχει το σύνθετο κλειδί μπορεί να αυξηθεί σε ένα σημείο όπου η απόδοση λειτουργίας CRUD είναι πολύ υποβαθμισμένη. Σε αυτήν την περίπτωση, είναι πολύ καλύτερο να χρησιμοποιήσετε ένα απλό ακέραιο πρωτεύον κλειδί του οποίου ο δείκτης θα είναι αρκετά συμπαγής και θα καθορίσει τους απαραίτητους περιορισμούς DBE για να διατηρήσει τη μοναδικότητα.

Κακή πρακτική No. 7: Κακή ευρετηρίαση

Μερικές φορές, θα έχετε έναν πίνακα που πρέπει να κάνετε ερώτημα από πολλές στήλες. Καθώς ο πίνακας μεγαλώνει, θα παρατηρήσετε ότι οι ΕΠΙΛΟΓΕΣ σε αυτές τις στήλες επιβραδύνονται. Εάν ο πίνακας είναι αρκετά μεγάλος, θα σκεφτείτε, λογικά, να δημιουργήσετε ένα ευρετήριο σε κάθε στήλη που χρησιμοποιείτε για να αποκτήσετε πρόσβαση σε αυτόν τον πίνακα μόνο για να διαπιστώσετε σχεδόν αμέσως ότι η απόδοση των ΕΠΙΛΟΓΩΝ βελτιώνεται, αλλά οι ΕΙΣΑΓΩΓΕΣ, οι ΕΝΗΜΕΡΩΣΕΙΣ και οι ΔΙΑΓΡΑΦΕΣ μειώνονται. Αυτό, φυσικά, οφείλεται στο γεγονός ότι τα ευρετήρια πρέπει να διατηρούνται συγχρονισμένα με τον πίνακα, πράγμα που σημαίνει τεράστια γενικά έξοδα για το DBE. Αυτή είναι μια τυπική περίπτωση υπερβολικής ευρετηρίασης που μπορείτε να λύσετε με πολλούς τρόπους. Για παράδειγμα, έχοντας μόνο ένα ευρετήριο σε όλες τις στήλες διαφορετικό από το πρωτεύον κλειδί που χρησιμοποιείτε για να ρωτήσετε τον πίνακα, η παραγγελία αυτών των στηλών από τις πιο χρησιμοποιούμενες έως τις λιγότερες μπορεί να προσφέρει καλύτερη απόδοση σε όλες τις λειτουργίες CRUD από ένα ευρετήριο ανά στήλη.

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

Επίσης, η απόδοση ευρετηρίου εξαρτάται μερικές φορές από τον τύπο της στήλης. Τα ευρετήρια στις στήλες INT δείχνουν την καλύτερη δυνατή απόδοση, αλλά τα ευρετήρια στις VARCHAR, DATE ή DECIMAL (εάν έχει νόημα) δεν είναι τόσο αποτελεσματικά. Αυτό το ζήτημα μπορεί ακόμη και να οδηγήσει σε επανασχεδιασμό πινάκων στους οποίους πρέπει να έχετε πρόσβαση με την καλύτερη δυνατή απόδοση.

πώς να φτιάξετε μια γλώσσα υπολογιστή

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

Κακή πρακτική Νο. 8: Συμβάσεις κακής ονομασίας

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

Το όνομα του πίνακα πρέπει να περιγράφει ποια οντότητα κατέχει και κάθε όνομα στήλης πρέπει να περιγράφει ποιες πληροφορίες αντιπροσωπεύει. Αυτό είναι εύκολο, αλλά αρχίζει να είναι περίπλοκο όταν τα τραπέζια πρέπει να σχετίζονται μεταξύ τους. Τα ονόματα αρχίζουν να γίνονται ακατάστατα και, χειρότερα, εάν υπάρχουν σύγχυση συμβάσεων ονομασίας με παράλογους κανόνες (όπως, για παράδειγμα, 'το όνομα της στήλης πρέπει να είναι 8 χαρακτήρες ή λιγότεροι'). Η τελική συνέπεια είναι ότι η βάση δεδομένων γίνεται δυσανάγνωστη.

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

• Δεν υπάρχουν περιορισμοί στο μέγεθος του πίνακα ή του ονόματος στήλης. Είναι καλύτερο να έχουμε ένα περιγραφικό όνομα από ένα ακρωνύμιο που κανείς δεν θυμάται ούτε κατανοεί.
• Τα ίδια ονόματα έχουν την ίδια έννοια. Αποφύγετε να έχετε πεδία με το ίδιο όνομα αλλά με διαφορετικούς τύπους ή έννοιες. αυτό θα προκαλέσει σύγχυση αργά ή γρήγορα.
• Εκτός εάν είναι απαραίτητο, μην είναι περιττό. Για παράδειγμα, στον πίνακα 'Στοιχείο', δεν χρειάζεται να υπάρχουν στήλες όπως 'ItemName', 'PriceOfItem' ή παρόμοια ονόματα. Τα 'Όνομα' και 'Τιμή' είναι αρκετά.
• Προσοχή στις δεσμευμένες λέξεις DBE. Εάν μια στήλη πρόκειται να ονομαστεί 'Ευρετήριο', η οποία είναι μια δεσμευμένη λέξη SQL, δοκιμάστε να χρησιμοποιήσετε μια διαφορετική, όπως 'Ευρετήριο Αριθμός'.
• Εάν ακολουθείτε τον κανόνα του απλού πρωτεύοντος κλειδιού (δημιουργείται αυτόματα ένας ακέραιος ακέραιος), ονομάστε το 'Id' σε κάθε πίνακα.
• Εάν συνδέεστε σε άλλο πίνακα, ορίστε το απαραίτητο ξένο κλειδί ως ακέραιο, που ονομάζεται 'Id' ακολουθούμενο από το όνομα του ενωμένου πίνακα (π.χ. IdItem).
• Εάν ορίζετε περιορισμούς, χρησιμοποιήστε ένα πρόθεμα που περιγράφει τον περιορισμό (π.χ. 'PK' ή 'FK'), ακολουθούμενο από το όνομα του πίνακα ή των σχετικών πινάκων. Φυσικά, η χρήση υπογράμμισης ('_') βοηθάει τα πράγματα να γίνουν πιο ευανάγνωστα.
• Για να ονομάσετε ευρετήρια, χρησιμοποιήστε το πρόθεμα 'IDX' ακολουθούμενο από το όνομα του πίνακα και τη στήλη ή τις στήλες του ευρετηρίου. Επίσης, χρησιμοποιήστε το 'ΜΟΝΑΔΙΚΟ' ως πρόθεμα ή επίθημα εάν το ευρετήριο είναι μοναδικό και υπογραμμίζει όπου είναι απαραίτητο.

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

Μερικές τελικές παρατηρήσεις

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

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

Και μην ξεχνάτε ότι μαθαίνετε μόνο μέσω πειραματισμού, λαθών και επιτυχιών, οπότε προχωρήστε και ξεκινήστε τώρα.