Karaniwang Pagkakamali Ginawa sa Disenyo ng Database

Kung nagtatrabaho ka sa isang database na nagtataglay ng daan-daang talaan o milyun-milyong talaan, ang tamang disenyo ng database ay laging mahalaga. Hindi lamang gagawin nito ang pagkuha ng impormasyon nang mas madali, mapapasimple din nito ang pagpapalawak ng database sa hinaharap. Sa kasamaang palad, madali itong mahulog sa ilang mga traps na maaaring gumawa ng mga bagay na mahirap sa hinaharap.

May mga buong libro na nakasulat sa paksa ng pag-normalize ng isang database, ngunit kung maiiwasan mo lamang ang mga karaniwang pagkakamali, ikaw ay nasa tamang track sa mahusay na disenyo ng database.

Database pagkakamali # 1: Uulit ng mga Patlang sa isang Table

Ang isang pangunahing patakaran ng hinlalaki para sa mahusay na disenyo ng database ay upang makilala ang paulit-ulit na data at upang ilagay ang mga paulit-ulit na haligi sa kanilang sariling talahanayan. Ang mga umuulit na larangan sa isang talahanayan ay karaniwan para sa mga na nanggaling sa mundo ng mga spreadsheet, ngunit habang ang mga spreadsheet ay malamang na maging flat sa pamamagitan ng disenyo, ang mga database ay dapat na pamanggit. Ito ay tulad ng pagpunta mula sa 2D sa 3D.

Sa kabutihang-palad, ang mga paulit-ulit na mga patlang ay karaniwang madaling makita. Basta tingnan ang talahanayan na ito:

Ano ang mangyayari kapag ang isang order ay naglalaman ng apat na mga produkto? Kailangan naming magdagdag ng isa pang patlang sa talahanayan upang suportahan ang higit sa tatlong mga produkto. At kung nagtayo kami ng isang client application sa paligid ng talahanayan upang matulungan kaming mag-input ng data, maaaring kailangan naming baguhin ito sa bagong larangan ng produkto. At paano namin makita ang lahat ng mga order sa mga Jellybeans sa pagkakasunud-sunod? Pipilitin kaming magtanong sa bawat larangan ng produkto sa talahanayan na may pahayag ng SQL na maaaring magmukhang: PUMILI * MULA SA MGA Produkto WHERE Product1 = 'Jelly Beans' O Product2 = 'Jelly Beans' O Product3 = 'Jelly Beans'.

Sa halip na magkaroon ng isang mesa na pinagsasama-sama ang lahat ng impormasyon, dapat kaming magkaroon ng tatlong mga talahanayan na ang bawat isa ay mayroong natatanging piraso ng impormasyon. Sa halimbawang ito, nais namin ang talahanayan ng Mga Order na may impormasyon tungkol sa order mismo, isang Produkto na talahanayan sa lahat ng aming mga produkto at isang ProductOrders tablet na naka-link sa mga produkto sa order.

Pansinin kung paano ang sariling talahanayan ay may sariling natatanging ID field. Ito ang pangunahing susi. I-link namin ang mga talahanayan sa pamamagitan ng paggamit ng pangunahing pangunahing halaga bilang isang banyagang susi sa isa pang talahanayan. Magbasa nang higit pa tungkol sa pangunahing mga susi at banyagang mga susi.

Database pagkakamali # 2: Pag-embed ng isang Table sa isang Table

Ito ay isa pang pangkaraniwang pagkakamali, ngunit hindi ito laging nakakaalam ng maraming mga paulit-ulit na mga patlang. Kapag nagdisenyo ng isang database, nais mong tiyakin na ang lahat ng data sa isang talaan ay may kaugnayan sa sarili nito. Ito ay tulad ng laro ng bata tungkol sa pagtutuklas kung ano ang naiiba. Kung mayroon kang saging, presa, peach at telebisyon, malamang na nabibilang sa ibang lugar.

Kasama ang parehong mga linya, kung mayroon kang isang talahanayan ng mga benta ng mga tao, ang lahat ng impormasyon sa mesa na dapat na partikular na nauugnay sa taong benta. Ang anumang dagdag na impormasyon na hindi natatangi sa taong benta ay maaaring pag-aari sa ibang lugar sa iyong database.

Habang ang table na ito ay maaaring magmukhang ito ay lahat na may kaugnayan sa indibidwal na salesperson, ito talaga ay may talahanayan na naka-embed sa loob ng talahanayan. Pansinin kung paano paulit-ulit ng Office and OfficeNumber ang "Downtown Austin". Paano kung ang pagbabago ng numero ng telepono ng opisina? Kakailanganin mong i-update ang isang buong hanay ng data para sa isang solong piraso ng pagbabago ng impormasyon, na hindi kailanman isang magandang bagay. Ang mga patlang na ito ay dapat ilipat sa kanilang sariling mesa.

Ang ganitong uri ng disenyo ay nagbibigay din sa iyo ng kakayahang magdagdag ng karagdagang impormasyon sa talahanayan ng Tanggapan nang hindi lumilikha ng isang bangungot ng kalat sa talahanayan ng mga benta ng tao. Isipin kung magkano ang trabaho ay upang subaybayan lamang ang address ng kalye, lungsod, estado at zip code kung ang lahat ng impormasyong iyon ay nasa talahanayan ng mga tao sa pagbebenta!

Database pagkakamali # 3: paglalagay ng dalawa o higit pang piraso ng impormasyon papunta sa isang Single Field

Ang pag-embed ng impormasyon sa opisina sa talahanayan ng tao sa pagbebenta ay hindi lamang ang problema sa database na iyon. Ang patlang ng address ay naglalaman ng tatlong piraso ng impormasyon: ang address ng kalye, ang lungsod at ang estado. Ang bawat patlang sa database ay dapat lamang maglaman ng isang solong piraso ng impormasyon. Kapag mayroon kang maraming mga piraso ng impormasyon sa isang solong patlang, maaari itong maging mas mahirap na query sa database para sa impormasyon.

Halimbawa, paano kung gusto naming magpatakbo ng isang query sa lahat ng mga benta mula sa Austin? Kailangan naming maghanap sa loob ng field ng address, na hindi lamang hindi mabisa, ngunit maaaring bumalik sa masamang impormasyon. Pagkatapos ng lahat, ano ang mangyayari kung may nakatira sa kalye ng Austin sa Portland, Oregon?

Narito kung ano ang magiging hitsura ng talahanayan:

Mayroong ilang mga bagay na dapat tandaan dito. Una, ang "Address1" at "Address2" ay tila nahulog sa ilalim ng mga paulit-ulit na pagkakamali ng mga patlang.

Gayunpaman, sa kasong ito ay tinutukoy nila ang magkakahiwalay na piraso ng data na nauugnay nang direkta sa tao sa pagbebenta sa halip na isang paulit-ulit na pangkat ng data na dapat pumunta sa sarili nitong mesa.

Gayundin, bilang isang pagkakamali ng bonus upang maiwasan, pansinin kung paano ang pag-format para sa numero ng telepono ay nakuha sa mesa. Dapat mong iwasan ang pag-iimbak ng format ng mga patlang kapag posible. Sa kaso ng mga numero ng telepono, maraming mga paraan ang nagsusulat ng numero ng telepono ng mga tao: 215-555-5858 o (215) 555-5858. Ito ay gumawa ng paghahanap para sa isang tao sa pagbebenta sa pamamagitan ng kanilang numero ng telepono o paggawa ng isang paghahanap ng mga benta ng mga tao sa parehong lugar code mas mahirap.

Database pagkakamali # 4: Hindi Paggamit ng isang Tamang Pangunahing Key

Sa karamihan ng mga pagkakataon, gugustuhin mong gamitin ang isang awtomatikong incrementing number o ilang iba pang nabuong numero o alphanumeric para sa iyong pangunahing susi. Dapat mong iwasan ang paggamit ng anumang aktwal na impormasyon para sa pangunahing susi kahit na parang ito ay magiging isang mabuting tagatukoy.

Halimbawa, bawat isa sa atin ay may sariling indibidwal na numero ng seguridad sosyal, kaya ang paggamit ng social security number para sa isang database ng empleyado ay maaaring tunog tulad ng isang magandang ideya. Ngunit bagaman bihirang, posible para sa kahit isang numero ng social security na baguhin, at hindi namin nais na baguhin ang aming pangunahing susi.

At iyon ang problema sa paggamit ng aktwal na impormasyon bilang isang mahalagang halaga. Maaari itong baguhin.

Error sa Database # 5: Hindi Paggamit ng Kombensyon sa Pag-uugnay

Maaaring hindi ito tunog tulad ng isang malaking pakikitungo kapag una mong sinimulan ang pagdidisenyo ng iyong database, ngunit sa sandaling nakarating ka sa punto ng pagsulat ng mga query laban sa database upang makuha ang impormasyon, ang pagkakaroon ng pagbibigay ng pangalan sa kombensyon ay makakatulong sa iyo kabisaduhin ang mga pangalan ng patlang.

Isipin kung gaano mas mahirap ang proseso kung ang mga pangalan ay nakaimbak bilang FirstName, LastName sa isang table at first_name, last_name sa isa pang table.

Ang dalawang pinakasikat na mga kombensiyal na pagbibigay ng pangalan ay ang paggamit ng unang titik ng bawat salita sa larangan o paghihiwalay ng mga salita gamit ang salungguhit. Maaari mo ring makita ang ilang mga developer na capitalizing ang unang titik ng bawat salita maliban sa unang salita: firstName, lastName.

Gusto mo ring magpasya sa paggamit ng mga pang-isahan na mga pangalan ng talahanayan o pangmaramihang mga pangalan ng talahanayan. Ito ba ay isang talahanayan ng Order o isang talahanayan ng Orders? Ito ba ay isang talahanayan ng Customer o talahanayan ng Mga Customer? Muli, hindi mo nais na ma-stuck sa isang table ng Order at isang Customers table.

Ang kombensyong pagbibigay ng pangalan na iyong pinili ay hindi mahalaga gaya ng proseso ng aktwal na pagpili at pananatili sa isang kombensiyal na pagbibigay ng pangalan.

Database pagkakamali # 6: Hindi tamang Pag-index

Ang pag-index ay isa sa pinakamahirap na bagay upang makakuha ng tama, lalo na para sa mga bago sa disenyo ng database. Dapat i-index ang lahat ng mga pangunahing key at banyagang key. Ito ang mga link ng mga talahanayan nang magkasama, kaya walang index, makakakita ka ng napakahirap na pagganap mula sa iyong database.

Ngunit ang mga madalas na napalampas ay ang iba pang mga larangan. Ito ang mga "SAAN" na mga patlang. Kung madalas kang magpapaikli sa iyong paghahanap sa pamamagitan ng paggamit ng isang patlang sa isang sugnay SAAN, nais mong isipin ang paglalagay ng isang indeks sa patlang na iyon. Gayunpaman, hindi mo nais na labis na i-index ang talahanayan, na maaari ring saktan ang pagganap.

Paano magpasya? Ito ay bahagi ng sining ng disenyo ng database. Walang mga mahigpit na limitasyon sa kung gaano karaming mga index ang dapat mong ilagay sa isang table. Lalo na, gusto mong i-index ang anumang field na madalas na ginagamit sa isang Sugnay na SAAN. Magbasa nang higit pa tungkol sa maayos na pag-index sa iyong database.