- Какво представляват ключовете?
- Прости клавиши
- Свързани или сложни ключове
- Първични ключове
- Номериране и автоматично нарастване
- Може ли една таблица да съдържа множество първични ключа?
Докато много разработчици и администратори на бази данни могат да работят с primary keys всеки ден е увлекателна тема да се запитате:„Какво точно е primary key и може (или трябва) таблица на база данни да съдържа множество primary keys едновременно?“
По-долу ще разгледаме тези въпроси по-подробно и ще се опитаме да стигнем до разумния и общоприет консенсус в рамките на общността за разработчици.
Какво представляват ключовете?
За да разберете какво е primary key е в таблица на база данни, първо трябва да разберем малко за non-primary keys . key в таблица е просто атрибут, който се използва за идентифициране и достъп до тази информация. Една таблица може и често ще има множество ключове, като например в таблицата Users и двата email и username може да се счита за ключове.
В зависимост от разработчика или администратора, с когото говорите, може да чуете за различни типове ключове и техните дефиниции, така че ще разгледаме само няколко различни примера по-долу и основна дефиниция на всеки.
Прости клавиши
simple key е просто ключ, използващ само един единствен атрибут в таблицата. Освен ако не наложим повече ограничения върху ключа или таблицата, тогава username атрибутът в горния пример е simple key .
Свързани или сложни ключове
Направена една крачка по-далеч от simple keys са concatenated или compound ключове. Както подсказва името, concatenated key представлява обединяване на множество single keys . Например, системата може автоматично да комбинира last_name и year_of_birth single keys в concatenated key , така:smith1980 .
Първични ключове
[primary key](https://en.wikipedia.org/wiki/Unique_key) е ключ, който е избран да бъде главен (или основен ) представителен атрибут за този ред данни. primary key еуникален и след това този атрибут се използва в цялата база данни и се осъществява достъп и се предава на други таблици като представителен атрибут за въпросните данни.
На практика primary key атрибутът също е маркиран като NOT NULL в повечето бази данни, което означава, че атрибутът винаги трябва да съдържа стойност, за да може записът да бъде вмъкнат в таблицата.
Като пример, или email или username simple keys може да бъде присвоено обозначението на primary key , но обикновено е най-добрата практика да зададете primary key към атрибут, който не е (или не може) да бъде променен нито от бизнес логиката, нито дори от индивида. Например, представете си User получава нов имейл адрес, който след това причинява всички предишни primary keys асоциациите, направени с помощта на стария имейл адрес, да станат невалидни при използване на новия имейл адрес.
Поради тази причина (наред с други) повечето primary keys използвайте число или уникален низ, като [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) .
Номериране и автоматично увеличаване
Също така накратко си струва да се отбележи, че много системи за бази данни са настроени по такъв начин, че всяка таблица има primary key което е едновременно числово и също се увеличава автоматично. Това просто означава, че самата база данни автоматично присвоява на всеки нов запис в тази таблица уникален primary key стойност, която е постепенно по-голяма от всички предишни стойности. Повечето разработчици обаче са съгласни, че тази практика е остаряла и разкрива ненужни пропуски в сигурността на системата, когато се използва за някои таблици, които представляват определени данни.
Например, представете си всички User на записите се присвоява автоматично увеличен primary key стойност, позната като id атрибут. Ако злонамерено лице открие, че id атрибутът на даден потребител (напр. Джон Смит) е стойността 1500 , това вече разкрива малко информация. Първо, това показва, че вероятно има поне 1499 други потребители в системата или са били в някакъв момент. Това също така означава, че ако потребителската страница на Джон Смит може да бъде достъпна чрез URL или API извикване, което съдържа този id стойност на 1500 , тогава има голям шанс просто да промените стойността на друго число, като 1499 или 1501 , ще разкрие страницата на друг потребител, който може да не желае достъп до страницата му от този посетител. По този начин записите могат да бъдат търсени чрез просто отгатване id стойности в масов мащаб.
Това очевидно са много прости примери, но поради тези причини повечето съвременни бази данни ще използват произволен и уникален primary key стойност на атрибута, като UUID когато работите с чувствителни данни.
Може ли една таблица да съдържа множество първични ключа?
Краткият отговор ене , една таблица не може да съдържа множество primary keys , тъй като това противоречи на основните принципи на дизайна на релационна база данни (вижте:[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) и [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) ).
Това е възможно е една таблица да има множество candidate keys , които ефективно се държат подобно на primary key в това candidate key е уникален, NOT NULL , и е единично представяне на този запис в таблицата.
Въпреки това, когато става въпрос за избор на кой един атрибутът ще бъде присвоен като primary key за таблицата изборът идва от списъка с всички потенциални candidate keys (оттук и името, те са кандидати да станат primary key ). В крайна сметка само един candidate key е избран като най-добрият представителен атрибут за този запис, който да се използва в тази таблица като primary key и се препращат другаде в базата данни от други таблици чрез съответните им foreign keys .
