[aelander]

Jag har två tabeller

---------------------------------------
En produkttabell TabellA (i verkligheten avsevärt många fler kolumner)

select * from TabellA
+----+-------+
| Id | Namn  |
+----+-------+
|  1 | Saab  |
|  2 | Volvo |
|  3 | Audi  |
|  4 | Lexus |
+----+-------+

och en TabellB med priser

select * from TabellB
+----+-----+------+------------+
| Id | PId | Pris | Datum      |
+----+-----+------+------------+
|  1 |   1 |  500 | 2011-12-21 |
|  2 |   2 |  600 | 2011-12-21 |
|  3 |   3 | 1000 | 2011-12-07 |
|  4 |   3 | 1800 | 2011-12-13 |
|  5 |   3 | 1500 | 2011-12-18 |
|  6 |   4 |  320 | 0201-12-01 |
+----+-----+------+------------+

Priserna förändras över tid och jag vill spara all historik.
Här kan vi se att priset på produkt ändrats tre gånger i dec

select PId,Namn,Pris,Datum from TabellA
left join TabellB on TabellB.PId = TabellA.Id
+------+-------+------+------------+
| PId  | Namn  | Pris | Datum      |
+------+-------+------+------------+
|    1 | Saab  |  500 | 2011-12-21 |
|    2 | Volvo |  600 | 2011-12-21 |
|    3 | Audi  | 1000 | 2011-12-07 |
|    3 | Audi  | 1800 | 2011-12-13 |
|    3 | Audi  | 1500 | 2011-12-18 |
|    4 | Lexus |  320 | 0201-12-01 |
+------+-------+------+------------+

select PId,Namn,Pris,Datum from TabellA left
join TabellB on TabellB.PId = TabellA.Id
group by PId;
+------+-------+------+------------+
| PId  | Namn  | Pris | Datum      |
+------+-------+------+------------+
|    1 | Saab  |  500 | 2011-12-21 |
|    2 | Volvo |  600 | 2011-12-21 |
|    3 | Audi  | 1000 | 2011-12-07 |
|    4 | Lexus |  320 | 0201-12-01 |
+------+-------+------+------------+

Vad skriver jag för att det alltid ska välja senast pris? Alltså ett sånt här resultat.

+------+-------+------+------------+
| PId  | Namn  | Pris | Datum      |
+------+-------+------+------------+
|    1 | Saab  |  500 | 2011-12-21 |
|    2 | Volvo |  600 | 2011-12-21 |
|    3 | Audi  | 1500 | 2011-12-18 | <-- detta
|    4 | Lexus |  320 | 0201-12-01 |
+------+-------+------+------------+

[aelander]

Får ju problem redan här:

select * from TabellB;
+----+-----+------+------------+
| Id | PId | Pris | Datum      |
+----+-----+------+------------+
|  1 |   1 |  500 | 2011-12-21 |
|  2 |   2 |  600 | 2011-12-21 |
|  3 |   3 | 1000 | 2011-12-07 |
|  4 |   3 | 1800 | 2011-12-13 |
|  5 |   3 | 1500 | 2011-12-18 |
|  6 |   4 |  320 | 2011-12-01 |
+----+-----+------+------------+

mysql> select * from TabellB group by PId;
+----+-----+------+------------+
| Id | PId | Pris | Datum      |
+----+-----+------+------------+
|  1 |   1 |  500 | 2011-12-21 |
|  2 |   2 |  600 | 2011-12-21 |
|  3 |   3 | 1000 | 2011-12-07 |
|  6 |   4 |  320 | 2011-12-01 |
+----+-----+------+------------+

Vill att den ska välja det senaste priset för en PId

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

[Kekke]

Något sånt här borde fungera:

SELECT TabellA.*, MAX(TabellB.datum), TabellB.pris from TabellA INNER JOIN TabellB on TabellB.PId = TabellA.id GROUP BY TabellA.id

[Conny Westh]

Här är ett enkelt sätt att göra det på, så du enbart får senaste priset:

SELECT *
FROM ProduktPris pp1
WHERE pp1.PrisDatum = 
(
	SELECT DISTINCT Max(pp2.prisdatum) 
             FROM ProduktPris pp2
             WHERE pp2.Artikelnummer=pp1.Artikelnummer
)

Här är ett annat enkelt sätt att göra ungefär samma sak fast med produkttabellen med, så man set produkten i klartext:

SELECT p.Artikelnummer, p.ProduktNamn, 
( 
    SELECT MAX(pp.Pris) 
    FROM ProduktPris pp 
    WHERE pp.Artikelnummer=p.Artikelnummer) AS Pris
FROM Produkt p

[Conny Westh]

Dålig färändring i Forumet att man inte kan redigera egna inlägg mer än 15 minuter efter första spara!

Jag körde SQL-server men det borde vara närmast identisk SQL-kod.

Jag hade följande tabeller i mitt exempel:

CREATE TABLE [dbo].[produkt]
(
	[Artikelnummer] [nvarchar](50) NOT NULL,
	[ProduktNamn] [nvarchar](50) NOT NULL
);


CREATE TABLE [dbo].[ProduktPris]
(
	[PrisID] [int] IDENTITY(1,1) NOT NULL,
	[Artikelnummer] [nvarchar](50) NOT NULL,
	[pris] [money] NOT NULL,
	[prisdatum] [datetime] NOT NULL
);

ALTER TABLE [dbo].[ProduktPris] 
ADD  CONSTRAINT [DF_ProduktPris_prisdatum]  
DEFAULT (getdate()) FOR [prisdatum];

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

[Conny Westh]

Gör man om det hela till StoredProcedures så blir det lite snabbare och enklare att hantera (man kan då ange valfritt datum när man vill veta aktuell prislista, vilket gör att man kan hantera framtida prisförändringar):

CREATE PROCEDURE [dbo].[SenasteProduktPrisAlt1]
	-- Add the parameters for the stored procedure here
	@Datum datetime = GetDate
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;

	--declare @datum datetime
	--set @datum = GETDATE()
	SELECT     PrisID, Artikelnummer, pris, prisdatum
	FROM         dbo.ProduktPris AS pp1
	WHERE     PrisDatum <= @Datum 
	AND 
	(
		prisdatum =
		(
			SELECT DISTINCT MAX(prisdatum) AS prisdatum
			FROM          dbo.ProduktPris AS pp2
			WHERE      (Artikelnummer = pp1.Artikelnummer)
		)
	)
END
GO

-- Tester
declare @datum datetime
set @datum = GETDATE()
exec [dbo].[SenasteProduktPrisAlt1] @datum;

exec [dbo].[SenasteProduktPrisAlt1] '2011-12-15 23:59:59';
exec [dbo].[SenasteProduktPrisAlt1] '2011-12-18';
exec [dbo].[SenasteProduktPrisAlt1] '2011-12-18 23:59:59';
exec [dbo].[SenasteProduktPrisAlt1] '2011-12-21 23:59:59';
exec [dbo].[SenasteProduktPrisAlt1] '2011-12-24 23:59:59';

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