Is het goed om een externe sleutel als primaire sleutel te hebben?

Ik heb twee tabellen:

• Gebruiker (gebruikersnaam, wachtwoord)
• Profiel (profileId, geslacht, geboortedatum, …)

Momenteel gebruik ik deze aanpak: elk profielrecord heeft een veld met de naam “userId” als buitenlandse sleuteldie linkt naar de tabel Gebruikers. Wanneer een gebruiker zich registreert, wordt zijn profielrecord automatisch aangemaakt.

Ik ben in de war met de suggestie van mijn vriend: om het veld “userId” als de buitenlandseen primairesleutel te gebruiken en het veld “profileId” te verwijderen. Welke aanpak is beter?

Antwoord 1, autoriteit 100%

Buitenlandse sleutels zijn bijna altijd ‘Duplicaten toestaan’, waardoor ze ongeschikt zouden zijn als primaire sleutels.

Zoek in plaats daarvan een veld dat elk record in de tabel op unieke wijze identificeert, of voeg een nieuw veld toe (een automatisch ophogend geheel getal of een GUID) om als primaire sleutel te fungeren.

De enige uitzondering hierop zijn tabellen met een een-op-eenrelatie, waarbij de vreemdesleutel en primairesleutel van de gekoppelde tabel één en dezelfde zijn.

Antwoord 2, autoriteit 32%

Primaire sleutels moeten altijd uniek zijn, externe sleutels moeten niet-unieke waarden toestaan als de tabel een een-op-veel-relatie is. Het is prima om een externe sleutel als primaire sleutel te gebruiken als de tabel is verbonden door een één-op-één-relatie, niet een één-op-veel-relatie. Als u wilt dat hetzelfde gebruikersrecord de mogelijkheid heeft om meer dan 1 gerelateerde profielrecord te hebben, gebruik dan een aparte primaire sleutel, anders houdt u het bij wat u heeft.

Antwoord 3, autoriteit 10%

Ja, het is legaal om een primaire sleutel als refererende sleutel te hebben. Dit is een zeldzame constructie, maar het is van toepassing op:

• een 1:1-relatie. De twee tabellen kunnen niet in één worden samengevoegd vanwege verschillende machtigingen en privileges die alleen van toepassing zijn op tabelniveau (vanaf 2017 zou zo’n database vreemd zijn).

• een 1:0..1 relatie. Het profiel kan wel of niet bestaan, afhankelijk van het gebruikerstype.

• prestaties zijn een probleem en het ontwerp fungeert als een partitie: de profieltabel wordt zelden geopend, gehost op een afzonderlijke schijf of heeft een ander shardingbeleid in vergelijking met de gebruikerstabel. Het zou niet logisch zijn als de onderstreepte opslag zuilvormig is.

Antwoord 4, autoriteit 4%

Ja, een externe sleutel kan een primaire sleutel zijn in het geval van een één-op-één relatie tussen die tabellen

Antwoord 5, autoriteit 2%

Het wordt over het algemeen als een slechte gewoonte beschouwd om een één-op-één relatie te hebben. Dit komt omdat u de gegevens gewoon in één tabel kunt weergeven en hetzelfde resultaat kunt bereiken.

Er zijn echter gevallen waarin u deze wijzigingen mogelijk niet kunt aanbrengen in de tabel waarnaar u verwijst. In dit geval is het geen probleem om de Foreign key als primaire sleutel te gebruiken. Het kan helpen om een samengestelde sleutel te hebben die bestaat uit een automatisch oplopende unieke primaire sleutel en de externe sleutel.

Ik werk momenteel aan een systeem waarbij gebruikers kunnen inloggen en een registratiecode kunnen genereren voor gebruik met een app. Om redenen waar ik niet op in zal gaan, kan ik de vereiste kolommen niet eenvoudig aan de gebruikerstabel toevoegen. Dus ik ga een één-op-één route af met de codetabel.

Antwoord 6

Dat zou ik niet doen. Ik zou de profileIDals primaire sleutel van de tabel Profile

houden

Een externe sleutel is slechts een verwijzingsbeperking tussen twee tabellen

Je zou kunnen stellen dat een primaire sleutel nodig is als doelwit van alle externe sleutels die ernaar verwijzen vanuit andere tabellen. Een externe sleutel is een set van een of meer kolommen in een tabel (niet noodzakelijkerwijs een kandidaatsleutel, laat staan de primaire sleutel, van die tabel) die de waarde(n) kan bevatten die in de primaire sleutelkolom(men) van sommige andere tafel. We moeten dus een primaire sleutel hebben die overeenkomt met de externe sleutel.
Of moeten we? Het enige doel van de primaire sleutel in het primaire sleutel/buitenlandse sleutelpaar is om een ondubbelzinnige join te bieden – om de referentiële integriteit te behouden met betrekking tot de “buitenlandse” tabel die de primaire sleutel bevat waarnaar wordt verwezen. Dit zorgt ervoor dat de waarde waarnaar de refererende sleutel verwijst altijd geldig is (of null, indien toegestaan).

http://www.aisintl.com/case/primary_and_foreign_key.html

Antwoord 7

Het hangt af van het bedrijf en het systeem.

Als uw userId uniek is en altijd uniek zal zijn, kunt u userId als uw primaire sleutel gebruiken. Maar als je ooit je systeem wilt uitbreiden, wordt het lastig. Ik raad je aan om een externe sleutel toe te voegen in tabelgebruiker om een relatie te maken met het tabelprofiel in plaats van een externe sleutel toe te voegen in het tabelprofiel.

Antwoord 8

Kort antwoord: HANGT AF…. In dit specifieke geval kan het goed zijn. Deskundigen zullen het echter bijna elke keer afraden; inclusief uw zaak.

Waarom?

Sleutels zijn zelden uniek in tabellen als ze vreemd zijn (afkomstig uit een andere tabel) voor de betreffende tabel. Een item-ID kan bijvoorbeeld uniek zijn in een ITEMS-tabel, maar niet in een ORDERS-tabel, omdat hetzelfde type item hoogstwaarschijnlijk in een andere volgorde zal bestaan. Op dezelfde manier kunnen order-ID’s (misschien) uniek zijn in de ORDERS-tabel, maar niet in een andere tabel zoals ORDER_DETAILS waar een order met meerdere regelitems kan bestaan en om een zoekopdracht op een bepaald item in een bepaalde volgorde uit te voeren, hebt u de aaneenschakeling van twee nodig FK (order_id en item_id) als de PK voor deze tabel.

Ik ben geen DB-expert, maar als je logisch kunt rechtvaardigen dat je een automatisch gegenereerde waarde als je PK hebt, zou ik dat doen. Als dit niet praktisch is, kan een aaneenschakeling van twee (of misschien meer) FK als uw PK dienen. MAAR, ik kan geen enkel geval bedenken waarin een enkele FK-waarde kan worden gerechtvaardigd als de PK.

Antwoord 9

Het is niet helemaal van toepassing op het geval van de vraag, maar aangezien ik op deze vraag belandde op zoek naar andere informatie en door enkele opmerkingen te lezen, kan ik zeggen dat het mogelijk is om alleen een FK in een tabel te hebben en unieke waarden te krijgen.
U kunt een kolom gebruiken die klassen heeft, die slechts 1 keer kunnen worden toegewezen, het werkt bijna als en ID, maar het kan worden gedaan in het geval dat u een unieke categorische waarde wilt gebruiken die elk record onderscheidt.