Greșelile obișnuite efectuate în proiectarea bazelor de date

Indiferent dacă lucrați cu o bază de date care deține sute de înregistrări sau milioane de înregistrări, proiectarea adecvată a bazelor de date este întotdeauna importantă. Nu numai că va face mult mai ușoară recuperarea informațiilor, ci va simplifica, de asemenea, extinderea bazei de date în viitor. Din păcate, este ușor să cadă în câteva capcane care pot face lucrurile greu în viitor.

Există cărți întregi scrise cu privire la normalizarea unei baze de date, dar dacă evitați pur și simplu aceste greșeli comune, veți fi pe drumul cel bun spre un design bun de baze de date.

Greseala de bază de date # 1: Repetarea câmpurilor dintr-un tabel

O regulă de bază pentru un design bun al bazei de date este recunoașterea repetată a datelor și plasarea acelor coloane repetate în propriul tabel. Repetarea câmpurilor într-un tabel este comună pentru cei care au venit din lumea foilor de calcul, dar în timp ce foile de calcul tind să fie plane de la proiectare, bazele de date ar trebui să fie relaționale. Este ca și cum ai merge de la 2D la 3D.

Din fericire, câmpurile repetitive sunt de obicei ușor de observat. Luați o privire la această masă:

Ce se întâmplă atunci când o comandă conține patru produse? Ar trebui să adăugăm un alt câmp la masă pentru a susține mai mult de trei produse. Și dacă am construit o aplicație client în jurul mesei pentru a ne ajuta să introducem date, este posibil să fie necesar să o modificăm cu noul câmp de produse. Și cum găsim toate ordinele cu Jellybeans în ordine? Ne-ar fi obligat să interogăm fiecare câmp de produs din tabel cu o instrucțiune SQL care ar putea să arate ca: SELECT * FROM Produse WHERE Product1 = 'Jelly Beans' sau Product2 = 'Jelly Beans' sau Product3 = 'Jelly Beans'.

În loc să avem o singură masă care să reunească toate informațiile împreună, ar trebui să avem trei mese care conțin fiecare câte o informație distinctă. În acest exemplu, dorim un tabel de comenzi cu informații despre comanda însăși, un tabel Products cu toate produsele noastre și o tabletă ProductOrders care leagă produsele de comanda.

Observați cum fiecare tabel are propriul câmp de ID unic. Aceasta este cheia primară. Legăm tabelele utilizând o valoare a cheii primare ca o cheie străină într-un alt tabel. Citiți mai multe despre cheile primare și cheile externe.

Greseala bazei de date # 2: încorporarea unei mese într-o tabelă

Aceasta este o altă greșeală obișnuită, dar nu este întotdeauna la fel de mare ca și câmpurile repetitive. Când proiectați o bază de date, doriți să vă asigurați că toate datele dintr-o tabelă se referă la ea însăși. Este ca jocul copilului despre observarea a ceea ce este diferit. Dacă aveți o banană, o căpșună, o piersică și un televizor, televizorul probabil aparține în altă parte.

În același mod, dacă aveți o tabelă de oameni de vânzări, toate informațiile din tabelul respectiv ar trebui să vizeze în mod specific acea persoană de vânzări. Orice informație suplimentară care nu este unică pentru acea persoană de vânzare poate să aparțină în altă parte din baza dvs. de date.

În timp ce acest tabel ar putea să pară că este vorba de un vânzător individual, acesta are de fapt o tabelă încorporată în tabel. Observați cum se repetă Office și OfficeNumber cu "Austin Downtown". Ce se întâmplă dacă se schimbă un număr de telefon al biroului? Va trebui să actualizați un întreg set de date pentru o singură piesă de schimbare a informațiilor, ceea ce nu este niciodată un lucru bun. Aceste câmpuri ar trebui să fie mutate pe masa proprie.

Acest tip de design vă oferă, de asemenea, posibilitatea de a adăuga informații suplimentare la masa de birou fără a crea un coșmar de dezordine în tabelul persoanelor de vânzări. Imaginați-vă cât de mult ar fi de făcut pentru a urmări pur și simplu adresa străzii, orașul, statul și codul poștal dacă toate aceste informații se găsesc în tabelul de persoane de vânzări!

Greseala bazei de date # 3: Punerea a două sau mai multe piese de informații într-un câmp unic

Încadrarea informațiilor despre birou în tabelul persoanelor de vânzări nu a fost singura problemă cu baza de date respectivă. Câmpul de adrese conținea trei informații: adresa străzii, orașul și statul. Fiecare câmp din baza de date ar trebui să conțină doar o singură informație. Când aveți mai multe informații într-un singur câmp, poate fi mai greu să interogați baza de date pentru informații.

De exemplu, dacă am fi vrut să executăm o interogare la toți vânzătorii din Austin? Ar trebui să căutăm în câmpul de adresă, care nu este numai ineficient, ci poate să returneze informații nepotrivite. La urma urmei, ce se întâmplă dacă cineva ar trăi pe strada Austin din Portland, Oregon?

Iata ce ar trebui sa arate masa:

Există câteva lucruri de remarcat aici. În primul rând, "Address1" și "Address2" pare să cadă sub eroarea de câmpuri repetitive.

Cu toate acestea, în acest caz, ele se referă la fragmente separate de date care se leagă direct de persoana de vânzări, mai degrabă decât un grup de date repetat care ar trebui să treacă în propriul tabel.

De asemenea, ca o greșeală bonus pentru a evita, observați modul în care formatarea pentru numărul de telefon a fost scos din masă. Ar trebui să evitați să stocați formatul câmpurilor atunci când este posibil. În cazul numerelor de telefon, există mai multe moduri în care oamenii scriu un număr de telefon: 215-555-5858 sau (215) 555-5858. Acest lucru ar face cautarea unei persoane de vânzări prin numărul de telefon sau efectuarea unei căutări a persoanelor de vânzări în același cod de zonă mai dificilă.

Greseala bazei de date # 4: nu folosiți o cheie primară corectă

În cele mai multe cazuri, veți dori să utilizați un număr incrementat automat sau alt număr generat sau alfanumeric pentru cheia primară. Ar trebui să evitați să folosiți orice informație actuală pentru cheia primară, chiar dacă se pare că ar fi un bun identificator.

De exemplu, fiecare dintre noi are propriul nostru număr de securitate socială, astfel încât utilizarea numărului de securitate socială pentru baza de date a unui angajat ar putea părea o idee bună. Dar, în timp ce este rare, este posibil ca chiar un număr de securitate socială să se schimbe și niciodată nu ne dorim ca cheia primară să se schimbe.

Și aceasta este problema utilizării informațiilor reale ca valoare-cheie. Se poate schimba.

Greseala de baze de date # 5: Nu folosiți o convenție de numire

Acest lucru nu s-ar părea o mare afacere atunci când ați început să vă proiectați baza de date, dar odată ce ați ajuns la punctul de a scrie interogări împotriva bazei de date pentru a prelua informații, având o convenție de numire va ajuta în timp ce memorați numele câmpurilor.

Imaginați-vă cât de dificil ar fi acest proces dacă ar fi fost stocate nume ca Nume, Nume într-un singur tabel și First_name, ultim_name într-un alt tabel.

Cele două convenții cele mai populare de numire sunt capitalizarea primei litere a fiecărui cuvânt din câmp sau separarea cuvintelor folosind o subliniere. De asemenea, este posibil să vedeți unii dezvoltatori care valorifică prima literă a fiecărui cuvânt, cu excepția primului cuvânt: firstName, lastName.

Veți dori, de asemenea, să decideți despre utilizarea unor nume de tabele singulare sau nume de tabele plural. Este un tabel de comenzi sau un tabel de comenzi? Este o tabelă de clienți sau o tabelă pentru clienți? Din nou, nu doriți să fiți blocați cu un tabel de comenzi și un tabel pentru clienți.

Convenția de numire pe care o alegeți nu este la fel de importantă ca și procesul de alegere și de a se lipi de o convenție de numire.

Greseala bazei de date # 6: Indexarea incorectă

Indexarea este unul dintre cele mai grele lucruri pentru a avea dreptate, mai ales pentru cei noi la proiectarea bazei de date. Toate cheile primare și cheile străine ar trebui indexate. Acestea sunt tabelele de legătură împreună, deci fără un index, veți vedea performanțe foarte slabe din baza dvs. de date.

Dar ceea ce este prea rar pierdut sunt celelalte domenii. Acestea sunt câmpurile "WHERE". Dacă adesea îți vei îngusta căutarea folosind un câmp într-o clauză WHERE, vrei să te gândești la punerea unui index pe acel câmp. Cu toate acestea, nu doriți să indice prea mult masa, ceea ce poate afecta și performanța.

Cum să decidem? Aceasta este o parte a artei bazei de date. Nu există limite grele asupra numărului de indici pe care ar trebui să-i puneți pe o masă. În primul rând, doriți să indexați orice câmp care este folosit frecvent într-o clauză WHERE. Citiți mai multe despre indexarea corectă a bazei dvs. de date.