Нармалізацыя ў рэальным свеце
Нармалізацыя базы дадзеных з'яўляецца адной з святых кароў распрацоўкі прыкладанняў. Кожны курс навучанне для праграмавання вы зрабілі ці кнігі , якую вы чыталі , верагодна , прапаведуе важнасць нармалізацыі баз дадзеных .
Прыйшоў час, каб кінуць выклік, што труізм. Часам гэта нармальна денормализовать вашу базу дадзеных!
Калі вы павінны Нармалізацыя?
Нармалізацыя базы дадзеных абараняе цэласнасць вашых дадзеных. Гэта выдатная ідэя, у многіх выпадках, і вы павінны пачаць любы дызайн высілак базы дадзеных з нармалізацыяй у выглядзе. Калі вы можаце нармалізаваць базу дадзеных, пайсці на гэта! На самай справе, вось некаторыя практычныя парады аб тым, як нармалізаваць базу дадзеных на гэтым сайце:
- Ўвод базы дадзеных у першай нармальнай форме (1NF)
- Ўвод вашай базы дадзеных у другой нармальнай форме (2НФ)
- Ўвод базы дадзеных у трэцяй нармальнай форме (2НФ)
Сутнасць заключаецца ў тым, што вы павінны нармалізаваць базу дадзеных , калі ў вас ёсць сапраўды важкія прычыны не рабіць гэтага. Нармалізацыя звычайна гукавы дызайн практык. Гэта памяншае залішнюю інфармацыю, аптымізуе прадукцыйнасць і памяншае верагоднасць таго, што вы будзеце мець праблемы цэласнасці дадзеных, якія з'яўляюцца вынікам якiя маюць адны і тыя ж дадзеныя, схаваных у розных кутках вашай базы дадзеных.
Некаторыя важкія прычыны не Нармалізацыя
Тым не менш, ёсць некаторыя важкія прычыны не нармалізуюць сваю базу дадзеных. Давайце паглядзім на некаторыя з іх:
- Злучэння з'яўляюцца дарагімі. Нармалізацыя базы дадзеных часта ўключае ў сябе стварэнне шмат табліц. На самай справе, вы можаце лёгка звярнуць з тым, што вы думаеце, павінен быць просты запыт, які ахоплівае пяць ці 10 табліц. Калі вы калі-небудзь спрабавалі рабіць пяць-табліцы далучыцца, вы ведаеце, што яна працуе ў прынцыпе, але яго старанна павольна на практыцы. Калі вы ствараеце вэб-дадатак, якое абапіраецца на некалькі запытаў для аб'яднання з вялікімі табліцамі, вы маглі б знайсці сябе думаць, «калі толькі гэтая база дадзеных не былі нармалізаваныя!» Калі вы чуеце гэтую думку ў галаве, гэта добры час, каб разгледзім денормализации. Калі вы можаце ўставіць ўсе дадзеныя, якія выкарыстоўваюцца гэтага запыту ў адну табліцу на самай справе не ставячы пад пагрозу сваю цэласнасць дадзеных, пайсці на гэта! Будзьце бунтаром і денормализовать вашу базу дадзеных. Вы не будзеце азірацца назад!
- Нармаваная дызайн цяжка. Калі вы працуеце са складанай базы дадзеных схемы , вы , верагодна , знайсці сябе б'ешся галавой аб стол па складанасці нармалізацыі. Як простае правіла, калі вы праводзіце цэлы дзень, спрабуючы высветліць, як перайсці да чацвёртай нармальнай форме, вы можаце прымаць нармалізацыі занадта далёка. Крок назад і спытаць сябе, калі гэта сапраўды варта працягваць.
- Хуткі і брудны павінен быць хуткім і брудным. Калі вы толькі распрацаваць прататып, проста рабіць усё працуе хутка. На самай справе. Добра. Хуткая распрацоўка прыкладанняў часам важней, чым элегантны дызайн. Толькі не забудзьцеся вярнуцца і ўважліва паглядзець на ваш дызайн, як толькі вы будзеце гатовыя выйсці за межы стадыі прототипирования. Цана, якую вы плаціце за хуткі і брудны дызайн базы дадзеных з'яўляецца тое, што вам, магчыма, прыйдзецца выкінуць і пачаць усё спачатку, калі прыйшоў час, каб пабудаваць для вытворчасці.
- Калі вы карыстаецеся базу дадзеных NoSQL, традыцыйная нармалізацыя ня пажадана. Замест гэтага спраектаваць базу дадзеных , выкарыстоўваючы БАЗЫ мадэлі , якая з'яўляецца значна больш ліберальныя. Гэта карысна, калі вы захоўвання неструктураваных дадзеных, такіх як паведамленні электроннай пошты, малюнка або відэа.
Некалькі слоў засцярогі
Нармалізацыя базы дадзеных, як правіла, з'яўляецца добрай ідэяй. Вы павінны старацца прытрымлівацца прынцыпаў нармалізацыі, калі ўяўляецца мэтазгодным зрабіць гэта. Але калі ўсе індыкатары паказваюць на нармалізацыю занадта складаным для рэалізацыі, разгледзім падыход, які атрымае працу, абараняючы пры гэтым дадзеныя.
Нарэшце - калі вы вырашылі адхіліцца ад правіл нармалізацыі, быць вельмі пільнымі аб тым, як вы забеспячэння цэласнасці базы дадзеных. Калі захоўваць залішнюю інфармацыю, ставіць трыгера і іншыя элементы кіравання на месцы, каб пераканацца, што інфармацыя застаецца паслядоўнай.