En mindre fråga om tabellstrukturer i databasen[/Mod]

Skapar tabeller i databas som skall kunna hämtas, och kommunicera med Forms. En inloggning.


Blir det riktigt att skapa två stycken foreign keys på detta vis för att refererera till tabellerna?

Varför behöver tre tabeller?
Om du har användarna i en tabell. AnvändareID(PK), Förnamn, Efternamn, ....

Och inloggningarna i en tabell
InnloggningID(primär) - AnvändareID(FK), Tidpunkt, ....

Så räcker kanske det till att börja med?

Beklagar om jag surrar.

Första tabell består av följande attribut.

AnvändareID(PK) , Förnamn, Efternamn....

Tabell nr 2.

InloggningsID(PK), Användarnamn, Lösenord..

tabell nr 3.

ID(PK), AnvändareID, InloggningID.

Detta förändrar möjligen situationen?

Jag tänker att AnvändareID och InloggningID bör sammankopplas under ett unikt ID.

Du borde egentligen inte ha en separat tabell med lösenorden.

Gör en tabell i stället:


Sen en annan tabell för själva inloggningarna:

typ.

1.Inloggning (iid(PK) + username + password)

2.Användare (aid(PK)namn, efternamn, osv, osv)

3.ai (aid + iid)
foreign key 1 - 1
foreign key 2 - 2

Menar ni att det finns nackdelar att göra på viset ovan och jag istället bör följa era exempel?

Nej, du kan göra så, men jag ser användaren som ett objekt, och då finns det ingen anledning att dela upp i inloggning och användare.

Båda sätten funkar, däremot att ha en tabell till.. bättre att du lägger "inloggningsid" i användartabellen i så fall.

Jag har skapat lite flödesschema innan, kanske är jag ute och cyklar..

Programmet väntar på användaren fyller i fälten, username(variabel) + password(variabel). Sedan anropas krypteringsmetod till password. Därefter skapas ett objekt som innehåller (username + krypterat password) som sedan testas i databasen.

Tack för tipset! Får läsa på om detta..

Jag vet inte, men om varje användare bara skall kunna ha ett lösenord så finns det ju egentligen ingen anledning att dela upp på flera tabeller. Däremot om samma användare skall kunna ha flera lösenord så måste du ju dela upp det. (1 till * relation i UML).

Och att spara en "halv" användare pga. att vissa saker matas in först tycker jag låter dumt. Spara allt eller inget i det här fallet.

Tack för ditt råd!

Då behövs väl endast 1 foreign key?

Ja, en FK och en PK's i båda tabellerna kan vara en lösning.

Om en användare bara ska kunna ha ett lösenord så kan du med fördel spara det i en tabell tillsamman med användaren.
En användare behöver säkert vara unik och då kommer frågan om en användare ska kunna byta användarnamn men oaktat detta skulle jag göra en PK i tabellen över inloggningarna.

Användare: AnvändareID(PK), Användarnamn(Unik), Lösenord, Förnamn, Efternamn

Inloggning: InloggningID(PK), AnvändareID(FK), Tidpunkt

Om du sparar AnvändareID, alltså PK'n, i.st.f Användarnamn(Unik) här så håller du öppet för att Användarnamn kan ändras (så länge det inte ändras till det samma som något annat befintligt användarnamn) utan att du då också måste ändra på alla ev. rader i denna tabell där detta användarnamn finns.

Nu kan det vara så att din databas inte accepterar ett unikt index utöver en PK i en och samma tabell med då finns det säkert andra lösningar på det i din databas och lösningen bör ligga i databasen även om du också skapar det i din programlogik.

PK i tabell över inloggningar fyller nu alltså funktionen att om användarnamnet ändras så behöver inte alla ev. rader i inloggningstabellen ändras.

Tack för din input!

Jag har lärt mig att stycka upp i mindre tabeller, annars blir väl query väldigt långa?

Det skapar väl mer flexibilitet genom fördelning, där jag enkelt kan se vilka användare som har gjort vad. Går väl blixtsnabbt istället för SQL skall läsa 1,2, 3, 4, 5, 6, 7, 8 x 30 ? När istället kan skrivas 1, 2 x 30

Dessutom skall tabellerna referera till objekt. Har en användare login? osv.

Pedagogiskt sett anser jag att detta ger bättre överblick, och flera tabeller är väl inte till skada, tvärtom?

Grovt så representeras ofta ett objekt som en tabell och objektens attribut som kolumner och ingen ytterligare uppdelning i fler tabeller behövs utan skälig orsak. Sen är dom databaser jag känner så snabba att även mycket stora datamängder processas väldigt fort. Man bör oaktat detta alltid välja uppdelningen och nycklar med omsorg.