Skupne napake v izdelavi baz podatkov

Ne glede na to, ali delate z bazo podatkov, ki ima na stotine zapisov ali milijone zapisov, je pravilna oblika baze podatkov vedno pomembna. Ne samo, da bo olajšal pridobivanje informacij, ampak bo tudi v prihodnje poenostavil širitev baze podatkov. Na žalost je enostavno padati v nekaj pasti, ki lahko v prihodnosti otežijo stvari.

Obstajajo celotne knjige o normalizaciji baze podatkov, vendar, če se preprosto izognete tem običajnim napakam, boste na pravi poti do dobrega oblikovanja baz podatkov.

Napaka podatkovne baze # 1: ponavljanje polj v tabeli

Osnovno pravilo za dobro zasnovo baz podatkov je prepoznavanje ponavljajočih se podatkov in ponovitev stolpcev v njihovi tabeli. Ponavljajoča se polja v tabeli so pogosta za tiste, ki so prišli iz sveta preglednic, vendar pa so preglednice ponavadi ravne po zasnovi, podatkovne baze morajo biti relacijske. To je kot od 2D do 3D.

Na srečo so ponavljajoča polja ponavadi lahka. Oglejte si to tabelo:

Kaj se zgodi, če naročilo vsebuje štiri izdelke? V tabelo moramo dodati še eno polje za podporo več kot treh izdelkih. In če smo zgradili odjemalsko aplikacijo po mizi, ki nam bo pomagala pri vnosu podatkov, jo bomo morda morali spremeniti z novim področjem izdelkov. In kako najdemo vse naloge z Jellybeans v redu? V tabeli bomo morali natisniti vsako polje izdelka z izjavo SQL, ki bi lahko bila videti: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' ALI Product2 = 'Jelly Beans' ALI Product3 = 'Jelly Beans'.

Namesto, da bi imeli eno samo mizo, ki bi združevala vse informacije skupaj, bi morali imeti tri tabele, od katerih ima vsak ločen del informacij. V tem primeru bi želeli tabelo naročil z informacijami o samem naročilu, tabeli izdelkov z vsemi našimi izdelki in tabletom ProductOrders, ki so izdelke povezali z naročilom.

Upoštevajte, kako ima vsaka tabela lastno edinstveno polje ID. To je primarni ključ. Tabele povežemo z uporabo primarnega ključa kot tujega ključa v drugi tabeli. Preberite več o primarnih ključih in tujih ključih.

Napaka baze podatkov # 2: Vdelava tabele v tabelo

To je še ena pogosta napaka, vendar se vedno ne izstopa precej kot ponavljajoča se polja. Pri oblikovanju baze podatkov se želite prepričati, da se vsi podatki v tabeli nanašajo na samega sebe. To je kot otroška igra o opazovanju, kaj je drugače. Če imate banane, jagode, breskev in televizijski sprejemnik, televizor verjetno pripada drugam.

V enakih vrsticah, če imate tabelo prodajnih ljudi, morajo biti vsi podatki v tej tabeli posebej povezani s to prodajno osebo. Morebitne dodatne informacije, ki niso edinstvene za to prodajno osebo, so lahko v vaši bazi podatkov nekje drugje.

Čeprav lahko ta tabela izgleda kot povezana s posameznim prodajalcem, ima dejansko tabelo, ki je vdelana v tabelo. Upoštevajte, kako Office in OfficeNumber ponavljata z "Austin Downtown". Kaj, če se spremeni številka uradnega telefona? Za en sam kos informacij je treba posodobiti celoten niz podatkov, kar ni nikoli dobra stvar. Ta polja je treba premakniti v svojo tabelo.

Ta oblika omogoča tudi, da v tabelo Office dodate dodatne informacije, ne da bi ustvarili nočno moro nereda v tabeli prodajnih oseb. Predstavljajte si, koliko dela bi bilo, če bi preprosto spremljali ulico, mesto, državo in poštno številko, če bi bili vsi podatki v tabeli prodajne osebe!

Napaka podatkovne baze # 3: Prenos dveh ali več podatkov v eno samo polje

Vdelovanje pisarniških informacij v tabelo prodajne osebe ni bilo edina težava s to bazo podatkov. Naslovno polje vsebuje tri podatke: ulico, mesto in državo. Vsako polje v bazi podatkov mora vsebovati le en sam kos informacij. Ko v enem polju imate več informacij, lahko težje poizveduje po podatkih baze podatkov.

Na primer, kaj če bi želeli zagnati poizvedbo pri vseh prodajalcih iz Austina? V polje za naslov bi morali iskati, kar ni le neučinkovito, ampak lahko vrne slabe podatke. Konec koncev, kaj se zgodi, če bi nekdo živel na ulici Austin v Portlandu v Oregonu?

Tukaj je, kakšna mora biti miza:

Tukaj je nekaj stvari. Prvič, "Address1" in "Address2" se zdi, da spadajo pod napako ponavljajočih se polj.

V tem primeru pa se nanašajo na ločene podatke, ki se neposredno nanašajo na prodajno osebo in ne na ponavljajočo se skupino podatkov, ki bi morala biti v svoji tabeli.

Tudi kot bonusna napaka, da bi se izognili, opazite, kako je bilo oblikovanje za telefonsko številko izločeno iz tabele. Izogibajte se shranjevanju oblike polj, kadar koli je to mogoče. V primeru telefonskih številk je na voljo več načinov, kako ljudje napišejo telefonsko številko: 215-555-5858 ali (215) 555-5858. To bi otežilo iskanje prodajne osebe po svoji telefonski številki ali iskanju prodajnih ljudi v isti področni kodi.

Napaka v bazi podatkov # 4: neuporaba pravilnega primarnega ključa

V večini primerov boste za primarni ključ želeli uporabljati samodejno povečevalno številko ali drugo generirano številko ali alfanumerično. Izogibajte se uporabi dejanskih podatkov za primarni ključ, tudi če se sliši, kot da bi bil dober identifikator.

Vsakdo ima na primer svojo individualno številko socialnega zavarovanja, zato bi lahko z uporabo številke socialnega zavarovanja za bazo podatkov zaposlenih morda všeč dobra ideja. Toda čeprav je redka, je mogoče spremeniti številko socialnega zavarovanja in nikoli ne želimo spremeniti prvega ključa.

In to je težava pri uporabi dejanskih informacij kot ključne vrednosti. Lahko se spremeni.

Napaka baze podatkov # 5: ne uporablja konvencije za poimenovanje

To se morda ne zdi kot velika stvar, ko najprej začnete načrtovati svojo bazo podatkov, vendar ko pridete do točke pisanja poizvedb z baze podatkov, da pridobite podatke, vam bo po dogovoru s poimenovanjem pomagalo, ko boste zapomnili imena polj.

Zamislite si, kako težje bi bil ta proces, če so imena shranjena kot FirstName, LastName v eni tabeli in first_name, last_name v drugi tabeli.

Dva najbolj priljubljena poimenovanja poimenovanja sta kapitalizacija prve črke vsake besede na terenu ali ločevanje besed z uporabo podčrtaje. Morda boste videli tudi nekatere programerje, ki kapitalizirajo prvo črko vsake besede, razen prve besede: firstName, lastName.

Prav tako se boste želeli odločiti za uporabo enotnih imen tabel ali imen množine. Ali je tabela naročil ali tabela naročil? Ali je tabela stranke ali tabele strank? Še enkrat, ne želite biti zaljubljen z naročilnico in tabelo strank.

Konvencija o poimenovanju, ki jo izberete, ni tako pomembna kot proces dejanskega izbiranja in ohranjanja konvencije o poimenovanju.

Napaka baze podatkov # 6: Neprimerno indeksiranje

Indeksiranje je ena izmed najtežjih stvari, ki jih je mogoče dobiti, zlasti za tiste nove pri oblikovanju baz podatkov. Vse primarne ključe in zunanje ključe je treba indeksirati. To je tisto, kar povezuje tabele skupaj, tako da brez indeksa, boste videli zelo slabo zmogljivost iz vaše baze podatkov.

Toda prevečkrat se pogrešajo druga področja. To so polja "WHERE". Če pogosto zožite iskanje z uporabo polja v klavzuli WHERE, si želite razmisliti o postavljanju indeksa na to polje. Vendar ne želite preveč indeksirati tabele, kar bi lahko tudi škodilo uspešnosti.

Kako se odločiti? To je del umetnosti načrtovanja baz podatkov. Ni omejitev glede števila indeksov, ki jih morate dati v tabelo. Najprej želite indeksirati katero koli polje, ki se pogosto uporablja v določbi WHERE. Preberite več o pravilnem indeksiranju vaše baze podatkov.