[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).