[Løst] Hjelp til datatype og query, evnt. alt?

[MMDE]

Jeg har jo all infoen som trengs i de to tabellene?

Personer har id og fullt navn.

Reiser har id, til og reisende. Fra er irrelevant da det kun er reisemål som skal føres inn.

 

Husk, prøver bare å hjelpe deg. Slik jeg satt det opp er mye bedre av ganske mange grunner, og du bør lese opp litt på det, men jeg tror nok med litt erfaring at du smertelig vil erfare at det er mye bedre. Ikke bare er det lettere å jobbe med, men det er faktisk ikke mye mer data som lagres, faktisk i det aller fleste tilfellene mindre. I ditt tilfelle er det ganske likt tror jeg, men du sparer litt på den måten jeg satt det opp. Du gjør også det mye enklere å utvide databasen med mer informasjon. Det er lettere å redigere data, alt er mer unikt og skaper en mer database som er mye lettere å behandle. Slik du har satt det opp kan du ende opp med duplikat data. Jeg glemte forsåvet å nevne primary key, unique, auto increment, foreign key etc for de fleste tabellene, men det er litt opp til deg, og du skal ha en eller flere for hver tabell. Løsningen du kom fram bruker antageligvis ikke bare mer plass men også mer resurser, og problemet du hadde oppsto på grunn av dårlig modellering/normalisering av databasen

 

Slik andre har linket til tidligere:

https://en.wikipedia...e_normalization

 

Det kan virke litt rart først, men prøv det ihvertfall, og se hvordan det går. Du kan spare deg selv så mye hodebry. Hvis du har oppnådd alt du skal i ditt prosjekt, så greit nok, men sånn til framtiden, tenk på det.

Endret 28. april 2013 av MMDE

[quantum]

Jeg har jo all infoen som trengs i de to tabellene?

Personer har id(int) og fullt navn(varchar).

Reiser har id(int), til(varchar) og reisende(varchar). Fra, når og hvor lenge er irrelevant da det kun er reisemål som skal føres inn.

 

Det er ikke godt å vite hvordan du har tenkt å bruke feltet "reisende" her, men utifra det du har skrevet tidligere ser det ut til at feltet skal inneholde en liste person-id'er. Man kan som sagt lagre lister av verdier i enkelt-felt i databasen i visse tilfeller uten at det nødvendigvis er veldig uheldig. Det forutsettes da at dette er verdier som ikke er knyttet til annen informasjon i databasen på noe vis.

 

Å lagre lister av nøkkelverdier som refererer til rader i en annen tabell er kroneksempelet på hvordan man ikke skal gjøre det. Hver gang du fjerner en rad i Person-tabellen må du nå gå gjennom alle rader i Reise-tabellen, parse alle listene med person-id'er og sørge for at verdien du har fjernet fra Person-tabellen ikke forekommer noe sted. Grunnen til at vi bruker relasjonsdatabaser er nettopp at de er ekstremt flinke til å passe på slike ting for oss, hvis vi bruker dem riktig. Og riktig bruk er her slik som andre allerede har vært inne på - å opprette en knyttetabell med fremmednøkler. Da vil databasen forhindre deg i å manipulere dataene slik at de blir inkonsistente (referanseintegritet opprettholdes automatisk)

 

Det du prøver å brette hjernen din rundt her er en helt triviell mange-til-mange-relasjon, og det er kun én riktig måte å implementere dette i en relasjonsdatabase på; lag en knyttetabell kalt person_på_reise, som inneholder en FK til Person.id og en FK til Reise.id. Disse to kan sammensatt utgjøre knyttetabellens PK, evt. kan du introdusere et eget id-felt som teknisk primærnøkkel.

 

http://en.wikipedia.org/wiki/Many-to-many_(data_model)

Endret 28. april 2013 av quantum

[stelar7]

Blir det ikke one-to-many?

En reise knyttet til mange personer?

 

Kan en ikke bare ta

update reiser set personer=null where find_in_set(person.id,personer)

for å tømme den raden?

Endret 28. april 2013 av stelar7

[MMDE]

Blir det ikke one-to-many?

En reise knyttet til mange personer?

 

Nei, mange reiser knyttet til mange personer.

 

Vi snakker om mer enn en reise her, riktig? Ellers så ville reiser vært helt unyttig informasjon, bare behøvd en liste over alle personene som skal med på den ene reisen. Så lenge det er snakk om at det finnes mer enn en reise, og hver reise er knyttet til mer enn en person, så er det mange til mange.

 

Kan en ikke bare ta

update reiser set personer=null where find_in_set(person.id,personer)

for å tømme den raden?

Men hva hvis du bare vil ta bort en person?

Endret 28. april 2013 av MMDE

[stelar7]

Takk for at dere ikke gir opp på meg

Kan egentlig ikke noe særlig på dette med keys...

Sitter egentlig bare primarykey på id av en eller annen grunn, uten å vite hva den gjør eller hvorfor...

 

EDIT:

Når jeg tenker over det så vil jo ikke personer som er fjernet fra person tabellen vises, da de ikke er funnet i settet?

 

@quantum

Hvordan finner jeg da navnet på personer?

Endret 28. april 2013 av stelar7

[MMDE]

Takk for at dere ikke gir opp på meg

Kan egentlig ikke noe særlig på dette med keys...

Sitter egentlig bare primarykey på id av en eller annen grunn, uten å vite hva den gjør eller hvorfor...

 

Men, du, som jeg sa tidligere, prøver du ikke egentlig å beskrive 4 ting?

Personer

Steder

Reiser

Passasjerer (i en reise)

 

Om du mener "navn" på stedet er nok, så okay, men du taper plass på å ikke ha den med om ikke hvert sted kun brukes en gang. Dette fordi du må bruke varchar hele tiden, istedenfor en int for å beskrive det unike stedet. Du kan også ha to forskjellige steder med samme navn, og navnene kan være lengre uten at det spiller noen rolle, du kan til og med legge til mer informasjon om stedet etc etc om du bare lager en egen tabell for det. Ikke minst trenger du bare redigere navnet et sted for å forandre det alle steder.

 

Jeg fåreslo også at du skulle bruke to felt for navn. Mye lettere å søke igjennom.

 

@quantum

Hvordan finner jeg da navnet på personer?

Slik han viste det og jeg fåreslo, så ville det vært noe sånt som det her:

SELECT p.navn
FROM Person_på_Reise AS ppr
INNER JOIN Person AS p
ON ppr.Person_id = p.Person_id
WHERE ppr.Reise_id = 10

For eksempel, for å finne alle reisende i reise med id 10.

(sorry, skrev en typo i queryet, fikset det, slitsomt å scrolle opp og ned og huske lol)

Endret 28. april 2013 av MMDE

[stelar7]

Kan hende jeg er milevis på bærtur, men det er jo ikke noe der som peker til personer_på_reise?

 

Der kom en edit ja...

 

Gawd, liker sql mindre og mindre xD

Endret 28. april 2013 av stelar7

[MMDE]

Kan hende jeg er milevis på bærtur, men det er jo ikke noe der som peker til personer_på_reise?

 

Der kom en edit ja...

haha, ja, skrev bare en liten typo. Drev å scrollet opp og ned og så på det lille miniatyrbildet. Skulle åpnet det i en ny fane og hatt den ved siden av. <_< Merker også at norsken min er blitt elendig etter nesten bare å ha skrevet engelsk i åresvis.

Endret 28. april 2013 av MMDE

[stelar7]

Tror du du kan forklare hva som gjør hva i den queryen? LEFT JOIN, ON, osv... (Kan ikke så mye at det gir mening lol)

 

Hvis en person registrerer en reise for fire andre under hans navn, hvordan vill databasen "handle" det? Legge til samme personen fire ganger?

Endret 28. april 2013 av stelar7

[MMDE]

Tror du du kan forklare hva som gjør hva i den queryen? LEFT JOIN, ON, osv... (Kan ikke så mye at det gir mening lol)

 

Hvis en person registrerer en reise for fire andre under hans navn, hvordan vill databasen handle det? Legge til samme personen fire ganger?

 

JOIN er generelt at du slår sammen to tabeller. For å slå dem sammen må de ha noe data felles, ellers så vet du ikke hvor du skal slå dem sammen. Dette gjøres ved hjelp av ON.

 

Angående LEFT, det finnes mange forskjellige måter å slå sammen tabeller. Jeg brukte LEFT JOIN fordi jeg ønsket å vise reisen om den ikke hadde noen passasjerer, men blir kanskje ikke helt riktig det for deg. Bruk INNER JOIN hvis du ønsker at det ikke skal være noen rader hvis det ikke er noen passasjerer på reisen.

 

Finnes mange forskjellige sider som kan forklare deg de forskjellige JOINs etc. Men ja, det de gjør er å slå sammen tabeller.

 

Tror du kan gjøre "ON" i WHERE også.

WHERE ppr.Personid = p.Person_id AND ppr.Reise_id = 10

Men jeg synes det blir veldig rotete.

Endret 28. april 2013 av MMDE

[quantum]

Blir det ikke one-to-many?

En reise knyttet til mange personer?

 

 

Dét kan du få til med bare to tabeller. Men personene blir kanskje litt lei når de oppdager at de bare får dra på en reise? Selv om de riktig nok slipper å reise alene ...

 

(Resten av spørsmålet forstår jeg ikke ... sorry)

[quantum]

 

Sitter egentlig bare primarykey på id av en eller annen grunn, uten å vite hva den gjør eller hvorfor...

 

@quantum

Hvordan finner jeg da navnet på personer?

 

Da må du lese om primærnøkler i lenkene vi har postet.

 

Navnene finner du med "select navn from person" men det er vel ikke egentlig det du lurer på?

 

Og glem denne find_in_set-funksjonen, det "virker", men det gjør post-it-lapper også.

[quantum]

 

Hvis en person registrerer en reise for fire andre under hans navn, hvordan vill databasen handle det? Legge til samme personen fire ganger?

 

Databasen "handler" det ikke.

[stelar7]

Databasen "handler" det ikke.

 

Så hva skjer da? Feilmeldig? Hvis det ikke går ann, hvordan kan det bli endret til å funke?

Endret 28. april 2013 av stelar7

[quantum]

Så hva skjer da? Feilmeldig? Hvis det ikke går ann, hvordan kan det bli endret til å funke?

Jeg er ikke helt sikker på om jeg forstår dette spørsmålet heller, men i utgangspunktet så vil du ønske å få en feilmelding, og det får du hvis du sørger for at det er en unik indeks på Person_id og Reise_id-feltene i knyttetabellen. Hvis du ikke legger på en slik unik indeks som omfatter begge feltene kan du registrere samme person på samme reise flere ganger.

 

Edit: Hvis du designer databasen slik blir kunden din - flyselskapet - ikke særlig happy, siden det åpner for at de må betale ut bonuspoeng til samme passasjer flere ganger for samme reise, og det kan han jo umulig ha gjort seg fortjent til.

Endret 28. april 2013 av quantum

[MMDE]

Jeg er ikke helt sikker på om jeg forstår dette spørsmålet heller, men i utgangspunktet så vil du ønske å få en feilmelding, og det får du hvis du sørger for at det er en unik indeks på Person_id og Reise_id-feltene i knyttetabellen. Hvis du ikke legger på en slik unik indeks som omfatter begge feltene kan du registrere samme person på samme reise flere ganger.

Kanskje han mener at det burde være lovelig, og i hvilket tilfelle så må du ikke gjøre det du sier, og alt vil fungere greit. Samme personen vil da komme opp i resultatet flere ganger og kan unikt identifiseres om du har en unik id i Person_på_Reise tabellen.

 

Ellers er det som du sier, du trenger egentlig ikke en ekstra id nøkkel der om du ikke ønsker at en person skal kunne kjøpe billetter for andre og alle registreres under samme navn, for da kan du bruke Reise_id og Person_id sammen (ikke unik hver for seg) som en unik nøkkel.

Endret 28. april 2013 av MMDE

[stelar7]

Og da hvis jeg skal legge in en ny reise, hvordan blir det? Må jeg legge til i relasjonstabellen?

[quantum]

nei

[stelar7]

Hvordan kan jeg da registrere hvem som er på reisen?

Endret 28. april 2013 av stelar7

[quantum]

da må du legge inn rader i knyttetabellen.