или - създайте индекс и не приемайте, че стойностите са уникални
Тона безопасно да приемем, че стойностиса уникален, ако имате дефиниран уникален индекс. Ето как се прилагат уникалните ограничения (в момента, а вероятно и във всички бъдещи версии).
Дефиниране на UNIQUE constraint вършина практика същото (почти, вижте по-долу) като създаване на уникален индекс без указване на типа на индекса. И цитирам ръководството:
Изборите са btree, hash, gist и gin. Методът по подразбиране е btree.
Добавянето на ограничение е просто каноничният начин, който няма да се счупи в бъдещи версии, където може да бъдат приложени по различен начин. Това е всичко.
И не, уникално ограничение може да се реализира само с основноbtree индекс във всички версии до и включително PostgreSQL v14. Цитирам параграфа "ADD table_constraint_using_index" в ръководството тук:
Индексът не може да има изразни колони, нито да бъде частичен индекс. Освен това трябва да е индекс на b-дърво с подреждане на сортиране по подразбиране.
###Други разлики
- Уникалните ограничения могат да бъдат отложени . Това не е възможно за уникални индекси. Разгледайте
SET CONSTRAINTSкоманда и следвайте връзките за повече.
Външният ключ трябва да препраща към колони, които или са първичен ключ, или представляват уникално ограничение.
Последният бит изглежда е остарял или е недоразумение от самото начало. Вижте:
- NULL стойности за колони referential_constraints.unique_constraint_* в информационна схема
Свързано:
- Уникалният индекс по-добър ли е от уникалното ограничение, когато имам нужда от индекс с операторен клас
