Vinnaren i pepparkakshustävlingen!
2007-10-05, 02:12
  #1
Medlem
Läser en exempelsida om en ebutik. Där har kundinfon delats upp i två tabeller, en med logininfo, och en annan med info som behövs om en beställning görs. Varför har dom gjort så?? För hastighets skull? Kunden behöver inte fylla i adress osv förrän han bestämt sig för en beställning, men skulle det skada att ha en tabell för all info och adress-fälten tomma? ... ... Känns som att jag är på väg att besvara min egen fråga. Dags att sova. Men om nån har nåt att tillägga eller om jag missat nåt så skriv gärna..

Kod:
CREATE TABLE customer (
  cust_id int(5) NOT NULL,
  surname varchar(50),
  firstname varchar(50),
  initial char(1),
  title_id int(3),
  address varchar(50),
  city varchar(50),
  state varchar(20),
  zipcode varchar(10),
  country_id int(4),
  phone varchar(15),
  birth_date char(10),
  PRIMARY KEY (cust_id)
) type=MyISAM;

CREATE TABLE users (
  cust_id int(5) NOT NULL,
  user_name varchar(50) NOT NULL,
  password varchar(32) NOT NULL,
  PRIMARY KEY (user_name),
  KEY password (password),
  KEY cust_id (cust_id)
) type=MyISAM;
Citera
2007-10-05, 02:40
  #2
Medlem
Kan det inte vara användare kopplade till företag som ligger i "andra" tabellen
Citera
2007-10-05, 02:51
  #3
Medlem
En användare behöver väl inte vara en kund? En användare kan ju dessutom som ovan skrivs vara t.ex tillskriven ett företag eller liknande där de har gemensama uppgifter
Dessutom är det onödigt att querya en tabell med en massa data om man bara är intresserad av att se om t.ex en inloggning har gått igenom.
Citera
2007-10-05, 08:59
  #4
Medlem
Antar att "users" bara fylls i om kunden ska kunna logga in via websidan? Man kan alltså manuellt lägga in beställningar från kunder utan att de har ett konto.
Sen kan man ha ett konto utan att ha fyllt i leveransadress, som du säger.

Själv hade jag klagat på:
  • Index på password-fältet i users-tabellen. WTF?
  • Foreign keys saknas.
  • MYISAM = inga transactions.
  • Ett konto kan bara ha en leveransadress.
  • Edit: Användandet av MySQL.
Osv...
Citera
2007-10-05, 13:41
  #5
Medlem
ErrolFlynns avatar
Jag kanske har missuppfattat något men är det inte så enkelt att de har normaliserat databasen? http://www.databasteknik.se/webbkursen/normalisering/?
Citera
2007-10-05, 19:09
  #6
Medlem
Citat:
Ursprungligen postat av ErrolFlynn
Jag kanske har missuppfattat något men är det inte så enkelt att de har normaliserat databasen?

[Disclaimer: Jag är helt självlärd på det här. Jag har inte läst din länk än, men är på väg.]
Mjo. Kanske. Normalisering handlar väl om att se till att data inte dupliceras, att man får en "ren" databas som möjligt? Jag kan inte fatta var risken för det är, om man slår ihop dom två tabellerna.
Citera
2007-10-05, 19:31
  #7
Medlem
ErrolFlynns avatar
Det har ju inte bara med duplicering att göra. Man lyfter bort onödiga fält som adress osv som inte behövs vid en inloggning. När man ändrar på ett ställe skall bara de värden som är kopplade till huvudnyckeln finnas i samma område. Kanske inte världens bästa förklaring, jag skyller på att det är fredag kväll
Citera
2007-10-06, 12:59
  #8
Medlem
Citat:
Ursprungligen postat av Koenigsegg
[Disclaimer: Jag är helt självlärd på det här. Jag har inte läst din länk än, men är på väg.]
Mjo. Kanske. Normalisering handlar väl om att se till att data inte dupliceras, att man får en "ren" databas som möjligt? Jag kan inte fatta var risken för det är, om man slår ihop dom två tabellerna.

Om databasen har en "kund" med tre användare, då kommer du få lägga in tre poster för den kunden (en post för varje användare). alla dessa poster får exakt samma kundnamn och då har du duplicerad data. Byter kunden namn så måste du ändra på mer än ett ställe vilket gör det mycket svårare och programmera mot databasen.

Varje post bör ha en egen primärnyckel med, exempelvis i det exemplet du givit så har en user ingen egen primärnyckel så det finns brister där. En primärnyckel för en post skall aldrig vara ett fält som används till något annat. Låt säga att du har kunder med organisationsnummer där ett organisationsnummer är unikt. du skulle du potentiellt kunna använda detta som primärnyckel med men det är korkat. En primärnyckel är just bara en primärnyckel och bör helst vara av samma typ för alla tabeller, då blir det mycket lättare att programmera mot databasen. Vanligen använder man heltal eller GUID's som primärnycklar.
Citera

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback