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

[stelar7]

Er ikke relasjonstabell og knyttetabell det samme?

[quantum]

Jo, vi mener begge tabellen "i midten", Person_på_Reise, tror jeg?

Endret 28. april 2013 av quantum

[stelar7]

joa, så, da for å legge til en reise, så må jeg lage en ny rekke i reisetabellen, for å så legge til x antall i Person_på_reise tabellen?

(Det virker ikke som en særlig god måte å gjøre det på, imho. men hva vet vel jeg)

Endret 28. april 2013 av stelar7

[MMDE]

Legg inn en ny personen i person tabellen (med mindre den alleredet eksisterer)

Legg inn en ny reise i reise tabellen (med mindre den alleredet eksisterer)

Link deretter (unikt, hvis ønskelig) en person til reisen i Person_på_Reise tabellen.

 

Høres kanskje litt rart ut at dette er lurt, men det er altså det av mange gode grunner, men må spise nå så kan vel ramse opp det senere, eller du kan lese om hvorfor man normaliserer databaser.

Endret 28. april 2013 av MMDE

[quantum]

Riktig, forutsatt at disse personene du refererer fra Person_på_reise-tabellen faktisk fins i Person-tabellen, og reisen i Reise-tabellen. Hvis de ikke gjør det har du fått deg en inkonsistent database, og dette unngår du ved å opprette fremmednøkkelrestriksjoner, da vil databasen gi deg feilmeldinger når du prøver å sette den i en inkonsistent tilstand.

 

(Merk at begrepet "relasjon" i databaseteori ikke har noe å gjøre med at flere tabeller er relatert til hverandre gjennom fremmednøkler og evt. via knyttetabeller, en relasjon er rett og slett det abstrakte begrepet for en tabell, ref: https://en.wikipedia.org/wiki/Relation_(database) )

Endret 28. april 2013 av quantum

[quantum]

(Det virker ikke som en særlig god måte å gjøre det på, imho. men hva vet vel jeg)

finn på en bedre, så skal du se at du blir både rik og berømt ;-)

 

edit: det fins "bedre" måter å gjøre det på - hvis du ikke trenger alle de egenskapene en relasjonsdatabase gir deg, men i steden har andre behov. For eksempel hvis integritet ikke er så viktig som hastighet. Google NoSQL så finner du at det i de senere åra har dukket opp en hel bråte "alternative" databaser som gjør ting annerledes enn relasjonsdatabaser,og det er heller ikke noe nytt med alternative dabasemodeller, hierarkiske databaser, objektdatabaser og grafdatabaser har eksistert i årevis. Det er imidlertid slik at i veldig mange sammenhenger er de egenskapene relasjonsdatabasen har meget viktige, og det er derfor relasjonsdatabasene har vært dominerende i mange, mange tiår.

Endret 28. april 2013 av quantum

[stelar7]

Ser ut til å funke fint, men det virker unødvendig vanskelig å legge til så mangen ganger..

[quantum]

Ja, du har nevnt det allerede, vi venter i spenning ...

[stelar7]

Venter på hva?

[quantum]

Forklaringen på hvordan det *egentlig* skal gjøres, vel :-P

 

Denne måten å gjøre det på har vært dominerende i godt over 40 år, og det er som du sier "litt tungvint", men hensikten er altså å unngå feil. Hvis du følger reglene til relasjonsmodellen så får du visse garantier tilbake, og hvis du ikke trenger disse garantiene kan du gjøre ting litt enklere, men du må da akseptere slike ting som at kontoutskriften din ikke stemmer, at ikkeeksisterende personer kan sitte på flere fly samtidig og lignende. Når du har tre tabeller kan du fint klare å sikre konsistente data ved å programmere tester og valideringer selv, men hva når du har tusen tabeller og ingen oversikt over hvor mange hundre systemer som oppdaterer databasen? Da er du helt sjanseløs, uansett hvilke ressurser du har til rådighet, og relasjonsmodellen blir helt uvurderlig.

[stelar7]

La oss se om jeg har skjønt dette nå.

Har et slags kortspill der det lagres info om brukerkontoen, stats om brukeren og om kortene.

 

Blir det da "rett" med følgende schema?

 

Burde jeg slå sammen accounts med account_info? evnt. andre endringer?

Endret 7. mai 2013 av stelar7

[MMDE]

La oss se om jeg har skjønt dette nå.

Har et slags kortspill der det lagres info om brukerkontoen, stats om brukeren og om kortene.

 

Blir det da "rett" med følgende schema?

 

Burde jeg slå sammen accounts med account_info? evnt. andre endringer?

 

Du kan sikkert slå sammen de ja, men jeg prøver å se litt på det andre du har gjort. Kommer litt ann på hvordan du kommer til å bruke denne informasjonen, men mest sansyneligvis kan du slå dem sammen.

 

Ja, du har en unik primary key i hver tabel som et eget felt. Du trenger ikke ha et eget felt for dette hvis det er noe annet som unikt kan identifisere en rad, i hvilket tilfelle du må gjøre disse feltene sammen til en unik primary key. Det kan være greit å ha et id nummer når det kommer til brukerkontoene, selv om de har et unikt brukernavn, men det er opp til deg. Du trenger ikke forandre noe av det.

 

Jeg får intrykk av at du mangler en liste over all kortene som er en person eier (accountid, cardid).

 

 

Jeg ble også litt nysgjerrig rundt hvordan du lagrer passord. Håper du gjør fornuftige ting med passordet før du legger det i databasen (salt, hash etc). Jeg tar det som at dette er for en nettside og du skriver PHP, så jeg håper også du kjekker data som blir brukt mot databasen på en sikker måte (sanitize input).

[stelar7]

Alle kortene er tilgjengelig fra starten av, så det er ikke noe problem. Har ID på brukerkontoene fordi det blir brukt til å identifisere kortstokkene til brukerene (kan vel bruke brukernavnet, men int er vel bedre?)

 

Passord blir hashet og saltet ja.

 

Dette er en standalone applikasjon (ikke så veldig sikker men...) og input blir skjekket

Endret 7. mai 2013 av stelar7