Պետք է արդյոք իմ տվյալների շտեմարանը նորմալացնել:

Բարելավում իրական աշխարհում

Տվյալների բազայի կարգավորումը կիրառման զարգացման սրբազան կովերից է: Յուրաքանչյուր բակալավրիատի ծրագրավորման դասընթաց եք ստացել կամ գիրք, որը կարդացել եք, հավանաբար քարոզում է տվյալների բազաների նորմալացման կարեւորությունը:

Ժամանակն է մարտահրավեր նետել այդ ճշմարտությունը: Երբեմն դա OK է denormalize ձեր բազան:

Երբ պետք է նորմալացվի

Տվյալների բազայի կարգավորումը պաշտպանում է ձեր տվյալների ամբողջականությունը: Շատ դեպքերում դա մեծ գաղափար է, եւ դուք պետք է սկսեք ցանկացած տվյալների բազայի ձեւավորում `ձգտելով վերականգնել նորմալացումը: Եթե ​​դուք կարող եք կարգավորել ձեր տվյալների բազան, գնացեք դրա համար: Փաստորեն, Ահա որոշ գործնական խորհուրդներ, թե ինչպես կարգավորել ձեր տվյալների բազան այս կայքում:

Ներքեւի տողը այն է, որ դուք պետք է նորմալացնեք ձեր տվյալների բազան, եթե չլինեք իրական պատճառ չունեք: Normalizing սովորաբար ձայնային դիզայնի պրակտիկան: Այն կրճատում է ավելորդ տեղեկատվությունը, օպտիմալացնում է կատարումը եւ նվազեցնում հավանականությունը, որ դուք կունենաք տվյալների ամբողջականության խնդիրներ, որոնք հանգեցնում են տվյալների բազայի տարբեր անկյուններում պահվող նույն տվյալների հետ:

Որոշ լավ պատճառներ չկարգավորելու համար

Դա ասել է, որ կան բազում պատճառներ, որոնք չեն կարգավորելու ձեր տվյալների բազան: Եկեք մի քանիին նայենք.

  1. Միանալը թանկ է : Ձեր բազայի նորմալացումը հաճախ պարունակում է բազմաթիվ աղյուսակներ: Փաստորեն, դուք կարող եք հեշտությամբ քշել այն, ինչ կարծում եք, պետք է լինի պարզ հարց, որը տարածում է հինգ կամ 10 սեղան: Եթե ​​դուք երբեւէ փորձել եք հինգ սեղանի միացում կատարել, գիտեք, որ այն աշխատում է սկզբունքորեն, բայց գործնականում դանդաղորեն դանդաղ է: Եթե ​​դուք կառուցում եք վեբ ծրագիր, որը հիմնված է բազում սեղանների վրա բազմակի միացումների վրա հիմնված հարցումների վրա, կարող եք գաղափարների մասին մտածել, «եթե միայն այս բազան չի կարգավորվել»: Երբ ձեր գլխում այդ մտքերը լսես, դա լավ ժամանակ է հաշվի առեք հսկողությունը: Եթե ​​դուք կարող եք ձգել բոլոր հարցումները, որոնք օգտագործված են այդ հարցման մեջ, մեկ սեղանի վրա, առանց իսկապես վտանգելով ձեր տվյալների ամբողջականությունը, գնացեք այն: Դառնալ ապստամբ եւ denormalize ձեր տվյալների բազան: Դուք չեք նայում ետ:
  2. Նորմալ դիզայնը դժվար է : Եթե ​​դուք աշխատում եք բարդ տվյալների շտեմարանի հետ , ապա հավանաբար կկարողանաք գտնել ձեր գլուխը սեղանի շուրջ `կարգավորելու բարդությունը: Որպես պարզ կանոն, եթե դուք ամբողջ օրը ծախսում եք `փորձելով պարզել, թե ինչպես պետք է տեղափոխել չորրորդ նորմալ ձեւը, կարող եք չափազանց շատ կարգավորում ստանալ: Վերադարձեք եւ խնդրեք ինքներդ ձեզ, արդյոք արժե շարունակել:
  1. Արագ եւ կեղտոտ լինելը պետք է լինի արագ եւ կեղտոտ : Եթե ​​դուք պարզապես զարգացնում եք նախատիպը, ապա անմիջապես անում եք այն, ինչ արագ աշխատում է: Իրականում: Ամեն ինչ կարգին է. Արագ կիրառման զարգացումը երբեմն ավելի կարեւոր է, քան էլեգանտ դիզայնը: Պարզապես հիշեք, որ վերադարձեք եւ ուշադիր նայեք ձեր դիզայնին, երբ դուք պատրաստ եք անցնել նախատիպի փուլից դուրս: Գինը, որը վճարում եք արագ եւ կեղտոտ տվյալների շտեմարանների դիզայնի համար, այն է, որ դուք պետք է գցեք այն եւ սկսեք այն ժամանակ, երբ ժամանակն է արտադրության համար կառուցել:
  2. Եթե ​​օգտագործում եք NoSQL տվյալների բազա , ավանդական կարգավորումը ցանկալի չէ: Փոխարենը, նախագծեք ձեր բազան, օգտագործելով BASE մոդելը, որն ավելի շատ ներողամիտ է: Սա օգտակար է, երբ դուք պահեստավորում եք ոչ կառուցվածքային տվյալներ, ինչպիսիք են էլ-նամակներ, պատկերներ կամ տեսանյութեր:

Որոշակի բառեր

Տվյալների շտեմարանի կարգավորումը, ընդհանուր առմամբ, լավ գաղափար է: Դուք պետք է փորձեք հետեւել կարգավորումների սկզբունքներին, երբ դա ողջամիտ է դա անել: Բայց եթե բոլոր ցուցանիշները ցույց են տալիս, որ կարգավորումը շատ բարդ է իրականացնել, հաշվի առեք այն մոտեցումը, որը կստանձնի աշխատանքը, մինչդեռ ձեր տվյալները պաշտպանվում են:

Վերջապես, եթե դուք ընտրում եք շրջանցել նորմալացման կանոններից, լրացուցիչ զգոն լինեք, թե ինչպես եք իրականացնում տվյալների բազայի ամբողջականությունը: Եթե ​​դուք պահեստավորում եք ավելորդ տեղեկությունները, տեղադրեք խափանման միջոցները եւ այլ ստուգումներ, որպեսզի համոզվեք, որ տեղեկատվությունը մնում է հետեւողական: