webForumDet fria alternativet

relationstabell

Webbutveckling

10 svar · 1 192 visningar · startad av Hallgren

Medlem sedan dec. 19991 606 inlägg
Frågan#1

Hej på er!

Sitter och gör ett matchskript och det har nu visat sig att jag behöver använda realtionstabeller för att få allt att funka men nu är det så att jag inte kan med realationstabeller och allt som kommer med det. :l Så nu behöver jag lite hjälp med att få begreppet förklarat och gärna med ett exempelt eller två. :)

BTW, jag använder mysql om det nu ändrar på något.

[r]
Borde denna tråd kanske ligga i mySQL delen?

Medlem sedan dec. 200012 464 inlägg
#2

Tja, inte i ASP i alla fall.

En relationstabell används för att beskriva en många till många relation, t.ex drinkar och ingredienser.

För att beskriva detta så har man tre tabeller,

Drinkar
--------
Dnamn, beskrivning (nyckel Dnamn)

Ingredienser
----------------
Inamn, beskrivning

mixer
-------
Dnamn,Inamn,kvantitet

Relationstabellen innehåller två kolumner Dnamn och Inamn som används för att koppla samman de olika tabellerna. Om detta används ofta beteckningen join.

Databaser kan kontrollera att tabellerna inte innehåller felaktigt data, t,ex så skall det inte gå att lagra ett inamn i tabellen mixer som inte finns i tabellen ingredienser. Detta begrepp kallas referentiell integritet och man använder även begreppet främmande nycklar (foreign keys).

Mysql har stöd för foreign keys (med några konstiga restriktioner) om du använder InnoDB. Det står en del i deras manual.

Medlem sedan dec. 19991 606 inlägg
#3

Aha, mkay nu är det lite mer klart än va det va förut ialla fall. :)

Här är den strukturen jag tänker ha på min DB, vad mer behöver jag lägga till och hur skulle den SELECT så ut i så fall?

tblClans (tbl1)
clanID, clanCountry, clanName

tblWars (tbl2)
warID, warType, scoreHome, scoreAway, warDate, warReport

tblLineup (tbl3)
linupID, player1, player2, player3, player4, player5, player6

Medlem sedan dec. 200012 464 inlägg
#4

Att ha player1, player2 etc är aldrig bra. I stället för att ha flera kolumner så lagrar du flera poster i en tabell med 3 kolumner

lineUpID, player, ordinal

Vad mer behövs? Det beror väl på vad du vill lagra ...

Medlem sedan dec. 19991 606 inlägg
#5

...

har bestämt mig för att skippa den 3e tabellen just nu. :)

mina tabeller så ut på följande sätt.

clans (tbl1)
clanID, clan, country

wars (tbl2)
warID, clanID, wardate, wartype, result_home, result_away, auther, report

har löst det med hur jag lagrar allt i dbn men nu vill jag ju skriva ut allt också men vet inte hur jag binder ihop dem i min SELECT så rätt info kommer på rätt plats. :l

Medlem sedan dec. 200012 464 inlägg
#6

t.ex. alla clans som finns i ett war av typ kilt

select clan,country 
 from clans inner join wars on
  clans.clanID = wars.clanID
 where wartype = 'kilt'
Medlem sedan dec. 19991 606 inlägg
#7

om jag nu vill loopa ut allt och inte bara wartype 'kilt"?

Medlem sedan dec. 200012 464 inlägg
#8

Ännu enklare, alla clans som finns i något war

select clan,country 
 from clans inner join wars on
  clans.clanID = wars.clanID
Medlem sedan dec. 19991 606 inlägg
#9

Mm, något e fel. :l när jag försöker komma åt info från wars så får jag:

ADO Could not find the object in the collection corresponding to the name or ordinal reference requested by the collection

måste jag inte ange fälten från wars i min select?

Medlem sedan dec. 200012 464 inlägg
#10

Jo, då får du ange dessa i select-listan

select clan,country,wartype,wardate
 from clans inner join wars on
  clans.clanID = wars.clanID

t.ex. I detta exempel är alla kolumnnamn entydiga. Du kan alltid kvalificera kolumnnamn med tabellnamn

select clans.clan,clans.country,wars.wartype,wars.wardate
 from clans inner join wars on
  clans.clanID = wars.clanID

I ADO kan du inte använda det kvalificerade namnet.

Medlem sedan dec. 19991 606 inlägg
#11

wohooo! :) funkar prima! Nästan så att man skulle ta och bjuda dig på en jordgubbe eller två. ;) tack!

389 ms totalt · 4 externa anrop · v20260731065814-full.6fe65c25
123 ms — deklarationer (db)
0 ms — hämta statistik (cache)
257 ms — hämta tråd, inlägg och bilagor (db)
129 ms — ändringar (db)