Utformningen av ProductPricing
tabell gör att vi aldrig behöver ta bort gamla prisuppgifter (ibland vill ledningen ha en rapport baserad på den informationen). Med det du har beskrivit ovan skulle du börja så här (jag ändrade startdatumet bara så att det är lätt att välja ut att ja, det här var det ursprungliga priset när systemet gick på plats):
ProductPricing
1 | Jan 1, 1970, 00:00:00 | Jan 1, 2038, 00:00:00 | 10$ | 10$
Låt oss nu säga att du ger ett rabatterat pris på dina äpplen och du ville vara proaktiv och ställa in systemet för när försäljningen var över:
ProductPricing
1 | Jan 1, 1970, 00:00:00 | Dec 20, 2011, 00:00:00 | 10$ | 10$
1 | Dec 20, 2011, 00:00:01 | Dec 26, 2011, 00:00:00 | 7.5$ | 10$
1 | Dec 26, 2011, 00:00:01 | Jan 1, 2038, 00:00:00 | 10$ | 10$
Det vi gjorde här var:
- Uppdatera den befintliga posten med 2038-tidsstämpeln, ändra
endDateTimeStamp
fältet för att återspegla början av försäljningen - Infoga en ny post för att definiera försäljningen
- Infoga en ny post för att återspegla det normala priset igen
Utan överlappande tidsstämplar, är du garanterad att få en enda post när du frågar databasen för ditt pris. Alltså
SELECT p.Name, pp.price, pp.original_price
FROM Product p
INNER JOIN ProductPricing pp ON pp.productId = p.productId
WHERE NOW() BETWEEN pp.startDateTimeStamp AND pp.endDateTimeStamp
skulle ge dig en produktlista med aktuella priser.