E-Shop / Varesystem

Jeg lavde en gang en webshop som eksamens projekt i programering og IT på HTX, den var vist nok lavede sådan her:

jeg havde lavet et system hvor alle varene havde en vare_id, navn, info, indkøbespris, udsalgspris og kategori.
en anden database som havde indkøbes kurv, den havde vare_id og session nummer (som var styreet  af PHP) jeg kan ikke huske om der også var en id på indkøbskurven.så var der en database med købte vare, der havde id, vare_id, navn, addresse og dato

tablerne var linket sammen sådan her:
vare_id i tablen vare til vare_id i indkøbskurv
vare_id i tablen vare til vare_id i solgt vare

svar

Ok.. Altså sådan set min idé 1?

Jeg synes ikke du har en DB med vargrupper? men det er måske lige meget?

Kan du ikke lige udspecifiere for dummies (ja mig;).. ?

Hvis du kan skrive

tabel 1: 
varegruppe

tabel 2:
kurv

så jeg lige kan se hvor mange tabeller du har.. ?

Der kunne godt laves med en varegrupper, men da alle vare har en vare gruppe, vil det nok ikke vare nogle vildt stor fordel, måske hvis der er VILDT mange vare, og tabellerne dermed bliver mindre, men jeg tror ikke det er nødvendig i langt de fleste tilfælde.

Jeg lavede 3 tabeller.

1
vare

2
kurv

3
solgtvare

Jeg havde forresten nogle flere felter i vare:
Et binær felt til foto
Et felt til at markere om vare var på udsalg, hvilket var en fordel, når forsiden skulle laves og slagtilbud vises.
Et felt med antal vare på lagere
Et felt med det antal vare, som betød at man skulle bestille flere hjem, en fordel, da ikke alle vare er nødvendig at havde ligemange hjemme af.

Hmm... Hvis du giver varene en varegruppe, vil du så bare skrive ex "brænder" og "cdrom" og ikke et nummer som referere til en anden tabel?

Hvad putter du i 3'eren?

er det når man har købt eller mens man handler?

Der var vist 4 tabeller.

3.
havde kunde infomationer:
kunde_id, fornavn, efternavn, addresse

4.
Havde de solgte vare, så de kunne sendes til køberen
vare_id, kunde_id, dato og vistnok også et id.

til vare der ER solgt

2. er en tmp table til mens man shopper

de er linket sådan:
vare_id i 4. til vare_id i 1.
kunde_id i 4. til kunde_id i 3.

grunden til 3 og 4 er splittet op er, at ikke alle køber lige mange vare og det vil være spild af plads, af alle slogt vare skulle indeholde alle informationerne om den der havde købt den

Jeg kan ikke huske om jeg lave brugernavn og password til 3. men det ville være en god ide!

Snakker vi så:

Tabel 1 - varer:
vare_id, navn, info, indkøbespris, udsalgspris og kategori, photo, udsalg, lagerantal.

Tabel 2 - kurv:
vare_id i 4. til vare_id i 1.
kunde_id i 4. til kunde_id i 3 (hvad så hvis man ikke er kunde endnu?)

Tabel 3 - User:
kunde_id, fornavn, efternavn, addresse m.m.

Tabel 4 - Ordre: (?)
vare_id, kunde_id, dato, id.

i tabel 1. er det også en god ide at have "bestil_antal" som kan bruges til at lave bestillings lister til leverandøren, da du jo gerne vil bestille nye vare hjem inden du løber tør, men ikke alle vare har den samme grænse, du vil jo nok ikke havde 100 50ports switche hjemme, men gerne 100 fx CD cover eller 50 5meters netværkskabler ;-)

i table 2.
vare_id og session nummer ikke kunde_id, da det ikke kommer i spil før kunde tjekker ud. Session nummeret styrede jeg via PHP sessions.

tabel 1. skal også havde leverandør

Til et af dine første spørgsmål. "Skal den jo tjekke hele db'en?":
En database indekserer dine data så den ikke skal løbe hele datasættet igennem for at finde en indgang. Derfor skal du ikke regne med at det tager ret lang tid at finde den indgang du søger. Slet ikke hvis du laver en søgning på en key. Database har en træstryktur til deres data.
Jeres layout virker fint nok men det skal dog lige overvejes om der er nogle data som er tilknyttet kategorien ud over navnet. Det kunne være en forklaring på kataegorien, en fragtpris for varer i kategorien. Hvis dette er tilfældet ville det være smartest at lave en tabel til kategorierne alene med disse data i men hvis dette ikke er tilfældet er det i foreslår det bedste.

Er jeg helt ude og sk***... ? :)
(se bort fra int og varchar, dem retter jeg senere)

CREATE TABLE shop_products (
  id varchar(32) NOT NULL default '',
  name varchar(128) NOT NULL,
  descript varchar(128) NOT NULL,
  in_price int(16) NOT NULL,
  out_price int(16) NOT NULL,
  group int(4) NOT NULL,
  photo binary( hvad skal der så stå her) NOT NULL,
  offer boolan( hvad skal der så stp her) NOT NULL,
  store int(16) NOT NULL,
  PRIMARY KEY (id)
  ) TYPE=MyISAM;


CREATE TABLE shop_basket (
  session_id varchar(32) NOT NULL default '',

er lidt lost her

  PRIMARY KEY (id)
  ) TYPE=MyISAM;


CREATE TABLE shop_customer (
  customer_id varchar(32) NOT NULL default '',
  f_name varchar(128) NOT NULL,
  l_name varchar(128) NOT NULL,
  address1 varchar(128) NOT NULL,
  address2 varchar(128) NOT NULL,
  zipcide int(4) NOT NULL,
  town varchar(128) NOT NULL,
  phone int(11) NOT NULL,
  cellphone int(11) NOT NULL,
  PRIMARY KEY (id)
  ) TYPE=MyISAM;


CREATE TABLE shop_orders (
  vare_id varchar(32) NOT NULL default '',
  customer_id varchar(128) NOT NULL,
  date int(12) NOT NULL,
  id int(12) NOT NULL,
  PRIMARY KEY (id)
  ) TYPE=MyISAM;

haestrup >> selvom databasen er indelseret og ikke alt skal løbes igennem, skal tabellen stadig inlæses, hvilket betyder at størrelse har betydning, men først når de bliver MEGET store.
alternativ til at lave kategorier ville være at lave et felt med vægt
og en anden med fragt priser for diveres vægtklasser

shadowsurfer >> I havde vel ikke tænkt jer at vise hele tabellen i jeres program hver gang i skal vise jeres varer? For så kan I lige så godt ligge dataen i XML filer.

du bruger for meget int, brug smallint og mediuminst istedet for, selv om du sætter længde på, fylder de mindre

haestrup >> Det er LANG tid siden jeg lavde det ;-)
Jeg vist kun kategorierne.
også dem der var tilbud på, på forsiden.

Jeg kender desvære ikke noget til XML, men database elsker som jeg er, kan jeg godt lig at bruge MySQL.... men det er nok ved at være på tide at lære XML ;-)

min pointe var at hvis man har noget data som hører til kategorien så skal man helst lave en kategori tabel for sig så man i fremtiden ikke skal ændre en masse steder men kun i denne tabel og kun ved den ene indgang som har den kategori. Det er simpelthen for at undgå redundans.

det er en god ide at kalde id i fx shop_products, product_id, da det lettet designet af SQL komandoerne!

Jeps.. hehe.. Jeg rettet tabeller bedre til bagefter.. Men der var lige nogle små ting som jeg ikke fattede helt... :)

Nogen der kan supplere? :)

din shopping basket skal jo have en liste af ID som er de varer som man vil købe. Det ville nok være bedste hvis du enten ligger den i en cookie eller ligger den på harddisken på din server. Det er nok lidt kluntet at ligge det i databasen.

Jah... men hvad skal jeg så puttet i den ?

Jeg tænkte at have tingene ligge i en session?

Hmm i table shop_products, photo..
ligge den så billede ind i mysql databasen eller laver den et dir til dem?

Du skal bare have en liste af par (antal,vare_id)

Ja.. men hvordan skal jeg styre det? hvis nu 2 shopper samtidig?

ud fra dit session id

Ok.. Men.. hmmm.. Så definiere en session_id og hvordan ved en så hvilken varer i kurven som hænger på hvilken session?

Jeg havde photone i databasen, det var lettet, men man kunne lige så godt skrive addressen på dem også ligge dem i et dir. smags sag, jeg vil gerne havde tingene samlet ;-) andre en lille hurtig database ;-)

tingene kunne sikket godt ligges i en session. det kunne jeg ikke finde ud af da jeg lavde den (og har sådan set ikke læst op på de siden).
min tabel 2 havde:
vare_id, session_id (lavet via php)

som sagt kan jeg godt lig at havde tingene samlet, men det er en smags sag, men det er måske smartere at ligge det hele i en sesssion!

Hver bruger får en session_id som han så gennem hele hans interaktion med dit site. Du gemmer altså en kurv for hver session_id. Så skal du selvfølgelig have noget med timeout sat op så dine sessions bliver slettet igen efter noget tid men det gør php vist for dig. Det er lang tid siden jeg har brugt php ;-)

Hvis PHP virker som andre scriptsprog så vil den forsøge at gemme session data i en cookie, URL encoded eller på disken på serveren. Når man så tilgår din side får man et session_id som følger en ved hver transaktion. Derfor ved PHP hvilke data der hører til hvilke sessions.

Hmm... Det må jeg vist spørger om når jeg kommer dertil...

Teoretisk kunne man jo også lave en shop_dealer hvori alle levenrandørene kunne ligge, og så skulle de på produktet bare have en dealer_id... ?

Ja men så kommer det egentlige problem. Forskellige leverandører har de samme produkter men hvordan afgør man om to produkter er ens hvis man ikke selv skal sidde og sige god for dem allesammen?

#
# Sådan som jeg (husker) lavde shop_basket på dennemåde
#
CREATE TABLE `shop_basket`(
`id` INT NOT NULL ,
`session_id` VARCHAR( 32 ) NOT NULL ,
`product_id` INT NOT NULL ,
PRIMARY KEY (id)
) TYPE=MyISAM;

#
# Sådan som jeg (husker) laved shop_products på dennemåde:
#
CREATE TABLE `shop_products` (
`product_id` INT NOT NULL ,
`name` VARCHAR( 15 ) NOT NULL ,
`descript` TEXT NOT NULL ,
`in_price` MEDIUMINT( 16 ) NOT NULL ,
`out_price` VARCHAR( 16 ) NOT NULL ,
`group` VARCHAR( 10 ) NOT NULL ,
`photo` BLOB NOT NULL ,
`sale` ENUM( 'Y', 'N' ) NOT NULL ,
`store` SMALLINT NOT NULL ,
PRIMARY KEY ( `product_id` )
)TYPE=MyISAM;

#
# Sådan som jeg (husker) laved shop_products på dennemåde:
#
CREATE TABLE `shop_products` (
`product_id` INT NOT NULL ,
`name` VARCHAR( 15 ) NOT NULL ,
`descript` TEXT NOT NULL ,
`in_price` MEDIUMINT( 16 ) NOT NULL ,
`out_price` VARCHAR( 16 ) NOT NULL ,
`group` VARCHAR( 10 ) NOT NULL ,
`photo` BLOB NOT NULL ,
`sale` ENUM( 'Y', 'N' ) NOT NULL ,
`store` SMALLINT NOT NULL ,
`ordermore` SMALLINT NOT NULL ,
`primary_dealer` VARCHAR( 10 ) NOT NULL ,
# Denne skal være smallint hvis du laver en dealer database
PRIMARY KEY ( `product_id` )
)TYPE=MyISAM;

`out_price` VARCHAR( 16 ) NOT NULL ,

skulle være
`out_price` MEDIUMINT( 16 ) NOT NULL ,

ok.. Der er lige en ID som jeg ikke lige hvad den laver...
Ser i nogle fejl så må i life sige til...

CREATE TABLE shop_products (
  product_id INT (16) NOT NULL ,
  name VARCHAR (15) NOT NULL ,
  descript TEXT NOT NULL ,
  in_price MEDIUMINT (16) NOT NULL ,
  out_price MEDIUMINT (16) NOT NULL ,
  group VARCHAR (10) NOT NULL ,
  photo BLOB NOT NULL ,
  sale ENUM ('Y','N') NOT NULL ,
  store SMALLINT NOT NULL ,
  ordermore SMALLINT NOT NULL ,
  primary_dealer SMALLINT (8) NOT NULL ,
  PRIMARY KEY (product_id)
  ) TYPE=MyISAM;

CREATE TABLE shop_basket(
  id INT NOT NULL ,
  session_id VARCHAR (32) NOT NULL ,
  product_id INT NOT NULL ,
  PRIMARY KEY (id)
  ) TYPE=MyISAM;

CREATE TABLE shop_orders (
  vare_id VARCHAR (32) NOT NULL default '',
  customer_id VARCHAR (128) NOT NULL,
  date INT (12) NOT NULL,
  id INT (12) NOT NULL, # Hvad er det for en ID??
  PRIMARY KEY (vare_id)
  ) TYPE=MyISAM;

CREATE TABLE shop_customer (
  customer_id VARCHAR (32) NOT NULL default '',
  f_name VARCHAR (128) NOT NULL,
  l_name VARCHAR (128) NOT NULL,
  address1 VARCHAR (128) NOT NULL,
  address2 VARCHAR (128) NOT NULL,
  zipcide INT (4) NOT NULL,
  town VARCHAR (128) NOT NULL,
  phone INT (11) NOT NULL,
  cellphone INT (11) NOT NULL,
  PRIMARY KEY (customer_id)
  ) TYPE=MyISAM;

CREATE TABLE shop_dealer (
  dealer_id SMALLINT (8) NOT NULL default '',
  f_name VARCHAR (128) NOT NULL,
  l_name VARCHAR (128) NOT NULL,
  address1 VARCHAR (128) NOT NULL,
  address2 VARCHAR (128) NOT NULL,
  zipcide INT (4) NOT NULL,
  town VARCHAR (128) NOT NULL,
  phone INT (11) NOT NULL,
  cellphone INT (11) NOT NULL,
  PRIMARY KEY (dealer_id)
  ) TYPE=MyISAM;

har rette
  customer_id VARCHAR (32) NOT NULL default '',
til
  customer_id INT (8) NOT NULL default '',

så lige at der også var en id i basket'en.. hvad er det for en?

Der var en id, for at hvade en uniq, i såfald ville den se sådan her ud:

CREATE TABLE shop_orders (
  vare_id VARCHAR (32) NOT NULL default '',
  customer_id VARCHAR (128) NOT NULL,
  date INT (12) NOT NULL,
  id INT (12) NOT NULL,
  PRIMARY KEY (id)
  ) TYPE=MyISAM;

Men det kan også godt laves, hvor allesammen til sammen er uniq:
CREATE TABLE shop_orders (
  vare_id VARCHAR (32) NOT NULL default '',
  customer_id VARCHAR (128) NOT NULL,
  date INT (12) NOT NULL,
  PRIMARY KEY ( `vare_id` , `customer_id` , `date` )
  ) TYPE=MyISAM;

så er din primary en kombination af alle sammen.
Den øvereste er nok den lettet og arbejde med, mens den nedereste er den smarteste

Ok.. Jeg nipnapper den første.. :)

En stor tak til dig og haestrup.. :)

og point til shadowsurfer også.. :)