Агульныя памылкі, дапушчаныя пры праектаванні баз дадзеных

Калі вы працуеце з базай дадзеных, якая ўтрымлівае сотні запісаў або мільёны запісаў, правільнае праектаванне баз дадзеных заўсёды важна. Мала таго, што ён робіць выманне інфармацыі значна прасцей, ён будзе таксама спрасціць пашырэнне базы дадзеных у будучыні. На жаль, гэта лёгка трапіць у некалькі пастак, якія могуць зрабіць рэчы цяжка ў будучыні.

Ёсць цэлыя кнігі, напісаныя на тэму нармалізацыі базы дадзеных, але калі вы проста пазбегнуць гэтых распаўсюджаных памылак, вы будзеце на правільным шляху да добрага дызайне базы дадзеных.

База дадзеных Памылка № 1: Паўтарэнне палёў у табліцы

Асноўнае правіла для добрага дызайну базы дадзеных павінны прызнаць паўтараюцца дадзеныя і змясціць гэтыя паўтараюцца слупкі у іх уласнай табліцы. Паўтарэнне палёў у табліцы з'яўляецца агульным для тых, хто прыйшоў са свету электронных табліц, але ў той час як электронныя табліцы, як правіла, плоскі дызайнам, базы дадзеных павінны быць рэляцыйнымі. Гэта як пераход ад 2D да 3D.

На шчасце, паўтараюцца поля, як правіла, лёгка заўважыць. Проста зірніце на гэтую табліцу:

Што адбываецца, калі заказ змяшчае чатыры прадукту? Нам трэба дадаць яшчэ адно поле ў табліцы для падтрымкі больш трох прадуктаў. І калі мы стварылі кліенцкае прыкладанне вакол стала, каб дапамагчы нам ўваходныя дадзеныя, мы, магчыма, спатрэбіцца змяніць яго з новым полем прадукту. І як мы бачым, усе заказы з JellyBeans ў парадку? Мы будзем вымушаныя запытваць усе палі прадукту ў табліцы з дапамогай аператара SQL, які можа выглядаць наступным чынам: SELECT * FROM Products WHERE Product1 = «Jelly Beans» або product2 = «Бабы Жэле» або product3 = 'Бабы жэле.

Замест таго, каб мець адну табліцу, якая набівае ўсю інфармацыю разам, мы павінны мець тры табліцы, кожныя трымаюць асобную частку інфармацыі. У гэтым прыкладзе мы хочам табліцу Orders з інфармацыяй пра самага парадку, у табліцы прадуктаў з усімі нашымі прадуктамі і таблеткай ProductOrders, якая звязала прадукты ў парадак.

Звярніце ўвагу на тое, як кожная табліца мае свой уласны унікальны ідэнтыфікатар поля. Гэта першасны ключ. Мы звязваем табліцы, выкарыстоўваючы значэння першаснага ключа ў якасці вонкавага ключа ў іншай табліцы. Больш падрабязна пра першасных ключах і знешніх ключах.

База дадзеных Памылка № 2: Ўбудаванне табліцы ў табліцы

Гэта яшчэ адна распаўсюджаная памылка, але гэта не заўсёды вылучаюцца вельмі столькі, колькі паўтаральных палёў. Пры праектаванні базы дадзеных, вы хочаце, каб пераканацца, што ўсе дадзеныя ў табліцы ставіцца да сябе. Гэта як дзіцяці гульня пра плямістасць, што адрозніваецца. Калі ў вас ёсць банан, клубніцы, персік і тэлевізар, то тэлевізар, верагодна, належыць дзесьці ў іншым месцы.

У тым жа духу, калі ў вас ёсць табліца продажаў людзей, уся інфармацыя ў гэтай табліцы павінны ставіцца канкрэтна да гэтага чалавека продажаў. Любая дадатковая інфармацыя, якая не з'яўляецца унікальным для гэтага мэнэджэра па продажах можа належаць дзесьці ў вашай базе даных.

У той час як гэтая табліца можа выглядаць, як гэта ўсё звязана з індывідуальным прадаўцом, ён на самай справе мае табліцу укаранёны ў табліцы. Звярніце ўвагу на тое, якім чынам Упраўленне і OfficeNumber паўтарыць з «Austin Downtown». Што рабіць, калі офісны нумар тэлефона мяняецца? Вам будзе неабходна абнавіць увесь набор дадзеных для аднаго кавалка інфармацыі змены, якія ніколі не з'яўляецца добрай рэччу. Гэтыя палі павінны быць перамешчаныя ў іх ўласную табліцу.

Гэты тып канструкцыі таксама дае магчымасць дадаваць дадатковую інфармацыю ў табліцу офіса, не ствараючы кашмар бардака ў табліцы продажаў асобы. Уявіце сабе, колькі працы было б проста адсочваць адрас, горад, штат і паштовы індэкс, калі ўся гэтая інфармацыя была ў табліцы продажаў твар!

База дадзеных Памылка № 3: Увод двух або больш частак інфармацыі ў адным полі

Ўбудаванне службовай інфармацыі ў табліцу продажаў асобы не адзіная праблема, з гэтай базай дадзеных. Поле адрасы змяшчае тры часткі інфармацыі: адрас вуліцы, горада і дзяржавы. Кожнае поле ў базе дадзеных павінна ўтрымліваць толькі адну адзіную частка інфармацыі. Калі ў вас ёсць некалькі фрагментаў інфармацыі ў адным полі, ён можа стаць больш складанай зварот у базу, для атрымання інфармацыі.

Напрыклад, што, калі мы хочам, каб выканаць запыт на ўсіх прадаўцоў з Осціна? Нам трэба будзе шукаць у поле адрасы, які з'яўляецца не толькі неэфектыўна, але і можа вярнуць няслушную інфармацыю. У рэшце рэшт, што адбудзецца, калі хто-то жыў на вуліцы Осцін ў Портлендзе, штат Арэгон?

Вось што табліца павінна выглядаць наступным чынам:

Ёсць некалькі рэчаў, каб адзначыць тут. Па-першае, «Адрес1» і «Адрес2», здавалася б, падпадаць пад паўтаральнымі палямі памылкі.

Аднак, у гэтым выпадку яны маюць на ўвазе асобныя часткі дадзеных, якія адносяцца непасрэдна да твару продажаў, а не паўтараецца групы дадзеных, якія павінны ісці ў сваёй табліцы.

Акрамя таго, у якасці бонуса, каб пазбегнуць памылак, звярніце ўвагу, як фарматаванне нумары тэлефона было пазбаўлена з табліцы. Варта пазбягаць захоўвання фармату палёў, калі гэта наогул магчыма. У выпадку тэлефонных нумароў, ёсць некалькі спосабаў людзі пішуць нумар тэлефона: 215-555-5858 або (215) 555-5858. Гэта дазволіць зрабіць пошук для чалавека продажаў па іх нумары тэлефона ці рабіць пошук людзей продажаў у тым жа кодзе вобласці больш складанай.

База дадзеных Памылка № 4: Ці не Выкарыстанне правільнага першаснага ключа

У большасці выпадкаў, вы хочаце выкарыстоўваць аўтаматычна павялічваецца лік або якой-небудзь іншай згенераваны нумар або літарна-лічбавыя знакі для першаснага ключа. Вы павінны пазбягаць выкарыстання якой-небудзь фактычнай інфармацыі для першаснага ключа, нават калі гэта гучыць, як гэта зрабіла б добры ідэнтыфікатар.

Напрыклад, у кожнага з нас ёсць свой індывідуальны нумар сацыяльнага страхавання, таму, выкарыстоўваючы нумар сацыяльнага забеспячэння для базы дадзеных супрацоўнікаў можа гучаць як добрая ідэя. Але ў той час як рэдкія, гэта магчыма нават нумар сацыяльнага страхавання, каб змяніць, і мы ніколі не хочам, каб наш першасны ключ для змены.

І гэта праблема з выкарыстаннем актуальнай інфармацыі ў якасці ключавога значэння. Гэта можа змяніцца.

База дадзеных Памылка № 5: Не Выкарыстанне Канвенцыі Naming

Гэта не можа гучаць як вялікую справу, калі вы ўпершыню пачалі праектаваць базы дадзеных, але як толькі вы дойдзеце да кропкі напісання запытаў да базе даных для атрымання інфармацыі, якія маюць пагадненне аб імёнах дапамогуць, як вы запамінальныя імёны палёў.

Толькі ўявіце, наколькі цяжка гэты працэс калі б імёны былі захаваныя як FirstName, LastName ў адной табліцы і first_name, last_name ў іншай табліцы.

Два найбольш папулярных наймення з'яўляюцца загалоўнай першую літару кожнага слова ў поле або падзелу слоў з дапамогай падкрэслення. Вы таксама можаце ўбачыць некаторыя распрацоўшчыкі загалоўнай першую літару кожнага слова, акрамя першага слова: FirstName, LastName.

Вы таксама хочаце, каб прыняць рашэнне аб выкарыстанні асаблівых імёнаў табліц або множны лік імёнаў табліц. Гэта табліца заказу або табліца Orders? Ці з'яўляецца гэта табліца кліентаў або кліентаў табліцы? Зноў жа, вы не хочаце быць затрымаўся з табліцай замовы і табліцы Customers.

Пагадненне аб назвах Вы выбіраеце, не так важна, як працэс на самай справе выбару і прыляпіць да найменьні.

База дадзеных Памылка № 6: Няправільная індэксацыя

Індэксацыя адна з самых цяжкіх рэчаў, каб атрымаць правы, асабліва для пачаткоўцаў у распрацоўцы баз дадзеных. Усе першасныя ключы і знешнія ключы павінны быць праіндэксаваныя. Гэта тое, што звязвае табліцы разам, так што без індэкса, вы ўбачыце вельмі дрэнную прадукцыйнасць з вашай базы дадзеных.

Але тое, што занадта часта прапускае з'яўляюцца іншымі палямі. Гэта «дзе» поля. Калі вы часта збіраецеся звузіць вобласць пошуку з дапамогай поля ў сказе WHERE, вы хочаце думаць пра ўвод індэкса на гэтым полі. Тым не менш, вы не хочаце, каб празмерна індэксуе табліцу, якая можа нанесці шкоду прадукцыйнасці.

Як вырашыць? Гэта з'яўляецца часткай мастацтва праектавання баз дадзеных. Там няма жорсткіх абмежаванняў на колькі індэксаў вы павінны пакласці на стол. У першую чаргу, вы хочаце індэксаваць любое поле, якое часта выкарыстоўваецца ў сказе WHERE. Больш падрабязна аб правільнай індэксацыі базы дадзеных.