Εκπαιδευτικό πρωτεύον κλειδί SQL - Πώς να ορίσετε ένα πρωτεύον κλειδί σε μια βάση δεδομένων

Κάθε υπέροχη ιστορία ξεκινά με μια κρίση ταυτότητας. Ο Λουκάς, ο μεγάλος Δάσκαλος του Τζέντι, ξεκινά αβέβαιος - "Ποιος είμαι;" - και πώς θα μπορούσα να είμαι σημαντικός; Χρειάζεται ο Yoda, αυτός με τη Δύναμη, να του διδάξει πώς να εκμεταλλευτεί τις δυνάμεις του.

Σήμερα, επιτρέψτε μου να γίνω το Yoda σας.

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

Πώς να επιλέξετε ένα πρωτεύον κλειδί

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

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

First Name Last Name Passport Number

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

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

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

Η μοναδικότητα δεν είναι αρκετή. Η τιμή δεν πρέπει να αλλάζει καθ 'όλη τη διάρκεια της σειράς.

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

Κάθε σειρά πρέπει να έχει αναγνωριστικό. Δεν επιτρέπονται NULL.

Η επόμενη επανάληψη σημαίνει εύρεση ενός αναγνωριστικού που δεν αλλάζει με την πάροδο του χρόνου και ενός που έχει ο καθένας. Στην Ινδία, αυτό είναι το Adhaar Card. Στις ΗΠΑ, ο αριθμός κοινωνικής ασφάλισης.

Εάν δημιουργείτε μια βάση δεδομένων, ορίστε αυτά τα κύρια κλειδιά σας.

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

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

userID First Name Last Name Passport Number

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

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

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

Το κύριο takeaway είναι αυτό: Όποτε επιλέγετε ένα Πρωτεύον κλειδί, σκεφτείτε μια κρίση ταυτότητας . Είναι πιθανό κάποιος να αλλάξει το αναγνωριστικό του στο μέλλον; Μπορούμε να φτάσουμε σε μια κατάσταση με πολλά άτομα να έχουν το ίδιο αναγνωριστικό;

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

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

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

Ένα πραγματικό παράδειγμα

Ας υποθέσουμε ότι εκτελείτε εκκίνηση αποστολής, σαν το Flexport Έχετε πακέτα που πρέπει να πάρετε από το ένα μέρος στο άλλο και τα πλοία που τα μεταφέρουν. Επιπλέον, έχετε πελάτες που παραγγέλνουν αυτά τα πακέτα.

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

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

Δεδομένων αυτών των πληροφοριών, θα σχεδίαζα αυτούς τους πίνακες έτσι:

Customers: first_name, last_name, email, address (for deliveries to their location) Packages: weight, content Transportation: , Port, time

Λείπουν τα κύρια κλειδιά. Σκεφτείτε τους πριν διαβάσετε περαιτέρω.

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

Έτσι, είναι λογικό να δημιουργήσετε έναν τυχαίο αριθμό και να τον χρησιμοποιήσετε ως αναγνωριστικό. Γι 'αυτό ακριβώς βλέπετε το FedEx, το UPS και κάθε υπηρεσία παράδοσης χρησιμοποιούν γραμμικούς κώδικες και αναγνωριστικά. Αυτά είναι υποκατάστατα κλειδιά που δημιουργούνται για την παρακολούθηση πακέτων.

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

Διασκεδαστική ιστορία: Γνωρίζω μερικές εταιρείες όπου εξέθεσαν αυτό το CustomerNo, και οι πελάτες επέμειναν να πάρουν το No. 1. Ήταν αρκετά ξεκαρδιστικό - οι μηχανικοί έπρεπε πραγματικά να αλλάξουν τον κωδικό front-end τους σε: if (cust == 345681) print(1);

Για μεταφορά, θα επιλέξω ένα σύνθετο PackageID + Port + time. Αυτό είναι λίγο πιο ενδιαφέρον. Θα μπορούσα επίσης να δημιουργήσω ένα υποκατάστατο εδώ, και θα λειτουργούσε εξίσου καλά.

But, here lies the magic of indexing. The Primary Keys get an index automatically, which means searching is a lot more efficient over Primary Keys.

When you're searching through this database, most queries will be of the form "where is this package?". In other words, given this PackageID, tell me the Port and Time it is at right now. I would need an extra index over PackageID if I don't have it as part of my Primary Key.

Does this sound good? Final step, let's define these 3 tables in SQL. The syntax varies slightly with the database you're using.

Defining Primary Keys in MySQL

CREATE TABLE customers ( customerID INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, last_name VARCHAR(30) NOT NULL, first_name VARCHAR(25) NOT NULL, email VARCHAR(50) NOT NULL, address VARCHAR(300) );
CREATE TABLE packages ( packageID INT(15) NOT NULL AUTO_INCREMENT, weight DECIMAL (10, 2) NOT NULL, content VARCHAR(50), CONSTRAINT packages_pk PRIMARY KEY (packageID) # An alternative way to above, # when you want to name the constraint as well. );
CREATE TABLE transportation ( package INT(15) NOT NULL, port INT(15) NOT NULL, time DATE NOT NULL, PRIMARY KEY (package, port, time), FOREIGN KEY package REFERENCES packages(packageID) ON DELETE RESTRICT # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted. );

Defining Primary Keys in PostgreSQL

CREATE TABLE customers ( customerID SERIAL NOT NULL PRIMARY KEY, # In PostgreSQL SERIAL is same as AUTO_INCREMENT - it adds 1 to every new row. last_name VARCHAR(30) NOT NULL, first_name VARCHAR(25) NOT NULL, address TEXT, email VARCHAR(50) NOT NULL );
CREATE TABLE packages ( packageID SERIAL NOT NULL, weight NUMERIC NOT NULL, content TEXT, CONSTRAINT packages_pk PRIMARY KEY (packageID) # In PostgreSQL, this alternative way works too. );
CREATE TABLE transportation ( package INTEGER NOT NULL, port INT(15) NOT NULL, time DATE NOT NULL, PRIMARY KEY (package, port, time), FOREIGN KEY package REFERENCES packages(packageID) ON DELETE RESTRICT # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted. );

It's not very different, is it? Once you get the basics down, you can apply it to almost any database with just a quick look at the documentation. The key is knowing what to look for!

Good luck, young padawan.

Σας άρεσε αυτό; Μπορεί επίσης να σας αρέσουν τα πράγματα που έμαθα από έναν ανώτερο μηχανικό λογισμικού