SQL: Колона с първичен ключ. Колона с изкуствен идентификатор срещу естествени колони

Това е малко религиозен дебат. Моето лично предпочитание е да имам синтетични първични ключове, а не естествени първични ключове, но има добри аргументи и от двете страни. Реално погледнато, стига да сте последователни и разумни, и двата подхода могат да работят добре.

Ако използвате естествени ключове, двата основни недостатъка са наличието на съставни ключове и променящите се стойности на първичния ключ. Ако имате съставни първични ключове, очевидно ще трябва да имате няколко колони във всяка дъщерна таблица. Това може да стане тромаво от гледна точка на модел на данни, когато има много връзки между обекти. Но също така може да причини скръб на хората, разработващи заявки - ужасно лесно е да създавате заявки, които използват N-1 от N условия за свързване и да получите почти правилния резултат. Ако имате естествени ключове, вие също така неизбежно ще се сблъскате със ситуация, в която стойността на естествения ключ се променя и след това трябва да пренесете тази промяна през много различни обекти - това е много по-сложно от промяната на уникална стойност в таблицата.

От друга страна, ако използвате синтетични ключове, вие губите място чрез добавяне на допълнителни колони, добавяне на допълнителни разходи за поддържане на допълнителен индекс и увеличавате риска да получите функционално дублирани резултати. Ужасно лесно е или да забравите да създадете уникално ограничение за бизнес ключа, или да видите, че има неуникален индекс в комбинацията и просто да приемете, че това е уникален индекс. Всъщност бях ухапан от този конкретен провал преди няколко дни - бях индексирал съставния естествен ключ (с неуникален индекс), вместо да създам уникално ограничение. Тъпа грешка, но е сравнително лесна за допускане.

От гледна точка на писане на заявки и конвенция за именуване, аз също бих предпочел синтетичните ключове, защото е хубаво да знаете, когато се присъединявате към таблици, че първичният ключ на A ще бъде A_ID, а първичният ключ на B ще бъде B_ID . Това е много по-самодокументиращо се от опитите да запомните, че първичният ключ на A е комбинацията от A_NAME и A_REVISION_NUMBER и че първичният ключ на B е B_CODE.

Има малка или никаква разлика между ключ, наложен чрез ограничение PRIMARY KEY и ключ, наложен чрез ограничение UNIQUE. Важното е да прилагате ВСИЧКИ ключове, необходими от гледна точка на целостта на данните. Обикновено това означава поне един „естествен“ ключ (ключ, изложен на потребителите/потребителите на данните и използван за идентифициране на фактите за вселената на дискурса) на таблица.

По избор може също да искате да създадете „технически“ ключове, които да поддържат функциите на приложението и базата данни, а не крайния потребител (обикновено наричани сурогатни ключове). Това обаче трябва да бъде много второстепенно съображение. В интерес на простотата (а много често и на производителността) обикновено има смисъл да създавате сурогатни ключове само там, където сте идентифицирали конкретна нужда от тях, а не преди това.

Зависи от вашите естествени колони. Ако са малки и стабилно се увеличават, тогава те са добри кандидати за първичен ключ.

• Малък - колкото по-малък е ключът, толкова повече стойности можете да получите в един ред и толкова по-бързо ще бъде сканирането на вашия индекс
• Стабилно нарастване - произвежда по-малко размествания на индекси, докато таблицата расте, подобрявайки производителността.

Предпочитам винаги да използвам изкуствен ключ.

Първо е последователен. Всеки, който работи по вашето приложение, знае, че има ключ и може да направи предположения по него. Това го прави по-лесно за разбиране и поддържане.

Виждал съм и сценарии, при които естественият ключ (известен още като низ от система за човешки ресурси, който идентифицира служител) трябва да се промени по време на живота на приложението. Ако имате изкуствен ключ, който свързва естествения идентификатор с записа на вашия служител, тогава трябва да промените този естествен идентификатор само в една таблица. Въпреки това, ако този естествен идентификатор е първичен ключ и го дублирате в редица други таблици като външен ключ, тогава имате бъркотия в ръцете си.

По мое скромно мнение, винаги е по-добре да имате изкуствена идентификация, ако разбирам правилно значението ви за това.

Някои хора биха използвали, например, значими за бизнеса уникални стойности като техен идентификатор на таблица и аз вече прочетох в MSDN и дори в официалната документация на NHibernate, че се предпочита уникална безсмислена стойност за бизнеса (изкуствен идентификатор), въпреки че искате да създадете индекс на тази стойност за бъдещи справки. Така че в деня, когато компанията промени своята номенклатура, системата ще продължи да работи безупречно.

Да, така е. Ако не друго, едно от най-важните свойства на изкуствения първичен ключ е непрозрачност, което означава, че изкуственият ключ не отразява друга информация освен себе си; ако използвате естествено съдържание на редове за ключове, ще изложите тази информация на неща като уеб интерфейси, което е просто ужасна идея по всякакъв начин.