Hjælp til opbygning pris database ala edbpriser

Har dette indtil videre

CREATE TABLE `butik` (
  `butikid` int(255) NOT NULL auto_increment,
  `butiksnavn` varchar(100) NOT NULL,
  PRIMARY KEY  (`butikid`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=5 ;

CREATE TABLE `pris` (
  `prisid` int(100) NOT NULL auto_increment,
  `pris` varchar(10000) NOT NULL,
  `butik_butikid` int(100) NOT NULL,
  `vare_vareid` int(100) NOT NULL,
  PRIMARY KEY  (`prisid`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=9 ;


CREATE TABLE `producent` (
  `producentid` int(255) NOT NULL auto_increment,
  `producent` varchar(255) NOT NULL,
  PRIMARY KEY  (`producentid`),
  UNIQUE KEY `producent` (`producent`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;



CREATE TABLE `vare` (
  `vareid` int(10) NOT NULL auto_increment,
  `varenavn` varchar(10) NOT NULL,
  `producent_id` int(100) NOT NULL,
  `storrelse` varchar(50) NOT NULL,
  PRIMARY KEY  (`vareid`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=21 ;

Dine størrelser ser meget mystiske ud INT(100), VARCHAR(10000) etc..

Jeg tror at jeg ville droppe prisid og bruge en 2 felts primary key.

Der må mangle en masse oplysninger om både butik og vare.

Hmm, kan godt se at værdierne er lidt mærkelige ud.
og ja der mangler en del oplysninger, men grundlæggende.

Så pris ville du lave sådan her ??

CREATE TABLE `pris` (
  `pris` float NOT NULL,
  `butik_butikid` int(10) unsigned NOT NULL,
  `vare_vareid` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`butik_butikid`,`vare_vareid`)

hvad er fordelen ved 2 felters primary key. Bedre index??

Ellers andet du ville foreslå.

Ja sådan.

Jeg tror aldrig at du ville bruge den prisid til noget som helst og så er der ingen grund
til at have den.

Hvad med historik (pris over tid) ?

Ja den får jeg nok ikke brug for.
Tjo pris historik kunne være rart, men kan ikke helt greje hvordan det skulle laves, ville man lave den i en helt ny tabel ?? eller udvide pris tabelen ?

så skulle der nok start og slut tid på i pris tabellen (eller måske i en
pris historik tabel)

ahh, ja start og slut tidspunkt, når man så skal finde nyeste søger man på dato :)

Tak for hjælpen.

læg et svar

jeg ville overveje den separate tabel - mange queries ville blive pænere på den måde

og svar