Database for påmelding til aktiviteter

[TMB]

Hvis det er ønskelig å la folk melde seg på ikkeeksisterende aktiviteter som "romreiser" eller "fottbal" så værsågod, blir så fint så.

Hvis man lager en dropdown-meny (eller radio buttons) så er det ikke så lett for folk å melde seg på romreiser eller fottbal

[TheNarsissist]

Så du mener at email vil være best? Nr funker dårlig som du sier og mange kan hete kjell inge.

 

Da bør jeg ha en tabell "person" med all infoen som skal være der. Mail som pk.

 

En tabell "Påmelding med mail og aktivitet og en tabell med aktiviteter

?

[quantum]

Så du mener at email vil være best? Nr funker dårlig som du sier og mange kan hete kjell inge.

 

Da bør jeg ha en tabell "person" med all infoen som skal være der. Mail som pk.

 

En tabell "Påmelding med mail og aktivitet og en tabell med aktiviteter

?

Jeg syns det er greiest med teknisk nøkkel (altså et "meningsløst tall", som f.eks. databasen kan finne på selv når du setter inn en rad (autoincrement heter det vel i mysql)). Men hvis du vil ha naturlige nøkler kan du bruke email for Person-tabellen og Aktivitetsnavn for aktivitetstabellen. Email er ikke perfekt, men bedre enn telefonnummer.

 

Påmelding-tabellen vet jeg ikke hvor kommer fra, at en Person er påmeldt en Aktivitet uttrykkes ved at det er en rad i tilknytningstabellen, hvis du ikke velger en helt annen måte å gjøre det på da. Der (i tilknytningstabellen) kan du også legge annen informasjon som vedrører den bestemte påmeldingen, som f.eks. et felt som sier om påmeldingsavgift er betalt etc., dersom du har behov for det.

[quantum]

Hvis man lager en dropdown-meny (eller radio buttons) så er det ikke så lett for folk å melde seg på romreiser eller fottbal

Ja vi er jo hjertens enige om at selv de utroligste ting kan funke. Hvorfor du på død og liv ikke vil ha et normalisert databasekjema som gir deg mulighet til å utnytte all funksjonaliteten i en relasjonsdatabase får vi bare undre oss over ...

[TheNarsissist]

 

Jeg syns det er greiest med teknisk nøkkel (altså et "meningsløst tall", som f.eks. databasen kan finne på selv når du setter inn en rad (autoincrement heter det vel i mysql)). Men hvis du vil ha naturlige nøkler kan du bruke email for Person-tabellen og Aktivitetsnavn for aktivitetstabellen. Email er ikke perfekt, men bedre enn telefonnummer.

 

Påmelding-tabellen vet jeg ikke hvor kommer fra, at en Person er påmeldt en Aktivitet uttrykkes ved at det er en rad i tilknytningstabellen, hvis du ikke velger en helt annen måte å gjøre det på da. Der (i tilknytningstabellen) kan du også legge annen informasjon som vedrører den bestemte påmeldingen, som f.eks. et felt som sier om påmeldingsavgift er betalt etc., dersom du har behov for det.

 

Takk for rask svar, jeg vet faktisk ikke hva en teknisk nøkkel er og vil bare gjøre det så enkelt som mulig siden det er mitt førsre skikkelige prosjekt.

Det holder altså med person og aktiviteter?

 

Skal prøve meg litt når jeg kommer hjem fra jobb. Har et helvete med workbench nå så tror jeg skal teste myphpadmin funksjonen i wamp

[quantum]

jeg vet faktisk ikke hva en teknisk nøkkel er

 

Det holder altså med person og aktiviteter?

 

 

Teknisk nøkkel er en form for primærnøkkel som ikke "betyr noe", f.eks. et unikt løpenummer som databasen selv kan øke med +1 hver gang du setter inn en rad. Fordelen er at alle tabellene da får en pk av samme type og du slipper å vri hodet for å finne en halvbra primærnøkkel, slik som vi har gjort nå.

 

En naturlig nøkkel, er en primærnøkkel som "har betydning ute i virkeligheten" som f.eks. personnummer, email eller telefonnummer. Ulempen er at du kan ende opp med pk av ulike typer i ulike tabeller, og du må oftere ty til sammensatte primærnøkler. Vi kunne f.eks. brukt tlf+navn, det hadde delvis løst problemet med påmelding fra personer i samme husstand som oppgir fasttelefon, men så er det jo slik at i noen familier går navn i arv, far og sønn heter det samme, og da er vi like langt, og må hive inn alder også i pk.

 

Det ene er ikke riktigere enn det andre, noen vil argumentere sterkt for naturlige nøkler. Det som er superviktig er at hver tabell har en definert primærnøkkel.

 

Person og Aktivitet m. en knyttetabell i tillegg holder til det du har beskrevet nå, men jeg skal vedde på du kommer på flere ting du vil ha med og da blir det flere tabeller også.

Endret 3. mai 2013 av quantum

[jag007]

Støtter absolutt forslag om å bruke "syntetiske" primærnøkler.

Dersom du bruker epost eller telefonnummer, så vil du få trøbbel med personer som endrer epost/telefon.

[quantum]

Støtter absolutt forslag om å bruke "syntetiske" primærnøkler.

Dersom du bruker epost eller telefonnummer, så vil du få trøbbel med personer som endrer epost/telefon.

Tja, noe løser seg vel med ON UPDATE CASCADE, men jeg er i bunn og grunn helt enig med både meg selv og deg

[TheNarsissist]

Hva er en knytte tabell?

[TheNarsissist]

Hvordan ser dette ut?

 

 

 

 

Endret 3. mai 2013 av TheNarsissist

[quantum]

Hva er en knytte tabell?

 

http://www.diskusjon...post&p=20495632

 

Når du skal ha en mange-til-mange-relasjon må du opprette en tabell "imellom" de to tabellene som skal stå i et mange-til-mange-forhold til hverandre.

Endret 4. mai 2013 av quantum

[quantum]

Hvordan ser dette ut?

 

 

Aktivitet ser ikke bra ut, du skal ikke ha en kolonne pr. aktivitet, da må jo tabellen forandres og programmene som leser den omskrives hver gang du legger til en ny aktivitet. Også merkelig at noen aktiviteter er int og andre varchar?

 

Hvorfor har du feltet aktiviet i tabellen Person? Telefon kan alternativt lagres som tekst, da får du med mellomrom, bindestreker osv.

 

Har du definert fremmednøkler riktig? Nesten bedre om du poster SQL/DDL for tabelldefinisjonene.

 

Hovedpointet med fremmednøkler er at databasen vil sørge for at det aldri står en person_id eller aktivitet_id i PersonDeltarPåAktivitet som ikke også fins i hhv. Person- eller Aktivitet-tabellene.

Endret 4. mai 2013 av quantum

[TheNarsissist]

 

 

http://www.diskusjon...post&p=20495632

 

Når du skal ha en mange-til-mange-relasjon må du opprette en tabell "imellom" de to tabellene som skal stå i et mange-til-mange-forhold til hverandre.

 

Se der ja, da er det litt klarere. Men på person_id og aktivitets_id blir det da sånn at folk må fylle inn et eget nummer, eller skjer det automatisk? Og at vi har aktivitet VARCHAR, vil det føre til at folk må skrive inn hvilken aktivitet de vil delta på som igjen vil føre til at folk kan finne på fiktive aktiviteter for å kødde? Hadde forresten alt for mye tull med Wamp så tok faktisk og bare lastet opp siden med FTP til hostgator, så siden er faktisk live, utrolig hvor lett det skulle være.

[quantum]

Men på person_id og aktivitets_id blir det da sånn at folk må fylle inn et eget nummer, eller skjer det automatisk? Og at vi har aktivitet VARCHAR, vil det føre til at folk må skrive inn hvilken aktivitet de vil delta på som igjen vil føre til at folk kan finne på fiktive aktiviteter for å kødde?

 

Ingen ting skjer av seg selv (annet enn at databasen kan forhindre deg fra å skyte deg i foten hvis den er designet riktig), du må ha en webapplikasjon oppå databasen som presenterer valgmulighetene for brukeren og lagrer de valgene brukeren tar. Når en bruker melder seg på en aktivitet må applikasjonen din legge inn en rad i PersonDeltarPåAktivitet.

 

Aktivitet VARCHAR ... hvor kom det fra? Et viktig point som flere har forklart her er at folk ikke skal skrive inn aktivitetsnavnet selv (hvis det er viktig for deg at ikke folk skriver inn en masse kødd, da.), men det har med webgrensesnittet og ikke databasen å gjøre. Aktivitetene presenteres som dropdown, radiobuttons el. checkbox. For databasen sin del er en påmelding kun to tall som skal inn i knyttetabellen.

 

Fint at ting er litt klarere, men jeg tror du må klø deg ennå litt mer i hodet før alt sitter som det skal :o)

[TheNarsissist]

Haha, mente aktivitetsnavn VARCHAR. Ok, det er vel det jeg må lage i dreamweaver. Skal prøve etter jobb, kommer sikkert et par spørsmål da.

[quantum]

Det er jo et åpent spørsmål hvordan aktivitetene kommer inn i Aktivitet-tabellen. Kanskje det er du som skal legge dem inn på forhånd, kanskje noen brukere er tilbydere av aktiviteter og skal få legge inn aktivieter selv, mens andre er deltagere og da får legge seg inn i Person-tabellen selv.

Endret 4. mai 2013 av quantum

[TheNarsissist]

Regner med at det er noe sånt jeg må gjøre? http://m.youtube.com/#/watch?v=1lEjcdmnngc&desktop_uri=%2Fwatch%3Fv%3D1lEjcdmnngc

[quantum]

Tja, hva skal vi svare på det? Det vil sikkert funke hvis du gjør det riktig? Er redd jeg ikke kan hjelpe deg med Dreamweaver, men det er det kanskje andre som kan? Prøv evt. i gruppa for webprogrammering.

 

Antar at Dreamweaver i bunn og grunn bare spytter ut noe halvdårlig php-kode, anbefaler deg heller å lære deg å kode php selv (eller aller helst noe litt mer oppegående enn php). Det tar litt tid å komme opp å stå, men du vil nok ganske snart møte veggen med Dreamweaver. DW var sist jeg brukte det (leeenge siden) bra på wysiwyg-design, men generert kode basert på databaseskjema er per. def. temmelig begrensa, nedover i stacken må vi inn og kode sjøl.

[TheNarsissist]

Hvordan ser dette ut så langt? Får sørren ikke til å sette inn primær fremmed nøkkel

 

 

 

Endret 4. mai 2013 av TheNarsissist

[quantum]

Når du "prøver å sette inn en primær fremmed nøkkel", hva gjør du da, og hvorfor går det ikke? Får du noen feilmeldinger?

 

Du poster noen skjermbilder, det eneste som står der er noen select-setninger som ikke kan ha noen sammenheng med problemet ditt.

 

Kanskje du finner noe her: http://www.w3schools.com/sql/sql_foreignkey.asp eller google "create foreign key constraint".

 

Hvis du bruker mysql-klienten istedenfor mysqlphpadmin, eller ihvertfall poster sql-kommandoene du bruker, og evt. feilmeldingene du får, så blir det mulig å hjelpe deg. Skjermdumpenen sier for lite.