WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   Databasnormalisering av datum? (https://www.wn.se/forum/showthread.php?t=24521)

Weaver 2007-10-23 23:03

Nej, normalisera inte datum. Använd datatyperna timestamp, date, time eller datetime beroende på dina behov.

Ett undantag dock. Om detta datumet skulle ändras väldigt ofta så kan du få bättre performance genom att normalisera. Ett exempel (som dock inte är datumbaserat) hade kunnat vara en räknare för hur många gånger en sida har visats. I databastabellen lagrar du content för sidan samt hur många gånger den visats. I detta fallet hade du tjänat performance genom att bryta ut räknar INTen till en egen tabell för att inte förstöra query cachen varje gång en ny sidvisning sker.

Weaver 2007-10-23 23:12

Citat:

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…
Vyer ger ingen prestandavinst men å andra sidan har de bara ett väldigt litet overhead. Dock är det väldigt lätt att skapa sig prestandaförluster med dem om man inte har tungan rätt i mun [1].

Procedurer kan generellt ge ganska stor prestandavinst men det existerar inte några bra verktyg för att debugga dem så de är en mardröm att arbeta med när man kommer upp i komplexitet.

[1] http://www.mysqlperformanceblog.com/...-troublemaker/

Robert 2007-10-28 10:42

Citat:

Ursprungligen postat av martine
Citat:

Ursprungligen postat av 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.

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…

[..klipp..]

"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.

Jag ser inte vilken databas det är frågan om, men iaf i MS SQLServer så lär sig query execution enginen vad en SP gör och optimerar därefter sin sökning. Därför är det dåligt att köra inline sql mot en databas -eller- dynamisk sql i en SP. Sedan så tycker jag det är bättre ur en arkitekturell synvinkel att använda sig av SP's.

Jag skulle säga att normalisering(läs Övernormalisering) inte ligger i samma vågskål som Prestanda. Ökar du det ena så minskar du det andra. Man kan fundera på att tom aggregera information om det visar sig att (vilket ofta är sant) det skrivs kanske 1 gång per 1000 läsningar (eller mer), vilket betyder att man gör de tidskrävande sakerna vid skrivning och optimerar via aggregering för de andra 1000 tillfällena. Exempel på detta kan tex vara räknare för foruminlägg som updateras vid skrivning och inte räknas ut vid läsning etc.

fors 2007-10-28 10:51

Citat:

Originally posted by Weaver@Oct 23 2007, 22:03
Nej, normalisera inte datum. Använd datatyperna timestamp, date, time eller datetime beroende på dina behov.

Ett undantag dock. Om detta datumet skulle ändras väldigt ofta så kan du få bättre performance genom att normalisera. Ett exempel (som dock inte är datumbaserat) hade kunnat vara en räknare för hur många gånger en sida har visats. I databastabellen lagrar du content för sidan samt hur många gånger den visats. I detta fallet hade du tjänat performance genom att bryta ut räknar INTen till en egen tabell för att inte förstöra query cachen varje gång en ny sidvisning sker.

Det senare kan man ju dock lösa genom att cachelagra det i minnet istället. Så slipper förändra databasdesignen.

Weaver 2007-10-28 17:02

Citat:

Ursprungligen postat av fors
Citat:

Ursprungligen postat av Weaver
Nej, normalisera inte datum. Använd datatyperna timestamp, date, time eller datetime beroende på dina behov.
Ett undantag dock. Om detta datumet skulle ändras väldigt ofta så kan du få bättre performance genom att normalisera. Ett exempel (som dock inte är datumbaserat) hade kunnat vara en räknare för hur många gånger en sida har visats. I databastabellen lagrar du content för sidan samt hur många gånger den visats. I detta fallet hade du tjänat performance genom att bryta ut räknar INTen till en egen tabell för att inte förstöra query cachen varje gång en ny sidvisning sker.

Det senare kan man ju dock lösa genom att cachelagra det i minnet istället. Så slipper förändra databasdesignen.

Det kan du väl inte alls, detta värdet måste ju skrivas till databasen vid varje pageview. En cache kan ju bara hjälpa dig om du har mycket läsningar.

fors 2007-10-28 18:24

Citat:

Ursprungligen postat av Weaver
Citat:

Ursprungligen postat av fors
Det senare kan man ju dock lösa genom att cachelagra det i minnet istället. Så slipper förändra databasdesignen.


Det kan du väl inte alls, detta värdet måste ju skrivas till databasen vid varje pageview. En cache kan ju bara hjälpa dig om du har mycket läsningar.

Alltså om man cachelagrar sidinnehållet i minnet och uppdaterar tabellen som vanligt. Dvs, man använder inte query-cachen. Det får ju ungefär samma resultat som din lösning.

Weaver 2007-10-28 18:46

Citat:

Originally posted by fors@Oct 28 2007, 19:24
Alltså om man cachelagrar sidinnehållet i minnet och uppdaterar tabellen som vanligt. Dvs, man använder inte query-cachen. Det får ju ungefär samma resultat som din lösning.
Nu har detta blivit lite off-topic. Detta kommer inte att fungera om du visar antalet visningar av sidan på själva sidan.


Alla tider är GMT +2. Klockan är nu 11:02.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson