Register över spelare och föräldrar

Hej,
jag är kagförälder för ett gäng basektspelare. Nu har j ag "tagit på mig" att göra ett register.
- varje spelare har ett unikt nummer (dvs tröjnummret)
- varje spelare har 1 eller 2 föräldrar
- varje förälder har a) namn
b) mobil
c) e-post
- varje spelare har 1) tröjnummer
2) namn
3) e-post
4) adress
5) mobiltelefon
6) hemtelefon

Mina frågor:
i vilket program bör jag göra detta register?
lite tips innan jag kommer igång?

Tack på förhand
//Peter
www.laget.se/spifp93

Papper och penna funkar utmärkt. Lite grundläggande regler. Ett fält innehåller ett och endast ett värde. Alltså funkar inte kolumnen "adress" utan du ska ha adress, postnummer, stad för att det ska bli bra. Knyt ihop föräldrarna med spelaren genom primary key i spelar-tabellen som kommer vara deras tröjnummer.

Föräldrar = {#id, tröjnummer, namn, mobil, e-post}
Spelare = {#tröjnummer, namn, e-post, adress, postnummer, stad, mobiltelefon, hemtelefon}

(# = primärnyckel, dvs det som gör att varje rad är 100% unik)

Reserverat för fel så detta gjordes på fri hand. Egentligen ska det modelleras och normaliseras men det ska nog funka bra.

Tack för ditt snabba svar:-)
Några frågor:
1)Jag skall alltså ha 2 tabeller, 1 spelare och 1 förälder?
2) behövs det verkligen både id och tröjnummer i föräldertabellen?
3) blir inte det strul om en spelare har 2 föräldrar?

1)Ja du måste ha två tabeller. Hur ska du annars lagra informationen om förälder 1 och 2? Sen vet du inte ifall ungen har 1 eller 2 så bäst är bara att ha en extra tabell där du knyter ihop föräldern med ungen och inte tvärt om.

2)Nej det behövs inte. Chansen att en unge har två föräldrar med samma information är 0 så det behövs inte.

3)Det blir inte strul med eller utan id då den är unik. I föräldertabellen knyter du ihop föräldern med ungen m.h.a. tröjnumret.

Ett fall som verkar ha glömts bort är att en förälder kan ha flera ungar i laget.

Visst fan får ha 3 tabeller där mitttabellen parar ihop unge med förälder.

Nej, det behövs inte. Det räcker med en kolumn i förälder tabellen, typ unge_id. och sedan en rad för varje förälder.


Edit: fan, hade fel. Givetvis en relationstabell om varje förälder kan ha flera ungar i laget

Tabell Unge:
#Tröjnummer, Namn, E-post, Adress, Mobil, Hemtelefon, Förälder1ID, Förälder2ID

Tabell Förälder:
#ID, Namn, Mobil, Hemtelefon Adress, E-post,


ID för föräldrarna är unikt, och sen så har Ungarna tröjnummer som är unikt, och med hjälp av Förälder1ID och Förälder2ID så vet man vilket/vilka päron man ska leta upp information om till ungen. Går också att sätta samma päron på fler ungar eftersom det spelar ingen roll ifall Förälder1ID/2ID är samma på flera rader i tabellen Unge.

Bästa lösningen enligt mig åtminstonde.

kan man tänka sig: att spelare med tröja #4 har förälder1ID=14 och förälder2ID=24?
eb fråga till: kan man göra en "stand alone" av en access databas? dvs utan att användaren måste ha access installerat?

//Peter

Personligen skulle jag inte låta tröjnummer vara primary key för ungarna. Spelare slutar medan nya börjar, tröjnummer ärvs. Visst kan man deletea gamla spelare och föräldrar, men det känns dels som att någon relation kan komma att spricka förr eller senare, och dels synd att förlora historik över vilka som spelade i laget den där våren -75 (you get the point)...

En spelare behöver alltså enligt mig dels ett unikt id som primary key, och dels en kolumn för tröjnummer.

Om man skulle gå vidare lite till så kan man tänka sig att minska redundansen genom att införa ytterligare tabeller:

Barn: *Barn_ID, Tröjnummer, +P_ID
Förälder: *Förälder_ID, +P_ID
Person: *P_ID, Namn, E-post, Mobil
Person_Hushåll: +H_ID, +P_ID
Hushåll: *H_ID, Gata, Postnummer, Postort, Hemtelefon

Detta ger att ett Hushåll kan ha en eller flera Personer som kan vara antingen Barn eller Föräldrar, med fördelen att adress- och hemtelefonnummer inte lagras redundant. Relationstabellen Person_Hushåll är till för att tillgodose de fall där en person tillhör flera hushåll, exempelvis barn med skilda föräldrar.

Generellt sett så kan man komma undan att använda unika id som primärnycklar, men i praktiken är det i stort sett alltid en bra idé att ge varje tabell en unik id-kolumn

Frågan är om det är värt det, med tanke på att användargränssnittet blir så mycket krångligare.