Databasuppbyggning 5-skikts - 3skikts

[Johan Knape]

Har ett par frågor om något som jag kan EXTREMT

lite om.

 

Jag hörde för något tag sedan en kille snacka om

att skall man bygga en databas så skall man göra

det på det sättet att du lägger in alla data i olika

tabeller och binder sedan samman dessa med 1

tabell där alla ID:n (index om jag förstått allt

rätt) i och du använder sedan denna tabellen för

att hämta all data o.s.v.

 

Jag skall alltså bygga en hemsida med en databas

där alla datalagras och hämtas.

 

Förut har jag allt byggt databasen så att jag

först räknar ut hur jag vill att sidan skall se

ut och hur den skall användas sedan lägger jag

in ID:n i de olika databaserna och de som skall

kopplas mot varandra så lägger jag i en extra

ID i den.

 

Alltså UserID får i dbUser och MessageID & UserID

i dbMessages så att jag kan hämta ut information

om både meddelandet och användaren på en sida.

 

Nu är frågan är det sättet som jag idag gör det

korrekt eller tänker jag fel och borde ha det ungefär

på följande sätt.

 

UserID i dbUser

MessageID i dbMessage

och sedan UserID & MessageID i dbWebMessages och

använda dbWebMessages för att hämta ut ägaren och

meddelandet.

 

Som jag förstod det skulle detta göra det mycket

enklare att sedan bygga ut databasen med flera

tabeller utan att behöva designa om hela tabellen

eller databasen.

 

Om någon förstår vad det är jag pratar om uppskattar

jag alla tips ni kan komma med och vad jag bör tänka

på eller om det finns någon riktigt bra bok eller

sida om just detta.

 

Tackar på förhand.

[Magnus Gladh]

Tja jag fattade nog inte så mycket av du skrev. Men den gyllene reglen när man bygger databaser är att man skall bryta ner datan i så små beståndsdelar som möjligt.

 

Ex. Skall du lagra en persons adress i databasen så skall du inte skapa en kolumn som du döper till Adress, utan dela upp den i 3 kolumner.

 

- PostAdress

- PostNummer

- PostOrt

 

En annan regel är undvik dubbellagring.

Ex: Om du har en tabell med resultat från en fotbollserie, så stoppar du inte data om:

 

- Antal vunna matcher

- Antal förlorade matcher

- Antal oavgjorad matcher.

 

om du har dessa så behöver du inte stoppa in antalet poäng som laget har inte heller hur många matcher laget har spelat eftersom det går att räkna ut med hjälp av dessa kolumner.

 

Sedan har vi relationer, använd dessa!!!!

Exempel är en databas över kunder.

Där vill man kanske lagra til vilket företag denna kund tillhör. Lägg då inte dessa kolumner hos kunden typ så här.

 

- KundNamn

- FöretagsNamn

- FöretagsAdress

- FöretagsTelefonnummer

 

Utan bygg en tabell för Kunden med data om kunden:

 

- KundID

- kundNamn

- FöretagsID

 

och en tabell om företaget:

 

- FöretagsID

- FöretagsNamn

- FöretagsAdress

 

Nu kan man med hjälp av företagsID koppla ihop kunden och företaget, dels så spara man utrymme (tänk om företaget har 10000 anställda) samt att det blir enklare om kunden byter företag.

 

Om man tilllämpar relationerna rätt så blir det enkelt att bygga ut din databas, för oftas är det bara att lägga till ett ID-nummer om du vill koppla ihop kunden med något annat, kanske en OrderTabel. Eller en tabell över meddelande. Då bygger man meddelande tabellen som man vill ha den, och lägger till en kolumn med kundID så vet man vilken kund som har gjort meddelandet.

 

Det finns massor att tänka på men en bra databasdesign är grunden för en snabb och utbyggbar website.

 

- Magnus

----------------------------------------

 

 

[Pontus Wång]

Du är ett typiskt exempel på folk som inte vet vad dom talar om annat än i teorin...

 

Normalisering (borttagande av dubbellagrad information) används fullt ut på en teoretisk databasmodell och inte i verkligheten, i alla fall inte på det sätt som du beskrev... Man kan iofs beräkna allt data i realtid på din fotbollstabell men man bör lagra resultatet också på grund av att annars kommer databasen vid många samtidiga förfrågningar gå på knäna av alla beräkningar som behövs utföras. Alla ni som har teoretiska kunskaper utan praktisk erfarenhet av större system borde i alla fall ta upp att situationen styrs av hur intensivt datat kommer att användas.

Sedan har jag aldrig förstått poängen med att normalisera bort all dubbellagring i en databas till förmån för komplexa beräkningar av en annan anledning heller, nämligen utrymme... Hårddisk är billigt idag och en stor databas i de världar jag kommer från är mellan en halv till två gigabyte stora vilket omfattar information om ca en miljon kunder. Om man låtsas att en sån databas är totalt denormaliserad och låter den fördubblas i volym så får den ändå plats på samma hårddisk (som kanske kostar 3-4 tusen) så ur den aspekten är denormalisering inte heller speciellt farlig.

 

 

We sent a man to the moon with a computer that had the power of a C64 more than fifty years ago, today we are booting windows with computers that are a 1000 times faster! Are we making progress???

 

[Coleburn]

Du glömde nämna den största risken med dubbellagring (mao argument FÖR normalisering), nämligen inkongruent data. Risken med dubbellagring är ju att man missar att uppdatera på alla ställen, och därigenom kan få felaktiga resultat, som blir _väldigt_ svåra att upptäcka. Istället för att dubbellagra så använd views (logiska tabeller i AS400) för att snabbare läsa ut sammansatt data.

 

 

==Coleburn==

 

--------------------

"It takes a lot of knowledge to

really mess something up!"

 

[Tomas Nilsson]

Jag håller inte alls med dig Trash1 (däremot håller jag med Magnus).

 

Att normalisera fullt ut är något man bör efterstäva i alla applikationer. Denormalisering kan man använda för *cache*, men inget annat. Data bör absolut lagras normaliserat. Undantaget är OLAP där mycket går ut på att denormalisera informationen.

 

Det finns ingen direkt anledning till att spara hårddiskplats idag, det kan jag hålla med om. Men att använda det som argument för att denormalisera, då är du ute på hal is.

 

Denormalisering kan dessutom ge *sämre* prestanda! Varför? Säj att du ska beräkna information som normaliserad går in på 64kb på disken. Det krävs i en MSSQL2k-baserad miljö en enda read-operation för att läsa in dessa data, sedan får CPU:n jobba med att summera informationen.

 

Om du istället denormaliserar får du kanske 512kb data, information som kräver 8 inläsningar innan den kan bearbetas. Och frågar du mig vilket som är snabbast, en inläsning+CPU eller eller åtta st+CPU så vinner ju den första förmodligen överlägset. Du måste ju räkna med söktider, om informationen är fragmenterad, rotationshastigheten på disken, om du får indexträffar i SQL Servern, om du får covered reads osv..osv..

 

Ps. När du har ett par hundra, eller ännu hellre kanske 1000 tabeller är du otroligt glad om informationen bara lagras på ett ställe..

 

/Tomas

 

 

[Pontus Wång]

Ja du har rätt i att dubbellagring innebär vissa problem vad det gäller uppdatering av data men att det skulle gå lika fort genom att använda vyer betvivlar jag.. och i SQL-Server och Oracle vet jag att det inte går lika fort, databasen cachar nämligen bara vyresultaten tills det att en ny insert/update sker och sedan måste den räkna om nästa förfrågan...

 

[Pontus Wång]

Jag använde inte utrymme som argument för att denormalisera utan snarare för att döda argumenten som säger att man denormaliserar för att spara utrymmen.

 

Javisst kan denormalisering ge sämre prestanda, framför allt om man har tunga beräkningar att utföra, detta problem löser de flesta plus problemet med att sql-server bara hämtar 64kb data per read löser de många av de som jag har sett genom att ha parallella databaser där den ena är normaliserad och den bara har ett speglat innehåll av den ickenormaliserade. Den lösningen påverkar iofs skrivprestandan då alla skrivningar som sker kör igång en trigger som uppdaterar den normaliserade databasen. Fördelen med den typen av lösningar är att man kan ha flera klustrade index per tabell samt ha specialiserade databaser (en för stora körningar och en för normalt arbete).

 

Samtidigt håller jag med dig om att när man har några hundra tabeller (eller fler) att jobba mot så är normaliserade databaser mycket trevligare att jobba mot.

 

 

[Tomas Nilsson]

njae.. Du gjorde ju en reply på Magnus inlägg, och där finns det inga argument för att spara hårddiskplats. Hela ditt första stycke gick ju ut på att " folk som inte vet vad dom talar om annat än i teorin...".

 

Men men, du är välkommen att byta ståndpunkt.

 

Ja, det finns en klar fördel att dubbellagra information för att man ska få klustrade index. Men det är en helt annan historia, då gör du det för att få upp prestanda. Du har en normaliserad databas i botten, där samma information lagras en gång till i en annan tabell.

 

Att ha en denormaliserad databas innebär ju att lagra t ex namnet på en person, om och om igen, istället för att utnyttja kundnummerrelationen.

 

/Tomas

 

 

[Johan Knape]

Lite kan jag om databaser och jobbar

på det sättet som du beskrev innan.

 

Men som du skrev om KundID,kundNamn, företagsID

 

Och företagsID, företagsNamn,företagsAdress.

 

Så bygger jag idag och genom detta kan

jag sedan hämta informationen från kundID och företagsID i samma fråga och

lägga ut detta på hemsidan.

 

MEN det jag har fått höra är att du inte

skall ha företagsID i kundtabellen utan

varje tabell har bara 1 index och

sen har du en extra tabell där du lägger

alla index för den typen av sida du vill ha.

 

Så vill jag t.ex ha en sida som visar

kunder med deras företag så gör jag

en tabell som innehåller enbart KundID

och FöretagsID och hämtar informationen

från respektive tabell.

 

Frågan är om jag har förstått detta rätt

och om någon vet om detta är korrekt

sätt att jobba med databaser eller om

killen som sa detta till mig inte har en aning vad han snackar om.

 

Hoppas du förstod bättre vad jag försökte

säga nu.

 

/Johan

om vad han babblar

 

[Magnus Gladh]

Du är ett typiskt exempel på folk som inte vet vad dom talar om annat än i teorin...

 

Rätt kaxigt inlägg av dig när du inte har en anning om vad jag sysslar med!

 

Men visst jag kunde ha skrivet att det ibland kan var bra att dubbellagra information, men då får man ta upp alla nackdelar med.

 

Och exemplet på fotbollstabellen så usch vad komplex den beräkningen var!! Det var ett exempel.

 

Meningen var inte att beskriv i detalj hur man bygger upp en databas och optimerar den ut i minsta detalj, utan att ge en enkel bild hur man bygger en databas.

 

Du kanske skall skaffa dig lite mer info innan hoppar på folk!

 

- Magnus

----------------------------------------

 

 

[inlägget ändrat 2002-01-20 20:04:52 av Magnus Gladh]

[Pontus Wång]

Ursäkta, jag var inte på det bästa humöret den dan då jag setat och modellerat en databas med just såna människor...

 

Det var inte menat som ett påhopp och som du säger, ditt exempel var iofs ett bra exempel på när man inte behöver dubbellagra..

 

Men min åsikt står kvar: Folk tenderar att lägga aldeles för mycket tid på normalisering i det stadiet när databasen skall optimeras. Och jag anser det som mycket farligt att inte ta hänsyn till problemen det kan ställa till med..

 

[Thomas Tydal]

Om du har företagsID i kundtabellen så innebär det att varje kund bara kan vara associerad med ett företag. Däremot kan ju ett företag vara associerat med flera kunder. Men skulle det vara så att en kund ska associeras med flera företag =och= ett företag ska associeras med flera kunder, då får du ha kundID och företagsID i en separat tabell för att uppnå det.

 

/Thomas - som för säkerhets skull (eftersom han inte har någon asbestkostym) påpekar att han leker med databaser på hobbynivå.

 

[Magnus Ahlkvist]

Fel i fallet SQL Server, den lagrar inte resultatet. Det enda en vy består av är en SELECT-sats. Skapar man däremot index på vyn materialiseras den, och blir mångdubbelt snabbare att söka i. Det medför också naturligtvis att det tar mångdubbelt längre tid att uppdatera vyn när data i underliggande tabeller ändras.

Men indexerade vyer är väl knappast vanligt för tabeller som ändras (som ex.vis matchresultat).

 

 

[Magnus Ahlkvist]

För att - till skillnad från de flesta andra inlägg - försöka besvara din fråga:

 

Jag ser ingen anledning till att bygga ett många-till-många-förhållande i det här fallet.

En användare kan skriva flera meddelanden.

Att bygga en databasmodell som har

User -> user_messages <- messages

skulle inte bara göra sökningar långsammare. Den är dessutom direkt felaktig, om inte flera användare kan "äga" samma meddelande.

 

mvh/Marwin