Obecnie projektuję strukturę bazy danych dla projektu naszego zespołu. Mam teraz na myśli to pytanie: czy jest możliwe, aby klucz obcy działał jako klucz podstawowy przy innym stole?Czy klucz obcy może działać jako klucz podstawowy?
Oto niektóre z tabelami projektowania baz danych naszego systemu:
user_accounts
students
guidance_counselors
Chciałem zdarzyć się, że tabela user_accounts
powinien zawierać identyfikatory (podobno logowania poświadczeń do systemu) i haseł zarówno użytkownicy studentów i doradcy zawodowi. W skrócie, klucze podstawowe obu tabel: students
i guidance_counselors
są również kluczami obcymi z tabeli user_accounts
. Ale nie jestem pewien, czy jest to dozwolone.
Inną kwestią jest: student_rec
tabela istnieje również, co wymaga student_number
(który jest user_id
w tabeli user_accounts
) i guidance_counsellor_id
(który jest również user_id
w user_accounts
) do każdego z jego zapisu. Jeśli oba identyfikatory ucznia i doradcy zawodowego pochodzą z user_accounts table
, jak zaprojektowałbym tabelę student_rec
? I na przyszłość, jak ręcznie napisać to jako kod SQL?
To mnie wkurzyło i nie mogę znaleźć żadnej konkretnej ani pewnej odpowiedzi na moje pytania.
Podczas gdy odpowiedź na twoje pytanie brzmi "tak, klucz podstawowy może również działać jako klucz obcy", moim zaleceniem byłoby uniknięcie tego. Ta sama relacja może być wyrażona za pomocą dyskretnych kluczy podstawowych i kluczy obcych, a przeciążenie kolumny z wieloma obowiązkami może spowodować trudności na drodze. Na przykład, jeśli klucz podstawowy jest również kolumną tożsamości lub jest automatycznie przypisywany za pomocą strategii GuidComb przez ORM, prawdopodobnie będziesz szukał dwóch lub więcej transakcji zamiast jednego. Zasada pojedynczej odpowiedzialności jest również dobra dla projektowania baz danych. –