Komunaj Eraroj Faritaj en Datumara Dezajno

Ĉu vi laboras kun datumbazo, kiu tenas centojn da rekordoj aŭ milionoj da rekordoj, taŭga datumbaza dezajno estas ĉiam grava. Ne nur ĝi faros multe pli facile retrovi la informon, ankaŭ simpligos vastigi la datumbazon en la estonteco. Bedaŭrinde, estas facile fali en kelkajn kaptilojn, kiuj povas fari malfacilaĵojn en la estonteco.

Ekzistas kompletaj libroj skribitaj pri la normala normo, sed se vi simple evitas ĉi tiujn komunajn erarojn, vi estos sur la ĝusta vojo al bona datumbazo.

Datuma Eraro # 1: Ripetanta Kampoj en Tablo

Baza regulo de dikfingro por bona datumbaza dezajno estas rekoni ripetantajn datumojn kaj meti tiujn ripetajn kolumnojn en sia propra tablo. Repektaj kampoj en tablo estas komuna por tiuj, kiuj venis el la mondo de folioj, sed dum disvastiĝoj ŝajnas esti ebenaj laŭ dezajno, datumbazoj devus esti rilata. Ĝi estas kiel iranta de 2D al 3D.

Feliĉe, ripetaj kampoj kutime estas facile facilaj. Nur rigardu ĉi tiun tablon:

Kio okazas kiam ordo enhavas kvar produktojn? Ni bezonus aldoni alian kampon al la tablo por subteni pli ol tri produktojn. Kaj se ni konstruis klientan aplikaĵon ĉirkaŭ la tablo por helpi nin enigi informojn, ni eble bezonos modifi ĝin per la nova produkta kampo. Kaj kiel ni trovas ĉiujn ordojn kun Jellybeans en la ordo? Oni devos demandi ĉiun produktan kampon en la tablo kun SQL-komunikaĵo, kiu povus aspekti: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' OR Product2 = 'Jelly Beans' OR Product3 = 'Jelly Beans'.

Anstataŭ havi unu tablon, kiu kunigas ĉiujn informojn kune, ni devus havi tri tabulojn, ke ĉiu tenas distingan informon. En ĉi tiu ekzemplo, ni dezirus Ordon-tablon kun informoj pri la ordo mem, produkto-tabelo kun ĉiuj niaj produktoj kaj produktaĵaj tablojdoj kiuj ligis produktojn al la ordo.

Rimarku, kiel ĉiu tablo havas sian propran solan ID-kampo. Ĉi tiu estas la ĉefa ŝlosilo. Ni ligas tabulojn per primara kerna valoro kiel fremda ŝlosilo en alia tablo. Legu pli pri primaraj klavoj kaj eksterlandaj klavoj.

Datuma Malŝovo # 2: Enmetanta Tablon en Tablo

Ĉi tio estas alia komuna eraro, sed ĝi ne ĉiam elstaras tiom multe kiel ripetaj kampoj. Kiam vi desegnas datumbazon, vi volas certigi, ke ĉiuj datumoj en tablo rilatas al si mem. Ĝi estas kiel tiu infana ludo pri rimarkado de tio, kio estas malsama. Se vi havas bananon, frago, persiko kaj televida aro, la televida serio probable apartenas aliloke.

Samtempe, se vi havas tablon de vendaj homoj, ĉiuj informoj en tiu tablo devas rilatigi specife al tiu vendisto. Ajna ekstra informo, kiu ne estas unika al tiu venda persono, povas esti aparte en via datumbazo.

Dum ĉi tiu tablo eble aspektas, ĉio rilatas al la individua vendisto, ĝi efektive havas tablon enigita ene de la tablo. Rimarku kiel la Oficejo kaj OfficeNumber ripetas kun "Austin Downtown". Kion se telefona nombro ŝanĝiĝas? Vi bezonus ĝisdatigi tutan aron da datumoj por unu sola peco de informo ŝanĝanta, kio neniam estas bona afero. Ĉi tiuj kampoj devas esti movitaj al sia propra tablo.

Ĉi tiu tipo de dezajno ankaŭ donas al vi la kapablon aldoni plian informon al la Oficeja tablo sen krei koŝmaron de malordo en la venda persono tablo. Imagu, kiom da laboro estus simple kontroli la straton, urbon, ŝtaton kaj zip-kodon, se ĉiuj ĉi informoj estis en la venda persono tablo!

Datuma Eraro # 3: Metanta Du aŭ Pli da Pecoj de Informo En Ununura Kampo

Enkorpigi la oficejan informon en la vendotabla tablo ne estis la sola problemo kun tiu datumbazo. La adresa kampo enhavis tri pecojn da informoj: la strato, la urbo kaj la ŝtato. Ĉiu kampo en la datumbazo nur enhavas unu solan informon. Kiam vi havas multoblajn informojn en ununura kampo, ĝi povas pli malfacile demandi la datumbazon por informoj.

Ekzemple, ĉu ni volus ekzameni pri ĉiuj vendistoj de Austin? Ni bezonus serĉi ene de la adreso, kiu ne nur estas neefika, sed povas reveni malbonan informon. Post ĉio, kio okazas se iu loĝis en Austin-strato en Portland, Oregono?

Jen kio aspektas la tablo:

Estas kelkaj aferoj rimarki ĉi tie. Unue, "Adreso1" kaj "Address2" ŝajnas fali sub la ripetaj kampoj eraro.

Tamen, en ĉi tiu kazo ili rilatas al apartaj pecoj de datumoj, kiuj rilatas rekte al la venda persono anstataŭ al ripetanta grupo de datumoj, kiuj devus eniri en sia propra tablo.

Ankaŭ, kiel bonŝanca eraro eviti, rimarku, kiel la formato por la telefona nombro estis forigita de la tablo. Vi devas eviti konservi la formaton de kampoj kiam ajn ebla. En la kazo de telefonaj nombroj, ekzistas multaj manieroj skribi telefonan numeron: 215-555-5858 aŭ (215) 555-5858. Ĉi tio farus serĉadon de vendisto per sia telefona nombro aŭ serĉado de vendoj homoj en la sama areo kodo pli malfacila.

Datuma Eraro # 4: Ne Uzante Ĝustan Priman Ŝlosilon

En plej multaj okazoj, vi volas uzi aŭtomate pliiĝantan nombro aŭ iu alia generita nombro aŭ alfanumera por via primara ŝlosilo. Vi devas eviti uzi ajnan realan informon por la ĉefa ŝlosilo, eĉ se ĝi ŝajnas, ke ĝi farus bonan identigilon.

Ekzemple, ni ĉiuj havas nian propran individuan socian sekurecan numeron, do uzante la socian sekurecan numeron por dungito-datumbazo eble ŝajnas bonan ideon. Sed malofte, eĉ ebla por ŝanĝi socian sekurecan numeron, kaj ni neniam volas ke nia ĉefa ŝlosilo ŝanĝu.

Kaj tio estas la problemo per uzado de reala informo kiel ŝlosila valoro. Ĝi povas ŝanĝi.

Datuma Eraro # 5: Ne Uzanta Konferencan Konvencion

Ĉi tio eble ne ŝajnas grandan interkonsenton kiam vi unue komencis desegni vian datumbazon, sed unufoje vi atingos la punkton de skribado de demandoj kontraŭ la datumbazo por rekuperi informon, havante nombron de konvencioj helpos, kiel vi memorigas kampojn nomojn.

Simple imagu kiom pli malfacila tiu procezo estus, se nomoj estis konservitaj kiel FirstName, LastName en unu tablo kaj unua nomo, lasta nomo en alia tablo.

La du plej popularaj nomumaj konvencioj kapitulacas la unuan leteron de ĉiu vorto en la kampo aŭ apartigas vortojn per suba teksto. Vi ankaŭ povas vidi iujn programistojn kapitulacigante la unuan literon de ĉiu vorto krom la unua vorto: firstName, lastName.

Vi ankaŭ volas decidi pri uzado de unuopaj tablojnomoj aŭ pluraj tabuloj. Ĉu ĝi estas Ordo-tablo aŭ Ordonoj-tablo? Ĉu ĝi estas Klienta tablo aŭ Klienta tablo? Denove, vi ne volas esti ligita kun Ordono-tablo kaj Klienta tablo.

La nomuma konvencio, kiun vi elektas, ne estas tiel grava kiel la procezo de fakte elektado kaj frapado al nomado-konvencio.

Malalta Datumaro # 6: Malfacila Indeksado

Indikado estas unu el la plej malfacilaj aferoj por ĝustigi, precipe por tiuj novaj en datumbaza dezajno. Ĉiuj primaj klavoj kaj eksterlandaj ŝlosiloj devas esti indeksitaj. Ĉi tiuj estas ligaj tabloj kune, do sen indekso, vi vidos tre malriĉan agadon el via datumbazo.

Sed kio tro ofte mankas estas la aliaj kampoj. Jen la kampoj "KIE". Se vi ofte mallarĝos vian serĉon per uzado de kampo en KAJ klaŭzo, vi volas pensi pri metado de indekso en tiu kampo. Tamen, vi ne deziras tro indiki la tablon, kiu ankaŭ povas vundi la agadon.

Kiel decidi? Ĉi tio estas parto de la arto de datumbazo-dezajno. Ne estas malmolaj limoj pri kiom da indeksoj vi devas meti sur tablon. Plejparte, vi volas indeksi ajnan kampon, kiu ofte uzas en laŭdosiero de DIE. Legu pli pri konvena indeksado de via datumbazo.