Om de bara kan vara ensama eller par är det mycket effektivare att ha två fält i tabellen med könID som sedan kopplar mot en könTabell. Så är det bara att köra en select för varje användare.
Frågan#1
Databas design fråga.
6 svar · 305 visningar · startad av Nson
Jag tycker du verkar ha komplicerat allting. Varför ha en tabell för kön? Det räcker ju med att ha en kolumn i användartabellen, där det kan vara tex 1 eller 2, beroende på kön. Det lär ju inte ske några biologiska revolutioner som ställer könsdefinitioner på ända.
För att lösa par-frågan, skulle du kunna ha en till tabell över inloggningsid. Den kan du referera till från användartabellen. Då klarar du även polygama förhållanden. ;)
Jag tänker mig något i den här stilen:
Användare
--------------
id userID(FK till user) kön(1 eller 2) samt annan data du vill ha
User (som man loggar in som, eller medlemsnummer eller vad det nu är)
---------------
userID(refererad till från användartabell)
UlfT, tanken är att jag vill splitta upp databaserna så mycket det går. Då jag har fått den informationen att detta är det bästa sättet att bygga databaser.
Det låter inte så bra att übernormalisera där det inte behövs.
Ska du ha kön i en egen tabell är det ju lika bra att du bryter ut alla fält, och bara har ett användarid. Det är ju flera som heter Peter, så förnamnen kan man ha i en egen tabell?
Normalisering är bra, men onödigt om det inte behövs.
Varför inte skapa en tabell PARTNER som innehåller kolumnerna
ID
KÖN
NAMN
PARTNERID
Du kan ju sedan ställa sqlfrågan
select namn from partner a, partner b where a.idnr = b.partnerid and b.partnerid > ' '
Splitta info mellan tabeller skapar onödiga svarstider !!!