Pirminio rakto SQL pamoka - kaip apibrėžti pagrindinį raktą duomenų bazėje

Kiekviena puiki istorija prasideda nuo tapatybės krizės. Lukas, didysis „Jedi“ meistras, pradeda nežinoti - „Kas aš?“ - ir kaip aš galėčiau būti kas nors svarbus? Jodą, turinčią Jėgą, reikia išmokyti, kaip panaudoti savo galias.

Šiandien leisk man būti tavo Yoda.

Pradėsime nuo to, kaip pasirinkti pagrindinį raktą, kovoti su tapatybės krize ir baigti kodų pavyzdžiais, kaip sukurti pirminį raktą duomenų bazėje.

Kaip pasirinkti pagrindinį raktą

Galite manyti, kad Lukas yra vienintelis, patyręs tapatybės krizę, tačiau tai netiesa. Kuriant duomenų bazę viskas patiria tapatybės krizę. Ir būtent todėl mums reikia pirminių raktų: jie išsprendžia krizę. Jie mums sako, kaip surasti visus.

Įsivaizduokite, kad esate vyriausybė ir norite kiekvieną savo pilietį atpažinti skaitmeniniu būdu. Taigi, jūs sukuriate šią duomenų bazę su viskuo, kas apie juos:

First Name Last Name Passport Number

Kaip pagrindinį raktą pasirenkate paso numerį - kiekvieno tapatybę. Jūs suprantate, kad viskas, ko jums reikia, nes pase yra adresas ir visa kita. Jūs žinote, kad paso numeriai yra unikalūs, todėl jaučiatės gerai ir įgyvendinate šią sistemą.

Tada, praėjus keleriems metams, sužinosite negražią tiesą: visa šalis susiduria su tapatybės krize.

Kai pasibaigia paso galiojimo laikas, jis gauna naują. Jų tapatybė keičiasi. Kitos sistemos ir toliau naudoja senus paso numerius, todėl dabar rodo žmones į vaiduoklius.

Nepakanka unikalumo. Vertė neturi keistis per visą eilutės gyvavimo laiką.

Tada pastebite, kad yra žmonių, kurie net neturi pasų. Negalite jų įvesti į savo sistemą, nes pirminiai raktai negali būti NULL. Kaip galima atpažinti žmogų su NULLraktu?

Kiekvienoje eilutėje turi būti identifikatorius. NULL neleidžiama.

Kitas kartojimas reiškia rasti identifikatorių, kuris laikui bėgant nesikeičia ir kurį turi visi. Indijoje tai pasirodo „Adhaar Card“. JAV socialinio draudimo numeris.

Jei kuriate duomenų bazę, nustatykite tuos pagrindinius raktus.

Kartais tokio rakto neturite. Apsvarstykite šalį, kuri dar neturi socialinio draudimo numerio ir nori sukurti skaitmeninį kiekvieno piliečio įrašą. Jie galėtų sukurti naują SSN arba tiesiog pasinaudoti duomenų bazių galia ir naudoti pakaitinį raktą.

Pakaitinis raktas neturi atitikmens realiame pasaulyje. Tai tik skaičius duomenų bazėje. Taigi, jūs turite šią lentelę naujoje šalyje:

userID First Name Last Name Passport Number

Paso numeriai yra unikalūs. Visada, kai norite gauti vartotojo identifikatorių, galite jį gauti naudodamiesi paso numeriu.

„UserID“ niekada nesikeičia. Paso numeris gali keistis, tačiau jis visada yra unikalus, todėl visada gaunate tinkamą vartotoją. „UserID“ yra šioje šalyje neegzistuojančio socialinio draudimo numerio pakaitalas .

Įdomus faktas: paso numeris čia taip pat yra raktas į kandidatą. Tai galėjo būti pagrindinis raktas, jei jis niekada nepasikeitė. Tai yra verslo logikos skirtumas.

Pagrindinis išsinešimas yra toks: kai pasirenkate pagrindinį raktą, pagalvokite apie tapatybės krizę . Ar gali būti, kad ateityje kažkas gali pakeisti savo identifikatorių? Ar galime patekti į valstybę, kurioje keli žmonės turi tą patį identifikatorių?

Aš naudoju žmones kaip pavyzdį, nes taip tapatybė tampa aiškesnė - mes žinome, kad kiekvienas žmogus turi turėti tapatybę. Perkelkite šį mąstymą į savo duomenų bazes. Viskas turi tapatybę, būtent todėl jums reikalingi pirminiai raktai.

Pastaba: kartais įmanoma ir pageidautina kelis pagrindinius raktus naudoti kartu. Tai yra sudėtinis raktas.

Dabar pabandykime apibrėžti pagrindinius raktus su realiais kodų pavyzdžiais. Čia reikia padaryti du dalykus: pirmiausia nustatysite pagrindinį raktą. Tada išmoksite sintaksę, kaip ją apibrėžti duomenų bazėje.

Tikras pasaulio pavyzdys

Tarkime, kad vykdote pristatymo paleidimą, panašiai kaip „Flexport“. Jūs turite paketus, kuriuos reikia pasiekti iš vienos vietos į kitą, ir laivus, kurie juos gabena. Be to, turite klientų, kurie užsisako šiuos paketus.

Jūs suprantate, kad jums reikės vienos lentelės klientams, vienos pakuotėms ir vienos gabenimui, nurodant, kuri pakuotė yra kur dabar.

Pagalvokite, kokių stulpelių jums reikės ir koks turėtų būti pagrindinis raktas. Jei būtumėte „Flexport“ inžinierius, tai būtų tikras klausimas, kurį turėtumėte išsiaiškinti. Nieko neduota, viskas atrandama realiame pasaulyje.

Atsižvelgdamas į šią informaciją, aš sukūrčiau šias lenteles taip:

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

Trūksta pagrindinių raktų. Pagalvokite apie juos prieš skaitydami toliau.

Paketui pasirinksiu pakaitinį „ PackageID“. Galėjau pabandyti išvardyti visus pakuotės atributus: svorį, tūrį, tankį, amžių. Jie unikaliai identifikuotų paketą, tačiau praktiškai tai padaryti labai sunku. Žmonėms tai nerūpi, jie tiesiog rūpinasi, kad paketas patektų iš vienos vietos į kitą.

Taigi prasminga sukurti atsitiktinį skaičių ir naudoti jį kaip ID. Būtent todėl matote „FedEx“, „UPS“ ir kiekvienoje pristatymo tarnyboje naudojami brūkšniniai kodai ir ID. Tai pakaitiniai raktai, sugeneruoti paketams stebėti.

Klientui pasirenku pakaitinį „ CustomerID“. Čia vėl turėjau galimybę pasirinkti, tarkime, savo klientų socialinio draudimo numerį. Bet klientai nenori tuo pasidalinti su manimi, kad tik galėčiau jiems ką nors išsiųsti. Taigi, mes generuojame raktą viduje, nesakome savo klientams apie šį raktą ir toliau juos vadiname „CustomerNo“. 345681.

Įdomi istorija: Aš žinau keletą kompanijų, kuriose jie atskleidė šį „CustomerNo“, ir klientai reikalavo, kad jie gautų Nr. 1. Tai buvo gana linksma - inžinieriai iš tikrųjų turėjo pakeisti savo patobulintą kodą į: if (cust == 345681) print(1);

Transportavimui pasirinksiu sudėtinį „ PackageID + + Port + time“. Tai šiek tiek įdomiau. Aš čia taip pat galėjau sukurti pakaitalą , ir jis veiktų lygiai taip pat.

Bet čia slypi indeksavimo magija. Pirminiai raktai automatiškai gauna indeksą, o tai reiškia, kad paieška yra daug efektyvesnė už pirminius raktus.

Kai ieškote šioje duomenų bazėje, dauguma užklausų bus formos „kur yra šis paketas?“. Kitaip tariant, turint omenyje šį „PackageID“, pasakykite man, koks yra uostas ir laikas. Man reiktų papildomo indekso virš „PackageID“, jei jo neturiu kaip pirminio rakto dalies.

Ar tai skamba gerai? Paskutinis žingsnis: apibrėžkime šias 3 lenteles SQL. Sintaksė šiek tiek skiriasi priklausomai nuo naudojamos duomenų bazės.

Pagrindinių raktų apibrėžimas 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. );

Pagrindinių raktų apibrėžimas „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. );

Tai nėra labai skirtinga, ar ne? Susipažinę su pagrindais, galite greitai pritaikyti dokumentus bet kurioje duomenų bazėje. Svarbiausia žinoti, ko ieškoti!

Sėkmės, jaunas padawan.

Patiko tai? Jums taip pat gali patikti dalykai, kuriuos sužinojau iš vyresniojo programinės įrangos inžinieriaus