Bieži sastopamās kļūdas datubāzē

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.