Dlaczego tabela miałaby używać swojego klucza podstawowego jako klucza obcego dla siebie

Przeglądając bazę danych, natknąłem się na tabelę, która używała swojego klucza podstawowego jako klucza obcego dla siebie.

Widziałem, że tabela może mieć dla siebie klucz obcy, aby zbudować strukturę hierarchiczną, ale użyłaby innej kolumny do odwołania się do klucza podstawowego.

Ponieważ klucz podstawowy jest unikalny, w tej sytuacji wiersz nie byłby w stanie skierować się tylko do siebie? To wydaje się być linkiem tautologicznym, ponieważ jeśli już mam wiersz, to już go mam.

Czy jest jakiś powód, aby to zrobić?

Jestem pewien, że ograniczenie jest zapisane w ten sposób (nie tylko patrząc na diagram), ponieważ ta sama tabela i kolumna są używane dla obu połówek definicji.

Tak jak powiedziałeś. FOREIGN KEYOgraniczenie przedstawieniu tej samej tabeli jest typowo dla struktury hierarchii i byłoby użyć innej kolumny odwołać klucz podstawowy. Dobrym przykładem jest tabela pracowników:

EmployeeId    Int     Primary Key
EmployeeName  String
ManagerId     Int     Foreign key going back to the EmployeeId

Tak więc w tym przypadku klucz obcy pochodzi z tabeli z powrotem do siebie. Wszyscy menedżerowie są również pracownikami, więc tak ManagerIdnaprawdę należy EmployeeIddo kierownika.

Z drugiej strony, jeśli masz na myśli, że ktoś użył tego EmployeeIdklucza obcego do tabeli pracownika, to prawdopodobnie był to błąd . Przeprowadziłem test i jest to możliwe, ale nie przydałoby się to w rzeczywistości.

CREATE TABLE Employee (EmployeeId Int PRIMARY KEY,
                        EmployeeName varchar(50),
                        ManagerId Int);


ALTER TABLE Employee ADD CONSTRAINT fk_employee 
    FOREIGN KEY (EmployeeId) REFERENCES Employee(EmployeeId);

Właśnie znalazłem taki klucz obcy w moim własnym pliku db i musiałem go sam tworzyć. Myślę, że to się stało przez przypadek. Jeśli kliknę „Nowy klucz obcy” w menu kontekstowym tabeli z kluczem podstawowym (w Management Studio, SQL 2014 Express), to już automatycznie tworzy taki klucz obcy odnoszący się do siebie. Patrz poniżej:

Jeśli wtedy nie zdam sobie sprawy, że powinienem to zmienić, zamiast dodawać nowe, pozostanie tam. Lub, jeśli po prostu kliknę przycisk [Zamknij], co oznacza, że ​​byłoby to jak [Anuluj], klucz obcy nadal byłby tworzony po zapisaniu definicji tabeli.

Dla mnie taki klucz obcy nie ma sensu i można go usunąć.

Być może projektant chciał wyłączyć korzystanie z TRUNCATE TABLE?

TRUNCATE TABLEnie można go używać w tabeli z ograniczeniem klucza obcego do innej tabeli, chociaż można go użyć, jeśli istnieją klucze referencyjne obce. Z dokumentacji TRUNCATE TABLE (Transact-SQL) :

DELETEOświadczenie bez WHEREklauzuli ma podobny wpływ na A TRUNCATE TABLE(usuwanie wszystkich wierszy w tabeli), ale DELETEtwierdzenie pożary Usuwanie wyzwalaczy, co może być powodem, aby umożliwić DELETEale nie TRUNCATE TABLE.

Zrobiłbym to przy użyciu uprawnień ( DELETEwymaga uprawnień do usuwania, TRUNCATE TABLEwymaga uprawnień do zmiany tabeli), ale może istnieje jakiś powód, dla którego projektant nie mógł tego zrobić?

Uwaga: Chociaż to, co zrobił projektant, tak naprawdę nie wyłącza korzystania TRUNCATE TABLE, nadal spekuluję, że taki był ich zamiar.