Rätt uppbyggnad?

Hej!

Har fått i uppgift att fixa iordning ett system för ett kundregister.
Jag har fått 2st tabeller i MSSQL.
För optimeringens skull undrar jag lite angående designen på dessa tabeller.

Såhär ser dom ut nu:
tblKund
ID
Fornamn
Efternamn
Fodelsedata
Gatuadress
Postnr
Postort
Telefonnr
Faxnr
Datum

tblKundExtra
KundID
E-post
Hemsida
Kon
Storlek
Betalsatt
------------------------------

Som det verkar nu så ligger data som ska vara direkt sökbar i tblKund (alla fält är indexerade).
Informationen som ligger i tblKundExtra visas endast om man väljer att "visa mer info" om kunden.
Kan även nämna att det _INTE_ finns någon relation inlagd, har det betydelse åt något håll?
Är detta rätt sätt att bygga upp det på eller kan jag göra på ett annat sätt som är bättre?
Eftersom registret innehåller ca500.000 poster så kanske det blir lite småsegt när jag ska göra utsökningarna mha ASP framöver.

mvh

Frågan är ju om du inte tjänar på att hämta all data direkt. Och sedan gömmer informationen på hemsidan med något javascript.
Eftersom du skrev något om asp

Du kan ju alltid slå ihop båda tabellerna och benämna fälten i tblKundExtra med prefixet e_fältnamnet. Jag tror att jag skulle ha använt en tabell för ändamålet. I stället för två SQL-frågor som körs kan du ju få ner det till en - men då plocka ut all info ur databasen. När användaren klickar på en länk för att se extrainfon så kan du fixat det så finurligt att extrainfon redan finns på sidan - men dolt. Ett javascript som exempelvis expanderar en div eller något annat kan vara bra att ha.

Återstår att se vad andra skulle ha gjort. :)

Jag skulle använda en tabell för att lagra informationen. Annars måste du göra en JOIN när du ska hämta ut datat och då tycker jag att det är berättigat med att lagra en och annan tom post istället för att tappa i prestanda.

red.
Sedan räcker det ju om du indexerar dom fält du sorterar och söker på.

Du bör göra en uppskattning av hur många av dom halvmiljon kunderna som har extra info. Jag tycker nog att du skall ha minst två tabeller. Index på nyckelbegreppet gör ju att den posten kommer direkt.
Dessutom har ju användaren begärt den och accepterar den 0,3 sek som kanske blir följden.
Ta hellre bort några index på den första tabellen.

OK, nu har jag fått lite information :)
Jag tror att man ska ha två tabeller, eftersom (som Lasp påpekade) alla kunder har inte extrainfo (=tomma fält).
Alla fält i tblKund är som sagt indexerade.
Dom fälten _KAN_ ingå i en SQL-fråga (beroende på vad användaren väljer att söka på) _MEN_ jag sorterar alltid efter efternamn.
Det är altså fel?

Använder du inte fältet för sortering eller sökning är det onödigt att indexera det (om det inte är/ingår i ett nyckelfält).
Bäst jag lägger in en reservation här mot eventuell bristande kunskap...

Du kan ju förstås skapa en databas med tre tabeller, som får motsvara dom två olika scenariona och sedan göra lite prestandamätningar med dom. (Om du orkar, så är det ett bra sätt att få svart på vitt vad som fungerar bäst för just dig... ;))

Om det är ett kundregister så kanske du skall funderar på hur man hanterar flerar olika adresser för samma person.

Om det nu skulle vara så att det är för någon butik (verkar så eftersom du har med Betalsatt) så kan det ju vara så att man har en faktura adress och en leveransadress. Det bör din kundregister hantera.

Det gör sökningen på adress fält långsammare men du får istället ett mer flexibelt system.

Lika så brukar man lägga ut PostOrt i en separat tabell och endast lagara PostOrtId på Adresstabellen. Allt enligt normaliseringstabellen.

Mycket av normaliseringsreglerna är dock mer för att spara uttrymme än av prestandaskäl, och eftersom Hårdisk är billigt idag, så kan man bryta ganska friskt mot normaliseringsreglen på saker som man vet att man inte kommer ändra struktur på, typiskt just PostOrt. Man kan dock ha en tabell med alla PostOrter så man får dessa i en dropdownlista, men istället för att spara idet, så spara man texten. Det strider mot normaliseringen, tar mer uttrymme på hårddisken, men KAN ge en liten prestandförbättring. Det kan göra det långsammare också, så man måste testa och se.

- Magnus

Hehe, man kan bryta ut det där rätt ordentligt.

En tabell med postorter. Han kan ju ha flera olika postorter
En tabell med postnummer som har en postort.
En tabell med e-post adresser. (En person kan ju ha flera st)
En tabell med telefon nummer.
En med fax-nummer
Och en med betal sätt (Han kanske vill betala på olika sätt).

Så skall det ju vara om man skall normalisera korrekt.. (Jag kanske missat något).

Men sedan får man ju se till vad kunden vill eller ja han som skall ha databasen. Vill han att en person skall kunna ha 2 adresser ?? osv.

Och precis som Gladh skriver så får man överväga fall till fall när det gäller normalisering. Ibland eller rättare sagt ganska ofta så får man faktiskt bättre eller inte nämnvärt sämre prestanda än om man hade skitit i det. Mén strukturen blir lite klarare vid normalisering.

Men om man t.ex. skulle ha en databas som skall lagra vad en viss kund har köpt. (T.ex. ica kortet) så lagrar affären allt du har köpt.

I en tabell så finns kund-informationen. Namn,adress,tel (du antas antagligen bara ha en adress eller tel).

Sedan så skall du ha en lista där varan t.ex. dåvarande pris, hur många osv. Samt datum.

Här är det absolut INTE smart att bara ha en tabell för du ökar du datan med säkert 200% minst. Samt att en stor fet tabell är slöare att söka i en ett par små.

Så kort och gott

Här skall man ju ha minst

3 tabeller

KundInfo
K_Id
Namn
Efternamn
Adress
tel
osv osv

Kundharkopt
K_Id
P_Id
Datum
Dåvarandepris
hurmånga

Produkter
P_Id
P_Name

Man hade ju iof kunnat ha en tabell med pris info och när produkten kostade så mycket eller mellan vilka perioder
Så hade man sluppit att dåvarande pris upprepas ett par ggr.

ProductPrices
P_Id
Date
Cost

Detta hade varit det mest ultimata i både prestanda och plats anser jag än om man kört ihop allt i en tabell.
Samt att det är lite lättare att arbeta med.