Helt nybegynner på databaser, trenger litt veiledning.

[hvabehager]

Hei,

 

La oss si at jeg skal sortere en bildesamling i mysql. Jeg har statiske verdier for bilde som:

 

Bildetype (Sort/hvitt - Farge - Negativ)

Tilstand (Dårlig - Ok - Bra)

Periode (90-tallet - 80-tallet - 70-tallet - Nåtid)

 

Er det ikke like greit å bare ha alt i en tabell for de statiske verdiene, eller tenker jeg helt feil da (altså at jeg bør ha tre)? 

 

Altså

 

attributtID   beskrivelse

--------------|-----------

1                 Dårlig

2                 Ok

3                 Bra

4                 Sort/Hvitt

5                 Farge

6                 Negativ

7                 90-tallet

8                 80-tallet

9                 70-tallet

10               Nåtid

 

 

Og hvis dette er ok, kan jeg da bruke attributtID som Primary Key, og så referere til den i flere kolonner hvis jeg skal lage en oversikt over et enkelt bilde? Eksempel, bilde1 peker tre ganger til tabellen over.

 

bildeID    navn    periode    tilstand    bildetype

-----------|---------|------------|------------|--------------------------------

1             Oslo         9             2              4

 

 

 

Er det slik det gjøres, eller er dette bare tull? Og isåfall, er det noen som kunne ha forklart litt? 

 

På forhånd tusen takk!

[terjeelde]

God tommelfingerregel med databaser er å gjøre ting tydelig, ofte nesten overtydelig. Tenk gjerne at en som hadde arvet databasen etter deg lett skulle klart å finne meningen med alt.

 

Du kan gjøre ting som du had foreslått, men det kan gjøres tydeligere også.

 

Jeg tror jeg ville begynt med å skille mellom primærting, og ekstra/sekundær. For primærtingene, så vurder dem gjerne hver for seg. God/middels/dårlig etc, kan f.eks gjerne lagres som en numerisk verdi. Det gjør det også lettere å senere gjøre skoleringen som «Finn alle som er god eller bedre enn god».

 

Gå også gjerne etter primærinformsjon. Det er bedre å lagre en dato, enn nittitalls f.eks. Da kan du både søke etter nittitalls, og også f.eks sommer. Jeg vet ikke om den informasjonen er tilgjengelig for deg, men nevner som eksempel.

 

For sekundær/overskuddsinformasjon, så kan det kanskje vært lurt å bruke et tag-system, hvor du binder gjennom en bindetabell. Det dekker også fremtidig vekst i ulike typer informasjon du vil ha inn.

 

Du kan da ha tre tabeller:

bilder

tags

bildetags

 

Så slenger du inn tagger i tags, og i bildetags har du nesten ingen informasjon, bare IDer for bilder og tags, for å si hvilke bilde som har hvilke tags. Da støtter du også at ett bilde kan tagges med flere typer tags.

 

Om du ønsker, så kan de ulike taggene også ha kategorier.

[quantum]

Hei,

 

La oss si at jeg skal sortere en bildesamling i mysql. Jeg har statiske verdier for bilde som:

 

Bildetype (Sort/hvitt - Farge - Negativ)

Tilstand (Dårlig - Ok - Bra)

Periode (90-tallet - 80-tallet - 70-tallet - Nåtid)

 

Er det ikke like greit å bare ha alt i en tabell for de statiske verdiene, eller tenker jeg helt feil da (altså at jeg bør ha tre)? 

 

Altså

 

attributtID   beskrivelse

--------------|-----------

1                 Dårlig

2                 Ok

3                 Bra

4                 Sort/Hvitt

5                 Farge

6                 Negativ

7                 90-tallet

8                 80-tallet

9                 70-tallet

10               Nåtid

 

 

Og hvis dette er ok, kan jeg da bruke attributtID som Primary Key, og så referere til den i flere kolonner hvis jeg skal lage en oversikt over et enkelt bilde? Eksempel, bilde1 peker tre ganger til tabellen over.

 

bildeID    navn    periode    tilstand    bildetype

-----------|---------|------------|------------|--------------------------------

1             Oslo         9             2              4

 

 

 

Er det slik det gjøres, eller er dette bare tull? Og isåfall, er det noen som kunne ha forklart litt? 

 

På forhånd tusen takk!

 

 

Noe av poenget med å gjøre det (omtrent) slik du foreslår er at du kan opprette en foreign key constraint som sier at den fremmednøkkelen du legger inn i en kolonne må matche pk i en annen tabell. Dette er veldig nyttig med hensyn til å beholde dataintegriteten. 

 

Problemet med løsningen du skisserer er at du kan sette sette tilstand = 70 tallet og periode = Bra. Hvis du skal få dratt nytte av databasen til å opprettholde integriteten må du dele opp dette i flere tabeller.

 

Alternativet kan være å la rammeverket og programmeringsspråket holde orden på dette, eksempelvis med Java Enum og Hibernate User types. Så lenge applikasjonen "eier" databasen fungerer det også bra, men du får altså en Exception i applikasjonen og ikke en feilmelding i databasen når integriteten brytes. 

[hvabehager]

Tusen takk for svar. Som nevnt, jeg er helt nybegynner, og dette er bare noe jeg gjør for en kollega. Dette trenger ikke være noe hokus pokus, det trenger bare å være nok til å kunne legge inn litt info. Men da tror jeg at jeg lager meg tabeller for hver eneste statiske verdi som er i samme kategori, altså en tabell for tilstand, en for periode og en for type. 

 

Det er også slik at det er en liten historie som er med på hvert bilde. Burde det være i en tabell for seg selv og? Den kommer ikke til å forandre seg, så den kunne vel vært i "modertabellen" med bildeid og sånt?

[Emancipate]

Hvis du gjør det på den første måten din, med alt i en tabell, bør du bruke nye tallverdier for hver kolonne. Noe annet er bare unødvendig og forvirrende:

 
attributtID   beskrivelse

--------------|-----------

0                 Dårlig
1                 Ok
2                 Bra

0                 Sort/Hvitt
1                 Farge
2                 Negativ

0                 90-tallet
1                 80-tallet
2                 70-tallet
3                 Nåtid

Å lagre datoer er et kapittel for seg hvis man noen ganger ikke vet når bildet ble tatt. Optimalt bruker man selvsagt en datokolonne.

 

Edit: Det gjelder egentlig uansett hvordan du gjør det, men det er kanskje mer åpenbart at det skal gjøres på denne måten når man har forskjellige tabeller.

 

 

 

Det er også slik at det er en liten historie som er med på hvert bilde. Burde det være i en tabell for seg selv og? Den kommer ikke til å forandre seg, så den kunne vel vært i "modertabellen" med bildeid og sånt?

Hvis du ikke trenger å ha ut historien hver eneste gang du skal ha ut bildet, kunne du hatt den i en egen tabell. Om den forandrer seg eller ikke, er ikke en faktor.

 

Disclaimer: Jeg er ikke en ekspert.

Endret 19. desember 2017 av Emancipate

[quantum]

Hvis du gjør det på den første måten din, med alt i en tabell, bør du bruke nye tallverdier for hver kolonne. Noe annet er bare unødvendig og forvirrende:

 
attributtID   beskrivelse

--------------|-----------

0                 Dårlig
1                 Ok
2                 Bra

0                 Sort/Hvitt
1                 Farge
2                 Negativ

0                 90-tallet
1                 80-tallet
2                 70-tallet
3                 Nåtid

 

 

Absolutt ikke sånn. Tabellen skal ha en primærenøkkel som er unik, til nød kan man si at beskrivelsesfeltet her kunne vært primærenøkkel, men siden det er en beskrivelse som godt kunne tenkes å forekomme i flere enn én kategori blir det en dum begrensning. Dermed faller vi tilbake på attributtID, som navnet antyder skal være en id, eller PK, og den er jo absolutt ikke unik. 

 

Man kan legge til en kategoriID og la den være PK sammen med attributtID, da kan man uttrykke hvilke attributter som hører sammen i samme kategori også. AttributtID kan muligens være tenkt å gjøre nytten som sorteringsverdi, og da burde kolonnen hete noe lignende.

 

Man kan også legge til en "teknisk nøkkel", dvs. et felt uten semantisk mening som bare har som oppgave å identifisere en rad unikt, og la databasen fylle ut feltet fra en sekvens fortløpende som radene opprettes. Det er kanskje mest praktisk siden alle tabellene da kan behandles likt, man har alltid samme type PK og fremmednøkkel. Dette i motsetning til "naturlig nøkkel" (telefonnummer, emailadresse, fødselsnummer etc.)

 

Fins masse man kan google seg til her, det formelle står det litt om her https://en.wikipedia.org/wiki/Database_normalization (Se også linker til 1,2,3. normalform)

 

https://www.essentialsql.com/get-ready-to-learn-sql-database-normalization-explained-in-simple-english/

https://www.guru99.com/database-normalization.html

 

Hvis man gjør dette sånn nogen lunde riktig kan man spare seg for ufattelige mengder rot og arbeid. 

[Emancipate]

Dermed faller vi tilbake på attributtID, som navnet antyder skal være en id, eller PK, og den er jo absolutt ikke unik.

AttributtID er ikke en id. Det er bare en konstant for den verdien listet under beskrivelse.

Endret 21. desember 2017 av Emancipate

[quantum]

AttributtID er ikke en id. Nei vel, selvsagt ikke ...