Είτε εργάζεστε με μια βάση δεδομένων που περιέχει εκατοντάδες αρχεία ή εκατομμύρια αρχεία, ο κατάλληλος σχεδιασμός βάσης δεδομένων είναι πάντα σημαντικός. Όχι μόνο θα κάνει την ανάκτηση των πληροφοριών πολύ πιο εύκολη, αλλά θα απλοποιήσει επίσης την επέκταση της βάσης δεδομένων στο μέλλον. Δυστυχώς, είναι εύκολο να πέσετε σε μερικές παγίδες που μπορεί να κάνουν τα πράγματα δύσκολα στο μέλλον.
Υπάρχουν ολόκληρα βιβλία που γράφονται με θέμα την ομαλοποίηση μιας βάσης δεδομένων, αλλά αν απλά αποφύγετε αυτά τα συνηθισμένα λάθη, θα είστε στο σωστό δρόμο για καλό σχεδιασμό βάσης δεδομένων.
Λάθος βάσης δεδομένων # 1: Επαναλαμβανόμενα πεδία σε έναν πίνακα
Ένας βασικός κανόνας για τον καλό σχεδιασμό βάσης δεδομένων είναι η αναγνώριση επαναλαμβανόμενων δεδομένων και η τοποθέτηση αυτών των επαναλαμβανόμενων στηλών στον δικό τους πίνακα. Τα πεδία επανάληψης σε έναν πίνακα είναι κοινά για όσους προέρχονται από τον κόσμο των υπολογιστικών φύλλων, αλλά ενώ τα υπολογιστικά φύλλα τείνουν να είναι επίπεδα κατά το σχεδιασμό, οι βάσεις δεδομένων πρέπει να είναι σχεσιακές. Είναι σαν να πηγαίνεις από 2D σε 3D.
Ευτυχώς, τα επαναλαμβανόμενα πεδία είναι συνήθως εύκολο να εντοπιστούν. Ρίξτε μια ματιά σε αυτό το τραπέζι:
| Αριθμός Παραγγελίας | Προϊόν1 | Προϊόν2 | Προϊόν3 |
| 1 | Αρκουδάκια | Καραμέλες - Ζελεδάκια | |
| 2 | Καραμέλες - Ζελεδάκια |
Τι συμβαίνει όταν μια παραγγελία περιέχει τέσσερα προϊόντα; Θα πρέπει να προσθέσουμε ένα άλλο πεδίο στο τραπέζι για να υποστηρίξουμε περισσότερα από τρία προϊόντα. Και αν έχουμε δημιουργήσει μια εφαρμογή πελάτη γύρω από το τραπέζι για να μας βοηθήσει να εισάγουμε δεδομένα, ίσως χρειαστεί να το τροποποιήσουμε με το νέο πεδίο προϊόντος. Και πώς βρίσκουμε όλες τις εντολές με τη Jellybeans με τη σειρά; Θα είμαστε υποχρεωμένοι να ερωτήσουμε κάθε πεδίο προϊόντος στον πίνακα με μια δήλωση SQL που μπορεί να μοιάζει με: SELECT * FROM Προϊόντα WHERE Product1 = 'Jelly Beans' OR Προϊόν2 = 'Jelly Beans' OR Προϊόν 3 = 'Jelly Beans'.
Αντί να έχουμε ένα ενιαίο τραπέζι που να συγκεντρώνει όλες τις πληροφορίες μαζί, θα πρέπει να έχουμε τρία τραπέζια που κάθε ένα έχει ξεχωριστή πληροφορία. Σε αυτό το παράδειγμα, θα θέλαμε έναν πίνακα παραγγελιών με πληροφορίες σχετικά με την ίδια την παραγγελία, έναν πίνακα προϊόντων με όλα τα προϊόντα μας και ένα tablet ProductOrders που συνδέει προϊόντα με την παραγγελία.
| Αριθμός Παραγγελίας | Κωδικός πελάτη | Ημερομηνία παραγγελίας | Σύνολο |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Κωδικός προϊόντος | Προϊόν | μετρώ |
| 1 | Αρκουδάκια | 1 |
| 2 | Καραμέλες - Ζελεδάκια | 100 |
| ProductOrderID | Κωδικός προϊόντος | Αριθμός Παραγγελίας |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Παρατηρήστε πώς κάθε πίνακας έχει το δικό του μοναδικό πεδίο αναγνωριστικού. Αυτό είναι το πρωτεύον κλειδί. Συνδέουμε πίνακες χρησιμοποιώντας μια τιμή πρωτεύοντος κλειδιού ως ξένο κλειδί σε έναν άλλο πίνακα. Διαβάστε περισσότερα σχετικά με τα πρωτεύοντα κλειδιά και τα ξένα κλειδιά.
Λάθος βάση δεδομένων # 2: Ενσωμάτωση πίνακα σε πίνακα
Αυτό είναι ένα άλλο συνηθισμένο λάθος, αλλά δεν ξεχωρίζει πάντα τόσο πολύ όσο τα επαναλαμβανόμενα πεδία. Κατά το σχεδιασμό μιας βάσης δεδομένων, θέλετε να βεβαιωθείτε ότι όλα τα δεδομένα σε έναν πίνακα σχετίζονται με τον εαυτό του. Είναι σαν το παιχνίδι του παιδιού για να εντοπίσουμε τι είναι διαφορετικό. Αν έχετε μια μπανάνα, μια φράουλα, ένα ροδάκινο και μια τηλεόραση, η τηλεόραση πιθανώς ανήκει κάπου αλλού.
Παράλληλα, εάν διαθέτετε πίνακα ατόμων πωλήσεων, όλες οι πληροφορίες αυτού του πίνακα θα πρέπει να αφορούν συγκεκριμένα αυτόν τον πωλητή. Οποιαδήποτε πρόσθετη πληροφορία που δεν είναι μοναδική για αυτό το πρόσωπο πωλήσεων μπορεί να ανήκει κάπου αλλού στη βάση δεδομένων σας.
| SalesID | Πρώτα | τελευταίος | Διεύθυνση | Τηλεφωνικό νούμερο | Γραφείο | OfficeNumber |
| 1 | ο Σαμ | Ελλιότ | 118 Main St, Austin, TX | (215) 555-5858 | Ώστιν Downtown | (212) 421-2412 |
| 2 | Αλίκη | Σιδηρουργός | 504 2nd Street, Νέα Υόρκη, Νέα Υόρκη | (211) 122-1821 | Νέα Υόρκη (Ανατολικά) | (211) 855-4541 |
| 3 | Joe | Ενορία | 428 Aker St, Austin, TX | (215) 545-5545 | Ώστιν Downtown | (212) 421-2412 |
Αν και αυτός ο πίνακας μπορεί να μοιάζει σαν να σχετίζεται όλοι με τον μεμονωμένο πωλητή, έχει στην πραγματικότητα έναν πίνακα ενσωματωμένο στον πίνακα. Παρατηρήστε πώς επαναλαμβάνεται το Office και το OfficeNumber με το "Austin Downtown". Τι γίνεται εάν αλλάξει ένας αριθμός τηλεφώνου γραφείου; Θα χρειαστεί να ενημερώσετε μια ολόκληρη σειρά δεδομένων για ένα μόνο κομμάτι αλλαγής πληροφοριών, κάτι που δεν είναι ποτέ καλό. Αυτά τα πεδία πρέπει να μετακινηθούν στο δικό τους τραπέζι.
| SalesID | Πρώτα | τελευταίος | Διεύθυνση | Τηλεφωνικό νούμερο | OfficeID |
| 1 | ο Σαμ | Ελλιότ | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Αλίκη | Σιδηρουργός | 504 2nd Street, Νέα Υόρκη, Νέα Υόρκη | (211) 122-1821 | 2 |
| 3 | Joe | Ενορία | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Γραφείο | OfficeNumber |
| 1 | Ώστιν Downtown | (212) 421-2412 |
| 2 | Νέα Υόρκη (Ανατολικά) | (211) 855-4541 |
Αυτός ο τύπος σχεδίασης σας δίνει επίσης τη δυνατότητα να προσθέσετε επιπλέον πληροφορίες στον πίνακα γραφείου χωρίς να δημιουργήσετε έναν εφιάλτη ακαταστασίας στον πίνακα προσωπικού πωλήσεων. Φανταστείτε πόση δουλειά θα ήταν να παρακολουθείτε απλά τη διεύθυνση του δρόμου, την πόλη, την πολιτεία και τον ταχυδρομικό κώδικα, αν όλες αυτές οι πληροφορίες ήταν στο τραπέζι του προσωπικού πωλήσεων!
Λάθος βάση δεδομένων # 3: Βάζοντας δύο ή περισσότερα κομμάτια πληροφοριών σε ένα ενιαίο πεδίο
Η ενσωμάτωση των πληροφοριών του γραφείου στον πίνακα προσωπικού πωλήσεων δεν ήταν το μοναδικό πρόβλημα με αυτή τη βάση δεδομένων. Το πεδίο διεύθυνσης περιείχε τρία στοιχεία: τη διεύθυνση του δρόμου, την πόλη και το κράτος. Κάθε πεδίο στη βάση δεδομένων πρέπει να περιέχει μόνο ένα μόνο στοιχείο. Όταν έχετε πολλαπλές πληροφορίες σε ένα μόνο πεδίο, μπορεί να γίνει πιο δύσκολη η αναζήτηση πληροφοριών στη βάση δεδομένων.
Για παράδειγμα, τι εάν θέλαμε να εκτελέσουμε ένα ερώτημα σε όλους τους ανθρώπους πωλήσεων από το Ώστιν; Θα πρέπει να αναζητήσουμε μέσα στο πεδίο διεύθυνσης, το οποίο δεν είναι μόνο αναποτελεσματικό, αλλά μπορεί να επιστρέψει κακές πληροφορίες. Μετά από όλα, τι συμβαίνει αν κάποιος έζησε στην οδό Ώστιν στο Πόρτλαντ του Όρεγκον;
Εδώ πρέπει να φαίνεται το τραπέζι:
| SalesID | Πρώτα | τελευταίος | Διεύθυνση 1 | Διεύθυνση 2 | Πόλη | κατάσταση | Φερμουάρ | Τηλέφωνο |
| 1 | ο Σαμ | Ελλιότ | 118 Main St | Ώστιν | TX | 78720 | 2155555858 | |
| 2 | Αλίκη | Σιδηρουργός | 504 2η Στ | Νέα Υόρκη | NY | 10022 | 2111221821 | |
| 3 | Joe | Ενορία | 428 Aker St | Apt 304 | Ώστιν | TX | 78716 | 2155455545 |
Υπάρχουν μερικά πράγματα που πρέπει να σημειώσετε εδώ. Πρώτον, η "Διεύθυνση1" και "Διεύθυνση2" φαίνεται να εμπίπτουν στο σφάλμα των επαναλαμβανόμενων πεδίων.
Εντούτοις, στην περίπτωση αυτή αναφέρονται σε ξεχωριστά κομμάτια δεδομένων που σχετίζονται άμεσα με το πρόσωπο πωλήσεων και όχι σε μια επαναλαμβανόμενη ομάδα δεδομένων που πρέπει να μεταβεί στον δικό του πίνακα.
Επίσης, ως λάθος μπόνους για αποφυγή, παρατηρήστε πως η μορφοποίηση του αριθμού τηλεφώνου έχει αφαιρεθεί από τον πίνακα. Θα πρέπει να αποφύγετε την αποθήκευση της μορφής των πεδίων όταν είναι δυνατόν. Στην περίπτωση αριθμών τηλεφώνου, υπάρχουν πολλοί τρόποι με τους οποίους οι άνθρωποι γράφουν έναν αριθμό τηλεφώνου: 215-555-5858 ή (215) 555-5858. Αυτό θα έκανε την αναζήτηση ενός ατόμου πωλήσεων από τον αριθμό τηλεφώνου τους ή να κάνει μια αναζήτηση των πωλητών στον ίδιο τομέα κώδικα πιο δύσκολη.
Λάθος βάσης δεδομένων # 4: Δεν χρησιμοποιείτε ένα σωστό πρωτεύον κλειδί
Στις περισσότερες περιπτώσεις, θα θέλετε να χρησιμοποιήσετε έναν αυτόματα αυξανόμενο αριθμό ή κάποιο άλλο δημιουργούμενο αριθμό ή αλφαριθμητικό για το πρωτεύον κλειδί. Θα πρέπει να αποφύγετε τη χρήση οποιωνδήποτε πραγματικών πληροφοριών για το πρωτεύον κλειδί, ακόμα κι αν ακούγεται σαν να έκανε καλό αναγνωριστικό.
Για παράδειγμα, έχουμε το καθένα δικό μας προσωπικό αριθμό κοινωνικής ασφάλισης, οπότε η χρήση του αριθμού κοινωνικής ασφάλισης για μια βάση δεδομένων των εργαζομένων μπορεί να ακούγεται σαν μια καλή ιδέα. Αλλά ενώ είναι σπάνιο, είναι δυνατόν ακόμη και ένας αριθμός κοινωνικής ασφάλισης να αλλάξει και ποτέ δεν θέλουμε να αλλάξει το πρωτεύον κλειδί μας.
Και αυτό είναι το πρόβλημα με τη χρήση των πραγματικών πληροφοριών ως βασική τιμή. Μπορεί να αλλάξει.
Λάθος βάσης δεδομένων # 5: Μη χρήση μιας σύμβασης ονομάτων
Αυτό μπορεί να μην ακούγεται σαν μεγάλη υπόθεση όταν ξεκινάτε αρχικά να σχεδιάζετε τη βάση δεδομένων σας, αλλά μόλις φτάσετε στο σημείο να γράφετε ερωτήματα κατά της βάσης δεδομένων για να ανακτήσετε πληροφορίες, η σύμβαση ονοματοδοσίας θα σας βοηθήσει να απομνημονεύσετε τα ονόματα πεδίων.
Απλώς φανταστείτε πόσο πιο δύσκολη θα ήταν η διαδικασία αν τα ονόματα αποθηκεύτηκαν ως FirstName, LastName σε έναν πίνακα και first_name, last_name σε άλλο πίνακα.
Οι δύο πιο δημοφιλείς συμβάσεις ονομασίας είναι η κεφαλαιοποίηση του πρώτου γράμματος κάθε λέξης στο πεδίο ή ο διαχωρισμός των λέξεων χρησιμοποιώντας μια υπογράμμιση. Μπορεί επίσης να δείτε μερικούς προγραμματιστές να κεφαλαιοποιήσουν το πρώτο γράμμα κάθε λέξης εκτός από την πρώτη λέξη: firstName, lastName.
Θα θελήσετε επίσης να αποφασίσετε σχετικά με τη χρήση ονομάτων μοναδικών τραπεζιών ή ονομάτων πληθυντικών πινάκων. Είναι ένας πίνακας παραγγελιών ή ένας πίνακας παραγγελιών; Είναι ένας πίνακας πελατών ή ένας πίνακας Πελατών; Και πάλι, δεν θέλετε να κολλήσετε με έναν πίνακα παραγγελιών και έναν πίνακα Πελατών.
Η σύμβαση ονομασίας που επιλέγετε δεν είναι τόσο σημαντική όσο η διαδικασία της πραγματικής επιλογής και της προσκόλλησης σε μια σύμβαση ονομασίας.
Λάθος βάση δεδομένων # 6: Κακή ευρετηρίαση
Η ευρετηρίαση είναι ένα από τα πιο δύσκολα πράγματα που πρέπει να επιτύχουμε, ειδικά για εκείνους τους νέους στο σχεδιασμό της βάσης δεδομένων. Όλα τα πρωτεύοντα κλειδιά και τα ξένα πλήκτρα θα πρέπει να αναπροσαρμόζονται. Αυτά είναι αυτά που συνδέουν τα τραπέζια μαζί, έτσι χωρίς ένα ευρετήριο, θα δείτε πολύ κακή απόδοση από τη βάση δεδομένων σας.
Αλλά αυτά που λείπουν πολύ συχνά είναι τα άλλα πεδία. Αυτά είναι τα πεδία "WHERE". Αν σκοπεύετε συχνά να περιορίσετε την αναζήτησή σας χρησιμοποιώντας ένα πεδίο σε μια ρήτρα WHERE, θέλετε να σκεφτείτε να βάλετε ένα ευρετήριο σε αυτό το πεδίο. Ωστόσο, δεν θέλετε να κάνετε υπερβολική ευρετηρίαση του πίνακα, γεγονός που μπορεί επίσης να βλάψει την απόδοση.
Πώς να αποφασίσετε; Αυτό είναι μέρος της τέχνης του σχεδιασμού βάσης δεδομένων. Δεν υπάρχουν σκληρά όρια για τον αριθμό των δεικτών που πρέπει να τοποθετήσετε σε ένα τραπέζι. Κατά κύριο λόγο, θέλετε να αναγράψετε οποιοδήποτε πεδίο που χρησιμοποιείται συχνά σε μια ρήτρα WHERE. Διαβάστε περισσότερα σχετικά με τη σωστή ευρετηρίαση της βάσης δεδομένων σας.