Optimalisering → En tabell eller flere?

[Fjoggs]

Hei

Jeg er webansvarlig for en kameratside som skal rekodes, dermed benytter jeg meg av muligheten for å optimalisere databasen. Er forløpig kun i planlegging/modelerings fasen og under ER modeleringen ble jeg usikker på om jeg bør skille ut en tabell i flere (Jeg ser for meg flere svake entitesklasser som alle slekter til den samme entitetsklassen med en til en forhold.).

 

Problemstillingen min er:

Bør jeg dele opp (en for meg) stor tabell (entitetsklasse), med tanke på antall kolonner (antributter), i flere små?

 

Mer spesifik så har jeg nå en entitetsklasse som inneholder alle personlige info (atributter: brukernavn, epost, osv) og alle bruker instillinger (atrinutter: antall nyheter på forsiden, -poster, bilder i galleriet, osv)

 

Er det mer effektivt (bedre) å splitte denne opp i entitesklasser for hvert område, slik som ER diagrammet under viser, eller bør jeg ha alt i en tabell?:

 

 

Jeg synes det blir mer oversiktelig med en slik deling, men har det noe å si for databasen?

Har antall atributter noe å så si på hastigheten til et tabell søk?

 

Forøvrig har jeg etter søk på forumet og google kun kommet frem til indeksering og lignede når det gjelder database optimalisering. Følgende hvis noen av brukerene her på forumet har et bokmerke med informasjon tilknyttet mine spørsmål, som han/hun vil/kan dele, blir jeg meget taknemmelig.

 

Takker for all tilbakemelding

[mikaelandre]

jeg er vel ikke noe ekspert, men kan jo si hva jeg mener:

 

du bør generelt aldri dele opp en tabell bare fordi den har mange attributter. det som har noe å si når det gjelder hastighet ved søk er hvilken attributt du søker på, indeksering og antall poster. databasen henter ikke fram de andre attributtene før den har funnet indeksen uansett.

 

men du bør dele opp en tabell hvis den inneholder felter som er felles for postene, dvs at de forskjellige postene er like i de feltene. feks hvis en attributt heter "brukertype" kan det være lurt å skille denne ut i en egen tabell, slik at du er sikker på at alle brukerne har gyldige typer. hvis ikke risikerer du skrivefeil, og "admin" og "admni" vil begge kunne bli registrert. dette kan også løses med en ENUM eller SET felt i attributten, men da kan du ikke lagre mer info om den hvis du skulle få behov for det senere.

 

en annen ting er at du kan dele opp nesten i det uendelige, men du bør stoppe når du deler opp kun fordi det er mulig. et mye brukt eksempel er å dele opp postnummer/poststed i egen tabell, som må gjøres for å normalisere tabellen. men har du få brukere er dette bare unødvendig tungvindt.

 

når det gjelder oppdelingen din så er det vanskelig å si uten å vite mer om de forskjellige tabellene, men jeg bruker ganske skjedlen svake entiteter. nå var professoren min veldig glad i svake entiteter, så det kan jo være bra

[Fjoggs]

Takk for tilbakemeldingen.

 

For øyeblikket er databasen designet etter tredje grads normal form, med enkelte untakk av atributter i et par entitesklasser.

 

Hvis jeg har forstått deg rett så har ikke antall atributter noe å si for en tabell, men hvordan man indekserer den. Alikevel så er jeg usiker om jeg bør deginet tabellen min slik, men har kommet opp med tre forskjellige design:

• Alt i en tabell
  » Denne tabellen vil da innholde all bruker informasjon og bruker innstillinger.
  
• To tabeller
  » En tabell for bruker informasjon og en for bruker instillinger.
  
• Mange tabeller
  » En tabell for bruker informasjon og en tabell for hver av brukerinstillings typene
  

Bruker informasjon er av typen:

Brukernavn, epost, passordhash, salt, fornavn, etternavn, addresse, registrert siden, tittel,sist aktiv, fødselsdag, osv

 

Bruker instillinger er av typen:

Antall nyheter på forsiden, antall forum poster på forsiden, antall nyhets kommentarer, antall bilder i galleriet, antall kommentarer til bildene i galleriet per side, antall forum emner per side, antall forum kommentarer per side, forum sotering, bruke signatur, se signaturer, se avatarer, bruke avatar, osv

 

Med andre ord så er det mange like instillingstyper, men de skal kunne være forskjellige fra forumet, galleriet, artikklene, forsiden osv.

 

Brukerene bestemmer

Jeg er tilhenger i å gi brukerene flest mulig innstilinger og muligheter til å kontrolere utsende, derfor blir det så mange ulike atributter. Poenget er jo at ikke alle disse atributtene er nødvendig på samme tid, for eksemple er galleri instillinger ikke nødvendige for forumet.

 

Det er på grunlag av det jeg er usikker på designet:

Vil det ta lenger tid for php-mysqli å koble til og hente data fra mysql databasen hvis den må sortere bort mange atributter enn hvis den kunne hente alle (SELECT * FROM forumInnstillinger WHERE brukerID = 'fjoggs') når det trengs?

 

Et viktig aspekt som kanskje ikke har kommet frem, er at dette er en kamerat side som alldri kommer til å bli noe annet. Vi er nå 17 stykker i medlemsregisteret, der 5 stykker bruker siden daglig. Det sier seg selv at jeg ikke er redd for at databasen skal bli for stor. Dermed føler jeg database designet ikke trenger å bli perfekt, men at kompromisser kan inngås.

 

Jeg håper noen har tid til en kommentar eller eventuelt kjenner til literatur som omhandler emenet.

Takk

 

Edit

• Skrivefeil
  
• Gramatikkfeil
  
• Hadde hoppet over noen ord
  

Endret 9. november 2005 av Fjoggs

[henningml]

Hei.. beklager at jeg ikke gidder gi deg noen ordentlig analyse av situasjonen, selv om du har gjort deg stor flid med oppgaven selv

 

Rent effektivitets-messig blir det ikke bra å dele tabellen slik. Om du trenger parametre på en bruker som ligger i forskjellige tabeller må du joine i query (eller kjøre to queries), og det blir ikke spesielt effektivt.

 

Ei heller er det "riktig" å spre informasjonen på denne måten.

 

Det jeg ville gjort var å opprette en tabell med følgende kolonner:

Id, primærnøkkel

gruppe, index

person, index

variabel, index

verdi

 

Id er bare løpenummer

 

gruppe er en måte å gruppere verdiene på, istedenfor å ha verdiene i forskjellige tabeller. Feks "forum" kan være en gruppe, og samle alle data som har med forum å gjøre.

 

variabel er hvilken verdi som lagres

 

verdi er verdien som lagres selvfølgelig.

 

 

Med index på gruppe og person vil du kunne trekke ut subsett svært effektivt, feks "alle forum-instillinger på person X". Hastigheten vil være tilsvarende til at disse verdiene lå i sin egen tabell. Du kan også feks gjøre noe slikt: "alle forum-instillinger samt adresse-info om person X" uten å måtte joine to tabeller i query. Det blir fremdeles så effektivt som det kan bli.

 

Du oppnår altså å samle alle brukerdata i en tabell, ingen fare for inkonsistente data. Og du oppnår effektiv gruppering og uttrekk av subsett av data. Du vil også fritt kunne legge til mer data på brukere uten å gjøre database-endringer.

Endret 12. november 2005 av henningml

[vidarv]

gjør ting enkelt!

 

Jeg ville laget en tabell med alle attributtene...

Dette vil være mest effektivt ved søk.. så slipper du så mange join setninger... eller hadde du tenkt å kjøre flere spørringer evt?... det vil i så fall koste dyrt da det tar lenger tid å spørre 6 ganger enn å spørre 1 gang etter en rad som har tomme felter...

 

 

 

Tips: Gjør ting enkelt... da går ting som oftest kjappest...

 

 

Til nøds kunne du jo ha laget noen views over hvert av feltene om din database støtter dette...