Обяснява какво е първичен ключ и защо той е неразделна част от релационни бази данни.
Когато създадохме нашите две таблици, създадохме и първичен ключ за всяка таблица.
Когато разширите възлите в левия СХЕМИ раздел, можете да видите първичните ключове (и външни ключове - ще стигнем до тях по-нататък), изброени под всяка таблица:
Както показва придружаващата екранна снимка, Индексите възлите съдържат всякакви индекси (в нашия случай външни ключове и/или първични ключове). Тези първични и външни ключове са там само защото сме ги посочили в нашия код, когато създавахме таблиците.
По-конкретно, използвахме PRIMARY KEY (FruitId) за да направите
FruitId
колона първичния ключ за
Fruit
таблица и използвахме PRIMARY KEY (UnitId) за да направите
UnitId
колона първичния ключ за
Единиците
таблица.
Какво е първичен ключ?
първичен ключ (наричан още уникален ключ ) е колона, която е разпределена като поле за уникален идентификатор. Стойността в колоната с първичен ключ е уникална за всеки запис. С други думи, няма два записа да споделят една и съща стойност в тази колона.
Класически пример за поле за първичен ключ е полето "ID". Повечето таблици ще имат поле за ID, което предоставя уникален идентификатор за всеки запис. Примерите могат да включват "CustomerId", "ProductId", "FruitId" и т.н. Без полета за ID като тези функцията на вашата база данни би била сериозно затруднена. Ако имате двама или повече клиенти с едно и също име, как бихте могли да намерите техния запис? Въпреки че е вярно, че бихте могли да намерите нещо уникално за всеки запис, е много по-чисто и по-лесно да имате колона, чиято основна цел е да предостави уникална идентификация за всеки запис.
Основната може да бъде или нормална стойност, която е гарантирано уникална ( ISBN номер за книги, продуктов код и т.н.), или може да бъде стойност, генерирана от приложението или СУБД специално, за да бъде уникална (като глобално уникален идентификатор или автоматично увеличаващо се цяло число).
Избор на първичен ключ
Бъдете внимателни, когато избирате колона за вашия първичен ключ. Трябва да се уверите, че всеки запис ще има една и че няма възможност два записа да споделят една и съща стойност или че един запис ще има повече от една стойност.
Например, използването на имейл адреса на потребителя може да работи в някои случаи, но не е много солидна основа за уникален идентификатор. Потребителите могат да променят своя имейл адрес. Потребителите могат да споделят имейл адреси. Някои потребители може да нямат имейл адрес. Разбира се, можете да напишете вашата система, за да предотвратите потребителите да променят имейл адреса си или да го споделят, но вашата система няма да бъде много гъвкава или удобна за потребителя.
Можете да изисквате всички потребители да имат уникално потребителско име. Това може да работи. Трябва обаче да помислите внимателно за всички възможности. Ако има някакъв шанс потребителите да го променят или споделят (минало, настояще или бъдеще), не го използвайте като първичен ключ. Ами ако "TechGuy12" деактивира акаунта си. Това означава ли, че друг потребител вече може да използва "TechGuy12"? Това ще бъде ли проблем за вашето приложение или отчети, които трябва да генерирате?
Ако имате някакви съмнения относно „уникалността“ на полето за първичен ключ, използвайте автоматично генерирано число, което се увеличава с всеки създаден запис.
