Neatkarīgi no tā, vai strādājat ar datubāzi, kurā ir simti ierakstu vai miljonu ierakstu, vienmēr ir svarīgi pareizi veidot datubāzi. Tas ne tikai padarīs informācijas izgūšanu daudz vienkāršāku, bet arī vienkāršotu datubāzes paplašināšanu nākotnē. Diemžēl ir viegli iekļūt dažos lamatās, kas nākotnē var padarīt grūtības grūtāku.
Ir izveidotas veselas grāmatas par datubāzes normalizēšanu, bet, ja jūs vienkārši izvairieties no šīm bieži sastopamajām kļūdām, jums būs pareizā ceļa uz labu datubāzes dizainu.
Datubāzes kļūda # 1: atkārtošanās lauki tabulā
Labs datu bāzes dizains ir īkšķa pamatnoteikums, lai atpazītu atkārtotus datus un ievietotu šīs atkārtotās kolonnas savā tabulā. Tabulā atkārtotie lauki ir kopīgi tiem, kas ir izgājuši no izklājlapu pasaules, bet, lai gan izklājlapas parasti ir plānotas, datu bāzēm jābūt relatīvām. Tas ir tāpat kā no 2D uz 3D.
Par laimi, atkārtojas lauki parasti ir viegli pamanāmi. Apskatiet šo tabulu.
OrderID | Produkts1 | Produkts2 | Produkts3 |
1 | Teddy Bears | Želejas pupiņas | |
2 | Želejas pupiņas |
Kas notiek, ja pasūtījumā ir četri produkti? Lai atbalstītu vairāk nekā trīs produktus, mums jāpievieno vēl viens lauks. Un, ja mēs esam izveidojuši klientu aplikāciju pie galda, lai palīdzētu mums ievadīt datus, mums, iespējams, būs jāmaina tas ar jauno produktu lauku. Un kā mēs atrodam visus pasūtījumus ar Jellybeans kārtībā? Mēs būtu spiesti pieprasīt katram produkta laukam tabulā ar SQL paziņojumu, kas varētu izskatīties šādi: SELECT * FROM PRODUCTS WHERE Product1 = 'Jelly Beans' VAI produkts2 = 'Želejas pupiņas' OR Product3 = 'Želejas pupiņas'.
Tā vietā, lai izveidotu vienu tabulu, kas visu informāciju apkopo kopā, mums vajadzētu būt trīs tabulām, kurās katram ir atsevišķa informācija. Šajā piemērā mēs vēlētos, lai Pasūtījumu tabula ietvertu informāciju par pašu pasūtījumu, produktu tabulu ar visiem mūsu produktiem un ProductOrders planšetdatoru, kas saistīja produktus ar pasūtījumu.
OrderID | Klienta ID | Pasūtījuma datums | Kopā |
1 | 7 | 1/24/17 | 19.99 |
2 | 9 | 1/25/17 | 24.99 |
ProductID | Produkts | Skaits |
1 | Teddy Bears | 1 |
2 | Želejas pupiņas | 100 |
ProductOrderID | ProductID | OrderID |
101 | 1 | 1 |
102 | 2 | 1 |
Piezīme, kā katrai tabulai ir savs unikālais ID lauks. Šī ir galvenā atslēga. Mēs sasaistām tabulas, izmantojot primāro atslēgu vērtību kā ārēju atslēgu citā tabulā. Lasiet vairāk par primārajiem un ārējiem taustiņiem.
Datubāzes kļūda # 2: tabulas ievietošana tabulā
Šī ir vēl viena izplatīta kļūda, taču tā ne vienmēr izceļas tikpat daudz kā atkārtojas. Izstrādājot datu bāzi, jūs vēlaties pārliecināties, vai visi tabulā esošie dati attiecas uz sevi. Tā ir tā bērna spēle, kas parāda atšķirību. Ja jums ir banāns, zemeņu, persiku un televizors, televizors, iespējams, pieder kaut kur citur.
Līdzīgi, ja jums ir pārdevēju tabula, visa tabulā esošā informācija ir tieši saistīta ar šo pārdevēju. Jebkura papildu informācija, kas nav tikai šī pārdošanas persona, var piederēt kaut kur citur jūsu datu bāzē.
SalesID | Vispirms | Pēdējais | Adrese | Telefona numurs | Birojs | OfficeNumber |
1 | Sam | Elliots | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
2 | Alisa | Smits | 504 2nd Street, Ņujorka, NY | (211) 122-1821 | Ņujorka (Austrumi) | (211) 855-4541 |
3 | Joe | Pagasts | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Lai gan šī tabula varētu izskatīties tāpat kā tas attiecas uz atsevišķu pārdevēju, tabulā tas ir iekļauts tabulā. Norādiet, kā Birojs un OfficeNumber atkārtojas ar "Austin Downtown". Ko darīt, ja mainās biroja tālruņa numurs? Jums vajadzētu atjaunināt visu datu kopu, mainot vienu informācijas vienību, kas nekad nav laba lieta. Šie lauki jāpārvieto uz savu galdu.
SalesID | Vispirms | Pēdējais | Adrese | Telefona numurs | OfficeID |
1 | Sam | Elliots | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
2 | Alisa | Smits | 504 2nd Street, Ņujorka, NY | (211) 122-1821 | 2 |
3 | Joe | Pagasts | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
OfficeID | Birojs | OfficeNumber |
1 | Austin Downtown | (212) 421-2412 |
2 | Ņujorka (Austrumi) | (211) 855-4541 |
Šāda veida dizains arī ļauj jums pievienot papildu informāciju Biroja galdam, neradot pārmērīgas murgu tirdzniecības personāla galdam. Iedomājieties, cik daudz darba būtu vienkārši izsekot ielas adresei, pilsētai, valstij un pasta indeksam, ja visa šī informācija būtu pārdevēju galda sarakstā!
Datu bāzes kļūda Nr. 3: divu vai vairāk informācijas nodošana vienā laukā
Biroja informācijas ievietošana pārdevēju galda sarakstā nebija vienīgā problēma ar šo datubāzi. Adreses laukā bija trīs informācijas elementi: ielas adrese, pilsēta un valsts. Katrā datu bāzes laukā ir jābūt tikai vienai informācijas daļai. Ja vienā laukā ir vairāki informācijas elementi, datu bāzei var būt grūtāk iegūt informāciju.
Piemēram, ko darīt, ja mēs vēlētos palaist vaicājumu visiem Austin pārdošanas darbiniekiem? Mums vajadzētu meklēt adreses laukā, kas ir ne tikai neefektīvs, bet var atdot sliktu informāciju. Galu galā, kas notiek, ja kāds dzīvo Ostinas ielā Portlendā, Oregonā?
Lūk, kāds ir galds:
SalesID | Vispirms | Pēdējais | Adrese 1 | Adrese 2 | Pilsēta | Valsts | Zip | Tālrunis |
1 | Sam | Elliots | 118 galvenā sv | Austin | TX | 78720 | 2155555858 | |
2 | Alisa | Smits | 504 2. st | Ņujorka | NY | 10022 | 2111221821 | |
3 | Joe | Pagasts | 428 Aker St | Ap 304 | Austin | TX | 78716 | 2155455545 |
Šeit ir jāņem vērā pāris lietas. Pirmkārt, "Address1" un "Address2", šķiet, ietilpst kļūdu atkārtojošos laukos.
Tomēr šajā gadījumā tie attiecas uz atsevišķiem datiem, kas attiecas tieši uz pārdevēju, nevis uz atkārtotu datu grupu, kas jāiekļauj savā tabulā.
Tāpat kā bonusa kļūda, lai izvairītos, pamanīsiet, kā no tabulas ir noņemts tālruņa numura noformējums. Jums vajadzētu izvairīties no lauku formāta saglabāšanas, kad tas ir iespējams. Tālruņa numuru gadījumā ir vairāki veidi, kā cilvēki pieraksta tālruņa numuru: 215-555-5858 vai (215) 555-5858. Tas ļautu meklēt pārdevēju pēc viņu tālruņa numura vai apgrūtināt to, ka pārdošanas cilvēki meklē tajā pašā apgabala kodu.
Datubāzes kļūda # 4: nepareizas primārās atslēgas izmantošana
Vairumā gadījumu jūs vēlaties izmantot primāro atslēgu automātiski palielinošam skaitlim vai citam radītam skaitlim vai burtciparu skaitlim. Jums vajadzētu izvairīties no jebkādas primārās atslēgas faktiskās informācijas, pat ja tas izklausās kā labs identifikators.
Piemēram, katram mums ir savs individuālais sociālās apdrošināšanas numurs, tādēļ darbinieku datu bāzes sociālā nodrošinājuma numura izmantošana var likties kā laba ideja. Bet, lai gan reti, ir iespējams pat sociālās apdrošināšanas numurs mainīties, un mēs nekad nevēlamies mainīt galveno atslēgu.
Un tā ir problēma, izmantojot faktisko informāciju kā galveno vērtību. Tas var mainīties.
Datubāzes kļūda # 5: neizmantojot nosaukumu konvenciju
Tas varētu izklausīties kā liels darījums, kad pirmo reizi sācāt izstrādāt datubāzi, bet, tiklīdz jūs nokļūsit rakstīšanas vaicājumu datu bāzē, lai iegūtu informāciju, nosaukumu konvencija palīdzēs iegaumēt lauku nosaukumus.
Iedomājieties, cik daudz sarežģītāks būtu šis process, ja vārdi tiktu saglabāti kā pirmais vārds, LastName vienā tabulā un first_name, last_name citā tabulā.
Divas vispopulārākās nosaukumu konvencijas lielā formā izmanto pirmā katra vārda burtu laukā vai atdala vārdus, izmantojot pasvītras zīmi. Varat arī redzēt dažus izstrādātājus, kuri kapitalizē katra vārda pirmo burtu, izņemot pirmo vārdu: firstName, lastname.
Jūs arī vēlaties izlemt par atsevišķu tabulas nosaukumu vai daudzskaitļa tabulu nosaukumu izmantošanu. Vai tas ir pasūtījumu tabula vai pasūtījumu tabula? Vai tas ir klientu tabula vai klientu tabula? Atkal jūs nevēlaties būt iestrēdzis ar pasūtījumu tabulu un klientu tabulu.
Jūsu izvēlēto nosaukumu pieņemšanas konvencija nav tik svarīga kā process, kurš faktiski izvēlas un pieliek vārdu konvenciju.
Datubāzes kļūda # 6: nepareiza indeksācija
Indeksēšana ir viena no visgrūtāk izdarītajām lietām, jo īpaši jaunajām datu bāzu dizainā. Visiem primārajiem un ārējiem taustiņiem jābūt indeksētiem. Tie ir saites tabulas kopā, tādēļ bez indeksa jūs redzēsiet ļoti sliktu veiktspēju no savas datu bāzes.
Bet pārāk bieži tiek pazaudēti arī citi lauki. Tie ir lauki "KUR". Ja jūs bieži mēģināt sašaurināt meklēšanu, izmantojot lauku WHERE klauzulā, jūs vēlaties padomāt par indeksa ievietošanu šajā jomā. Tomēr jūs nevēlaties pārmērīgi indeksēt tabulu, kas var arī ietekmēt veiktspēju.
Kā izlemt? Tas ir daļa no datubāzes dizaina mākslas. Cik daudz indeksu jums vajadzētu likt uz galda, nav stingru ierobežojumu. Pirmkārt, jūs vēlaties indeksēt jebkuru jomu, kas bieži tiek izmantota WHERE klauzulā. Lasiet vairāk par datubāzes pareizu indeksēšanu.