struktur til bedømmelsessystem

tblvideoer:
id - INT, PK, AUTO
...

tblbilleder:
id - INT, PK, AUTO
...

tblvurdering:
id - INT, PK, AUTO
type - TINYINT, pseudo FK
relate_id - INT, FK
vurdering - TINYINT

er vel OK men jeg ville overveje:

tblmultimedie:
id - INT, PK, AUTO
type - TINYINT
...

tblvurdering:
id - INT, PK, AUTO
relate_id - INT, FK
vurdering - TINYINT

medmindre der er stor forskel på de øvrige felter for video og billed.

jeg slår tblbilleder og tblvideo sammen som du forslår.

Jeg havde alligevel et blob-felt i tblvideoer (til thumbnail fra video) og det felt kan jo ligeså godt være en billede-fil.

Dog vil der komme et felt (filnavn) som skal sættes til at må være NULL, da det felt skal bruges til videofilen (som er uploaded via din javaapplet) og som ikke kommer i brug hvis multimediet er et billede.

CREATE TABLE `tblvurderinger` (
  `id` int(11) NOT NULL auto_increment,
  `relationsid` int(11) NOT NULL default '0',
  `vurdering` tinyint(1) NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `type` (`relationsid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;


CREATE TABLE `tblforummultimedier` (
  `id` int(11) NOT NULL auto_increment,
  `label` varchar(30) NOT NULL default '',
  `beskrivelse` varchar(255) default NULL,
  `filnavn` varchar(100) default NULL,
  `billedefil` blob,
  `oprettet` datetime NOT NULL default '0000-00-00 00:00:00',
  `brugerid` int(11) NOT NULL default '0',
  `status` tinyint(1) NOT NULL default '0',
  `type` tinyint(1) NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `type` (`type`),
  KEY `status` (`status`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Nu jeg er ved at slp tabeller sammen, så overvejer jeg om det ville være en fordel at slå tblforumtopposter og tblforumposter sammen. tblforumkategorier er også inde i billedet.

Det jeg tænker lidt over er hvordan jeg smartest får defineret hvilke indlæg der er topposten og hvilke der er svarene på topposten?

tblforumkategorier
id  int(11) NOT NULL   
type  tinyint(4) NOT NULL   
label  varchar(30) NOT NULL   
beskrivelse  varchar(255)NULL


tblforumtopposter
id  int(11) NOT NULL   
kategoriid  int(11) NOT NULL
brugerid  int(11) NOT NULL
oprettet  datetime NOT NULL   
emne  varchar(40) NOT NULL   
indhold  text NOT NULL   
status  tinyint(1) NOT NULL

tblforumposter
id  int(11) NOT NULL   
toppostid  int(11) NOT NULL   
brugerid  int(11) NOT NULL   
oprettet  datetime NOT NULL
indhold  text NOT NULL   
status  tinyint(1) NOT NULL

tblforumkategorier
id  int(11) NOT NULL 
type  tinyint(4) NOT NULL 
label  varchar(30) NOT NULL 
beskrivelse  varchar(255)NULL


tblforumposter
id  int(11) NOT NULL 
kategoriid  int(11) NOT NULL
brugerid  int(11) NOT NULL
oprettet  datetime NOT NULL 
emne  varchar(40) NOT NULL 
indhold  text NOT NULL 
status  tinyint(1) NOT NULL
parentid int(11) NULL

hvor parentid er NULL for top poster lyder umiddelbart OK for mig.

Eller måske bedre:

tblforumkategorier
id  int(11) NOT NULL
type  tinyint(4) NOT NULL
label  varchar(30) NOT NULL
beskrivelse  varchar(255)NULL

tbltraad
id int(11) NOT NULL
kategoriid  int(11) NOT NULL
emne  varchar(40) NOT NULL

tblforumposter
id  int(11) NOT NULL
brugerid  int(11) NOT NULL
oprettet  datetime NOT NULL
indhold  text NOT NULL
status  tinyint(1) NOT NULL
parentid int(11) NULL
traadid int(11) NOT NULL

for at afspejle at et svar ikke kan skifte kategori - og i min fortolkning heller ikke
skifte emne

dit første forslag synes jeg bedst om
jeg ved ikke helt hvad der er fordelen ved nr. 2

at en tråd ikke kan skifte kategori eller emne

Det kan den vel godt? hvorfor kan den ikke? :)

det er ikke meningen at man skal kunne skifte hverken kategori eller emne, men jeg kan ikke se hvorfor det ikke er muligt i det eksempel

fordi kategori og emne ligger i tråden

1 række i tbltraad med 47 rækker i tblforumposter (hm - tbltraad skulle nok hedde tblforumtraad !)

alle 47 poster faar kategori og emne fra den ene række i traad tabellen - derfor er
de garanteret ens for alle poster

ja okay på den måde

men ud over det, er der ingen performancemæssig fordel ved sidste forslag?

Nej. Snarere tværtimod. Det vil give en ekstra join.

Men normalt designer man tabelstruktur for at sikre data konsistens - og så
får man det til at performe godt bagefter.

ok det vil jeg gerne
hvordan får man dette eksempel til at performe godt?

første skridt er index på traadid feltet

sandsynligvis er performance så god nok

ok easy :)
du skal have nogle point
tak for hjælpen endnu engang

svar