Mange vs. store tabeller - MySQL

Sur og sarkastisk

8. mai 2014

Jeg vet ikke om det er "frowned upon" og lage to tråder på så kort tidspunkt, men jeg lurer på en ting, som er urelatert til den andre.

Hva er "best"? Store eller mange tabeller i MySQL? Gjør det noe forskjell om det er MyISAM eller InnoDB?

Sånn... burde jeg ha "user_gen", "user_values" og "user_stats" eller en stor "user" tabell? Er det sånn at ene er best inntil du når ett visst antall kolonner/tabeller?

H_Spyke

227 55

8. mai 2014

så lenge de er på 3. normalform så er det vel det samme i min mening.

Du burde alltid ha egen brukertabell, så du slipper og ramse opp navn, epost ++ hver gang du lagrer nye data :P

droppboks

Sur og sarkastisk

Trådstarter

1.513 619

8. mai 2014

Sitat av H_Spyke

så lenge de er på 3. normalform så er det vel det samme i min mening.

Du burde alltid ha egen brukertabell, så du slipper og ramse opp navn, epost ++ hver gang du lagrer nye data :P

Vis hele sitatet...

Men hvis vi sier jeg har totalt 12 rader med userdata pr. bruker, burde jeg da ha en stor tabell, eller en 2-3 små (organisert inn i "kategorier" som "stats" og "verdier")? Og har det noe å si på performance?

Jurgen1337

Disippel

1.079 375

8. mai 2014

Det kommer også lit an på hvordan spørringer du skal kjøre. Jo mer komplekse, jo tyngre blir det for motoren.

Maea

87 30

8. mai 2014

Om du har en tabel som heter bruker med 12 rader er jo ikke det et problem, men det er jo heller ikke et problem om du vil dele den opp. Normalisering er fint og alt, men overdrivelse er heller ikke bra.
I systemer der man ofte trenger komplisert, sammensatt informasjon kan det derfor enkelte ganger være en fordel med en lavere normaliseringsgrad.

Sist endret av Maea; 8. mai 2014 kl. 11:54.

robhol

NOOOOOOOOOOOOOOOOOO-

6.431 5.672

8. mai 2014

Fordelen med å normalisere er at du enkelt kan hente ut data i sammenhenger du ikke ante at du trengte. Når behovet melder seg, kan du skrive en ny spørring og la databasen ta seg av utvalget i stedet for å gjøre det selv.

fuzzy76

webdings

2.482 589

8. mai 2014

Hvis en tabell alltid har en rad for hver eneste bruker, dvs at de alltid har like mange rader er det feil å ha det i to tabeller - da bør de slås sammen. Dette er den laveste formen for normalisering som akademikere har skrevet mye om. I tillegg vil spørringer på den type data gå kjappere fordi du bare har en indeks å forholde deg til.

Sist endret av fuzzy76; 8. mai 2014 kl. 13:34.

0xFF

War room

2.408 1.141

9. mai 2014

Jeg er ikkje noe ekspert innen relasjonsdatabaser. Men ville ikkje dette vært et bra sted å bruke metadata tabeller eller hva det kalles? Slik at TS har en tabell der hver bruker får en rad, denne kan inneholde informasjon som email og passord samt bruker ID. I tillegg så lages det en tabell med kolonnene bruker ID, meta-nøkkel og meta-verdi samt meta ID. Denne modellen er jo veldig skalerbar, trenger man mer informasjon om brukeren så legger man bare til en ekstra meta-nøkkel i scriptet. Og det er jo også mulig å bruke Alias for å få spørringen til å se ut som den kommer fra en 12 kolonners tabell.

( Jeg hadde ikkje MySQL workbench tilgjengelig som jeg vanligvis bruker, så jeg valgte notepad til jobben ).

nudo

Avventende

1.819 129

9. mai 2014

Hos meg er det

User
UserAccess
UserContact
UserContactDetail
UserMisc

Det som teller er at du benytter int som nøkkel i relasjonen mellom tabellene,
og utf-8 til alle tegn, selv om du ikke trenger det pr i dag.

Jeg syns også det er fint med tabell/klassenavn i entall, da en tabell sjelden kan beskrive mer enn én bruker,
flertall kommer av antall poster, og et evt bruk av users hører kun hjemme i et utvalg hvor antallet er over 1,
m a o listevisning.

Tommelfingerregel: relasjoner: InnoDB, flatfil: MyISAM

http://stackoverflow.com/questions/2...us-innodb?lq=1

Sist endret av nudo; 9. mai 2014 kl. 08:13. Grunn: Automatisk sammenslåing med etterfølgende innlegg.

hayer

806 147

9. mai 2014

Spørsmålet angående performance er vel mer; hvor mye skal du hente ut?
Raskere å hente ut data fra én tabel enn å joine over flere f.eks.

Personlig har jeg; Users, og UsersData - som kun inneholder ting som fornavn, etternavn, etc.

Users - innlogging,
UsersData - alt annet

Men balanse gangen må du nesten finne selv. Alltid et helvette å ha en tabel med 100ish kolonner i.

nudo

Avventende

1.819 129

9. mai 2014

Det kan ofte lønne seg å ha en enkel tabell som takler epost/telefonnummer-aktig info, og en tabell som håndterer addresse separat dersom du skal ha forskjellige regler for formattering av zip code pr land.

Kode

UserContactData.userContactDataID = "1"
UserContactData.userID = "33"
UserContactData.data="1880"
UserContactData.media="phone"

Address.addressID = "1"
Address.userID = "33"
Address.street = "Humlerudkleiva 89"
Address.postalcode = "8989"
Address.country = "no"
Address.unlocode = "NOHRK"

Kode

UserLogin.userID = "33"
UserLogin.previousLogin = "2014-05-08 13:37:30"
UserLogin.username = "n@u.do"
UserLogin.validation = "0bUGDDqy7vVdgOmRXzhTEsjCMc18TgSNRxRFKtxMucnuRbryqIy6+WanuRXp5YOJW+/"

UserPreferences.userID = "33"
UserPreferences.timezone = "timezone"

Da har jeg vist deg måten jeg har delt opp brukertabellen i noen prosjekter jeg har vært med på.

Just my ¢2 worth

Sitat av hayer

Spørsmålet angående performance er vel mer; hvor mye skal du hente ut?
Raskere å hente ut data fra én tabel enn å joine over flere f.eks.

Vis hele sitatet...

Men ved å planlegge litt kan man også planlegge skalerbarhet.

Sist endret av nudo; 9. mai 2014 kl. 16:52. Grunn: Automatisk sammenslåing med etterfølgende innlegg.