Hallå

Det var verkligen länge sedan jag höll på med databasstruktur. Visst har man använt en eller kanske två tabeller till enklare projekt men nu känner jag att jag behöver lite råd på hur jag bäst fixar detta fö rjust nu står det still i mitt huvud!

Jag har en sidan som har några användare. Temat är golf och man kan se och följa användarna hur de går för dem, om de sänker sig byter klubb etc. (finns att se på www.theduffers.se).

Idagsläget finns det en medlems tabell med nödvändig information samt en tabell som håller inlogg. Dessa har givetvis en relation som är knutet på person id. Inget konstigt.

Men nu vill jag erbjuda användarna möjligheten att kunna flagga upp om en spelinbjudan, dvs de skall kunna skiva en inbjudan till spel ett bestämt datum. De andra användarna skall sedan kunna anmäla sig om de tycker att det passar och det är detta jag inte riktigt vet hur jag skall lösa!?

Jag måste varje fall ha en tabell som håller informationen om inbjudan ex:

PlayRequest (PlayId, Course, Holes, PersonId?)

Denna tabell måste, gissar jag, ha en relation med medlemstabellen (därav mitt frågetecken på PesonId)

Sedan måste ju användarna kunna tacka ja till inbjudan, detta är ytterli tabell?? Denna som har relation med både med medlemstabellen för att knÿta användaren men även PlayReq för att knyta mot vilen inbjudan han tackar ja till??

Som sagt jag är lite lost och jag hoppas att ni är med på vad jag är ute efter.

Mvh,
Thomas

En klassisk bokning är inte så svår om du tänker efter. Ta några post-it lappar och skriv följande på dessa:

Det finns en "spelare", en "bana", en "tid" till att börja med.

En eller flera spelare kan spela på en eller flera banor vid ett eller flera tillfällen, rätt ?

Eventuellt finns lite mer fakta. Det kan vara antal hål, 9, 18 eller 27 ? Då är det en sk. styrtabell

Det kan också vara så att du vill ha detaljer om en bana eller att du vill kunna kolla vilka tider som finns tillgängliga på en bana för att inte "dubbelboka" - då blir det lite mer komplext. Dock i sin enklaste form är det dock dessa 3 objekt.

player
playerid int (auto incr, primary key)
firstname varchar(50)
lastname varchar(50)
handicap int

track
trackid int (autoincr, primary key)
trackname varchar(50)
holes int
opentime datetime (när banan öppnar, stänger)
closetime datetime

booking
bookingid int (auto incr, primary)
player1 int
player2 int
player3 int
player4 int
trackid int
starttime datetime

Det går också att göra om booking så det blir en rad per bokad person. Eftersom det inte är 4 som spelar jämt så kanske detta blir bättre- då får du i stället söka på spelstarttid och track för att få reda på den eller de som spelar vid ett visst tillfälle.

booking
bookingid int (auto incr, primary)
starttime datetime
playerid int
trackid int


Hjälpte detta något eller blev det snurrigt?
//Pelle

Tack för snabbt svar Pelle!

Ser ut som bra information, verkligen!!

Ska läsa igenom det i lugn å ro och se om jag kan få till det. Men det ser ut som om det skulle kunna vara aktuellt med den sistnämnda booking då det precis som du sääger inte alltid är 4 som spelar utan jag är mer nyfiken på om det finns spelare som är sugen på att spela ett visst datum.

Tack så länge!

Mvh,
Thomas

Som jag förstod det var det mer en "förslag på en runda", snarare än en faktisk bokning?

Hur som helst skulle jag inte göra som Pelle föreslår, det känns som fel nivå på normalisering, din ursprungliga känns mer rätt.

Jag skulle istället ha

player
player_id (alt. personnummer alt. golfid)
...

track
track_id
...

play_event
suggested_by (playerid)
track
time
[play_event_id]


player_acceptance
play_event_id
player_id
(play_event_id, player_id) PK

Utöver detta finns det lite constraints man skulle vilja lägga in, antingen i koden eller i databasen.

I play_event finns det två alternativ, antingen gör man (suggested_by, track, time) till PK, eller så gör man tripletten unique och lägger in play_event_id.

Om man väljer det första alternativet så får man istället sista tabellen som
player_acceptance
suggested_by
track
time
player_id
(suggested_by, track, time) FK
(suggested_by, track, time, player_id) PK

istället. Detta är "fullt" normaliserat, till skillnad mot vad många tror. Problemet är att det dels är många kolumner och därför krångligare, dels tar mycket plats. Nyttan är att du kan slänga på ett constraint på player_acceptance som säger att en viss person inte kan bokas på samma tider, etc.

Hej Niklas och tack för ditt svar.

Precis som du säger så skall det inte vara ett bokningssytsem utan "bara" en fråga om spel ett visst datum där andra medlemar kan tacka ja/ansluta sig.

Skall titta på ditt förlslag.

Tusen tack!

Mvh,
Thomas

Då har jag laborerat lite med mina tabbeler och det verkar kankse inte så krångligt som jag först trodde. Givetvis beror detta mycket på att både Pelle och Nick´las rade upp lite tankegångar på hur de skulle ha löst detta! Nu var jag något slarvig i början då jag borde ha förklarat mig bättre då det inte handlade om någon bokning utan helt enkelt om en förfrågan till andra medlemmar tillika spelare som kunde nappa på en eller flera förfrågningar.

Nu blir min lösning något mellan ting och det ser ut att det kommer att fungera även om jag inte har kodat färdigt fullt ut. Men som sagt på pappret ser det ut som om det kommer att funka...annars så skriver jag igen...=)

Tack för era tankar!!

Får passa på att önska er en trevlig Nationaldag i morgon!!

Med vänliga hälsningar,
Thomas K

Tack själv!