[Monkboll]

Skulle jag varit dig hade jag haft en separat tabell för de nuvarande priserna. Varje gång du ändrar ett pris så körs en trigger som lägger till en post i en tabell som loggar priset.
Går säkert lösa på många sätt som sagt men så har jag gjort med andra typer av data som ska loggas.

[pelmered]

Ursprungligen postat av Monkboll

Skulle jag varit dig hade jag haft en separat tabell för de nuvarande priserna. Varje gång du ändrar ett pris så körs en trigger som lägger till en post i en tabell som loggar priset.
Går säkert lösa på många sätt som sagt men så har jag gjort med andra typer av data som ska loggas.

Håller med om att det där är den bästa lösningen om det inte finns några andra hinder.
Du skulle ju rentav kunna ha priset och senaste uppdateringsdatum direkt i produkttabellen och sedan ha en tabell med prishistorik. Då slipper du joins helt och får en snyggare(enligt mig) och mer effektiv(bättre prestanda om du slipper joina) tabellstruktur.

[Conny Westh]

Ursprungligen postat av ITisGood.se

Håller med om att det där är den bästa lösningen om det inte finns några andra hinder.
Du skulle ju rentav kunna ha priset och senaste uppdateringsdatum direkt i produkttabellen och sedan ha en tabell med prishistorik. Då slipper du joins helt och får en snyggare(enligt mig) och mer effektiv(bättre prestanda om du slipper joina) tabellstruktur.

Håller inte med om att det blir effektivare, då det blir en hiskeligt komplicerat förfarande så fort det ska till en prisförändring. Det är effektivare att bara lägga in en extra post i en pristabell och sedan med en smart sql-fråga ta fram senaset priset.

Om man ska ha en historiktabell så måste man varje gång man gör én prisförändring först läsa fram det gamla priset för att lagra det i en historiktabell och sen lägga in det nya priset i "den aktuella pristabellen" detta måste även göras med en transaktion så det går att backa om någon del inte går igenom. Med den enklare varianten så slipper man hantera transaktioner.

Vad vi pratar om för prestandaeffektivisering är endast frågan om millisekunder vid prisfrågan, det tycker i vart fall inte jag är värt den betydligt mer komplicerade strukturen som det lätt kan bli fel i, det är mindre risk att det blir fel om man bara lägger till en extra insert varje gång priset förändras.

Den mer komplexa lösningen kräver även mer "knowledgein the head" dvs kunskap hos den som administrerar databasen än den enklare lösnuingen där det är fokus på "Knowledge in the world" (dvs mer kunskap finns i databasen i sig själv).

[pelmered]

Ursprungligen postat av ConnyWesth

Håller inte med om att det blir effektivare, då det blir en hiskeligt komplicerat förfarande så fort det ska till en prisförändring. Det är effektivare att bara lägga in en extra post i en pristabell och sedan med en smart sql-fråga ta fram senaset priset.

Om man ska ha en historiktabell så måste man varje gång man gör én prisförändring först läsa fram det gamla priset för att lagra det i en historiktabell och sen lägga in det nya priset i "den aktuella pristabellen" detta måste även göras med en transaktion så det går att backa om någon del inte går igenom. Med den enklare varianten så slipper man hantera transaktioner.

Vad vi pratar om för prestandaeffektivisering är endast frågan om millisekunder vid prisfrågan, det tycker i vart fall inte jag är värt den betydligt mer komplicerade strukturen som det lätt kan bli fel i, det är mindre risk att det blir fel om man bara lägger till en extra insert varje gång priset förändras.

Den mer komplexa lösningen kräver även mer "knowledgein the head" dvs kunskap hos den som administrerar databasen än den enklare lösnuingen där det är fokus på "Knowledge in the world" (dvs mer kunskap finns i databasen i sig själv).

Mjo, där har du nog rätt när jag tänker efter ett varv till.

Är det väldigt mycket läsningar och få uppdateringar av priset(vilket borde vara normalfallet) blir det dock en viss prestandavinst med "min" lösning. I de flesta sammanhang är det nog inte så mycket att bry sig om dock. Resultatet kan ju även cachas om prestanda är viktigt.