[Frej]

Normaliserar ni era datum?

Med en smalint (2 byte) kan man ju då få ~275 år.
Istället för en smaldatetime (4 byte) med 179 år.

Eller vad rekomenderar ni, håller på att sätta upp en databas
med normalisering i alla led, och började fundera lite över datum.

[hnn]

DATE typen
eller TIMESTAMP

[martine]

Originally posted by Frej@Oct 22 2007, 13:53
Eller vad rekomenderar ni, håller på att sätta upp en databas
med normalisering i alla led, och började fundera lite över datum.

Det effektivaste är säkerligen att använda de inbyggda typerna (DATE etc) särskilt om man behöver göra sökningar på datum.

Skulle själv aldrig använda något annat än DATE eftersom det krånglar till hämtningar (SELECT) från databasen när man inte kan jämföra och hämta datum utan vidare (t.ex. med BETWEEN).

[Frej]

Martine: Självklart kan man hämta och använda sig av Between även om man normaliserar data, man använder vyer för att skapa "tabeller" för att hämta datat man vill hantera. Förövrigt är det inte "best practice" att använda SELECT, INSERT, UPDATE eller DELETE direkt mot tabeller. SELECT skall köras mot Vyer och UPDATE, INSERT och DELETE skall köras mot lagrade procedurer.

Det jag undrar över är om man skall ha en tabell med en smalint (Identity) kolumn och en smaldatetime kolumn.
Sedan i övriga tabeller så refererar man till smalint värdet för att få tag i rätt datum. på detta vis så sparar man 2 byte för varje datum där det finns 3 eller fler av samma datum. Dock förlorar man 2 byte om datumet vara används en gång och blir ingen skillnad vid dubletter.

Hmm...
Jag har ju nästan svarat på detta själv. Alltså beror det på hur mycket samma datum kommer användas i min databas.

Jag undrar ändå, om någon annan normaliserar datum?

[oller]

Nej. Skulle tippa att det är rätt så sällsynt.

Mvh

[SimonP]

Du kan tjäna några bytes men samtidigt ökar ju CPU belastningen lite eftersom det krävs extra anrop enbart för att lagra och hämta datum.

[Frej]

SimonP: Lagringen kan jag hålla med om att det krävs ett extra anrop att få fram om Datumet redan existerar och returnera IDt eller om man skall skapa en ny rad för valt datum.

Men att det skulle ta mer CPU kraft att endast hämta datum vet jag inte. Då man kan fylla varje data page med fler rader så krävs färre läsningar av HDD huvudet vilket i sin tur medför bättre I/O prestanda. Och det är till 99.9% (ej fakta) HDD som begränsar I/O prestandand och inte CPUn.

[SimonP]

Originally posted by Frej@Oct 23 2007, 09:56
Men att det skulle ta mer CPU kraft att endast hämta datum vet jag inte. Då man kan fylla varje data page med fler rader så krävs färre läsningar av HDD huvudet vilket i sin tur medför bättre I/O prestanda. Och det är till 99.9% (ej fakta) HDD som begränsar I/O prestandand och inte CPUn.

Självklart tar det lite CPU, alla förfrågningar tar CPU, och ligger resultatet efter en SELECT fråga inte i cacheminnet ökar även I/O från hdd, precis som du skriver. Men cacheminnet gör att I/O-prestandan från HDD inte behöver vara avgörande jämt, ju mer RAM-minne ju mindre HDD I/O.

[Robert]

Personligen skulle jag inte försöka mig på normalisering på den här nivån. Det finns anledningar till att man tex inte bryter ut egennamn i separata tabeller, och datum.... tja, för att spara några bytes? Disk är billigt, en JOIN är dyr!

Det är lika dåligt att övernormalisera en databas som att inte alls normalisera. Mera aggregeringar till folket!

[edit: stavfel]

[martine]

Originally posted by Frej@Oct 22 2007, 15:14
Martine: Självklart kan man hämta och använda sig av Between även om man normaliserar data, man använder vyer för att skapa "tabeller" för att hämta datat man vill hantera. Förövrigt är det inte "best practice" att använda SELECT, INSERT, UPDATE eller DELETE direkt mot tabeller. SELECT skall köras mot Vyer och UPDATE, INSERT och DELETE skall köras mot lagrade procedurer.

Nu är det möjligt att du är mycket bättre insatt i databaser men ger det verkligen alltid en prestandavinst att använda vyer och procedurer? Det är ju trots allt en omväg till informationen…

Den stora vinsten ligger väl antagligen i att använda rader av fast bredd och inte om det kostar 2 eller 3 bytes. För framtidssäkring känns det trots all säkrare att satsa på "enkla" lösningar och låta databasen sköta optimeringen. Det kan mycket väl hända att lyfta 4 bytes data från en tabell går snabbare än 2 bytes om du har en processor som kör med 64 bitar, med 2 bytes måste den då maska ut 32 bitar och skicka dem separat, medans 4 bytes kan skickas löpande.

"Supernormalisering" betyder ju inte alltid prestandavinst och för min del tycker jag frågan också är om man inte gör saker krånligare än vad är nödvändigt i optimeringssyfte.