Artikelpreis zu gegenem Datum

[Hansa]

Ich würde den Einsatz einer SP in Betracht ziehen, z.B. so :

SQL-Code:

ALTER PROCEDURE NETTOSP (
    BETRAG DECIMAL(15,2),
    MWSTSATZ SMALLINT,
    DATUM DATE)
RETURNS (
    GESNETTO DECIMAL(15,2))
AS
DECLARE VARIABLE MWSTPROZ DECIMAL(15,2);
BEGIN 
  SELECT FIRST 1 MWSTWERT FROM MWST WHERE
    (MWSTSATZ=:MWSTSATZ) AND (ABDATUM <= :DATUM)
  ORDER BY ABDATUM DESC INTO :MWSTPROZ;
  IF (MWSTPROZ IS NULL) THEN MWSTPROZ = 0;
/*  GESNETTO = CAST (BETRAG / (1 + MWSTPROZ / 100) AS DECIMAL (15,2)); */
  GESNETTO = BETRAG / (1 + MWSTPROZ / 100);
  SUSPEND;
END

Da gehts zwar um die Ermittlung der Mwst., aber das dürfte egal sein. Es ist halt datumsgesteuert. Ob Mickysoft-SQL allerdings so was hat wie SELECT FIRST ? :gruebel: In Firebird gibts das auch erst seit vorletzter Version.

[alzaimar]

Zitat:

Zitat von Hansa

...Ob Mickysoft-SQL allerdings so was hat wie SELECT FIRST ? :gruebel:

Mach Dir man keine Sorgen (SELECT TOP 1...), MSSQL ist um längen schneller, mächtiger, skalierbarer, robuster und besser als Firebird & Co. :mrgreen:

[Elvis]

Zitat:

Zitat von alzaimar

Mach Dir man keine Sorgen (SELECT TOP 1...), MSSQL ist um längen schneller, mächtiger, skalierbarer, robuster und besser als Firebird & Co. :mrgreen:

Wurde aber erst mit dem aktuellen 2005'er aus Sicht einer Oracle-verwöhnten Göre interesant. Alle Versionen vorher waren zumindest im Transaktionsmodell einfach peinlich. ;)
FB scheint sich mit jedem bisschen was sie von Interbase rausschmeißen zu verbessern. ;)

@Topic
Eine selectable Procedure wäre hier nun wirklich witzlos, auch wennn SQL ziemlich schnell ziemlich eklig wird, wenn es um Aggregationen geht. (hässlich ist es ja sowieso immer ;) )

Als Erbchleicher wäre wahrscheinlich eine Liste der Ids aller Preise ausreichend um bereits vorher geholte Instanzen der Preise wiederzufinden:

SQL-Code:

SELECT p.Id
FROM Artikel a
     INNER JOIN Preise p ON p.Artikel = a.ID
     INNER JOIN Preise filter ON p.Artikel = a.ID
WHERE filter.Datum <= @Suchdatum
GROUP BY p.Id, p.Datum
HAVING p.Datum = max(filter.Datum)

Als RADieschen braucht man mehr Spalten, wodurch die Gruppierung aufwendiger wäre als die SubQuery aus Dominiks Beispiel. (MSSQL hatte vor 2005 leider den Hang dazu, SubQueries gerne mal für jeden Datensatz zu neu abzufragen :? )

[Hansa]

Zitat:

Zitat von alzaimar

...keine Sorgen (SELECT TOP 1...), MSSQL ist um längen schneller, mächtiger, skalierbarer, robuster und besser als Firebird & Co. :mrgreen:

Wenn First/Top dasselbe macht, dann ists ja auch gut so. Mickysoft-SQL war letztlich für den Einsatzweck immerhin 2. Wahl. Wegen mangelnder Skalierbarkeit, geringerem Sprachumfang, schlechterer Transaktionssteuerung usw. :mrgreen:

[alzaimar]

Zitat:

Zitat von Hansa

...war letztlich für den Einsatzweck immerhin 2. Wahl. Wegen mangelnder Skalierbarkeit, geringerem Sprachumfang, schlechterer Transaktionssteuerung usw. ...

So so.

[Jelly]

Zitat:

Zitat von Elvis

Als Erbchleicher wäre wahrscheinlich eine Liste der Ids aller Preise ausreichend um bereits vorher geholte Instanzen der Preise wiederzufinden:

SQL-Code:

SELECT p.Id
FROM Artikel a
     INNER JOIN Preise p ON p.Artikel = a.ID
     INNER JOIN Preise filter ON p.Artikel = a.ID
WHERE filter.Datum <= @Suchdatum
GROUP BY p.Id, p.Datum
HAVING p.Datum = max(filter.Datum)

So in der Art hab ich da jetzt auch gelöst, nur anders :zwinker:

Ich hab mir als Erstes eine temporäre View erstellt:

SQL-Code:

create view vwPreiseHeuteTemp
as
SELECT     fiArtikel, ISNULL(MAX(Datum), GETDATE() AS Datum, EKVK
FROM         dbo.Preise
WHERE     (Datum <= GETDATE())
GROUP BY fiArtikel, EKVK
HAVING      (MAX(Datum) <= GETDATE())

Für die eigentlich Abfrage greif ich dann über joins auf diese View zu, weil ich noch aus anderen Tabelle etliches Zeusch brauch. Aber im Grunde ist obige temporäre View schon das, was das Problem löst.

[alzaimar]

Du kannst es auch so lösen:

SQL-Code:

Select ID,
      Bezeichnung,
      (select top 1 preis 
         from Preise 
        where Preise.ID = Artikel.ID and Preise.Datum <= '1.1.2006' 
        order by Preise.Datum desc
      )
from Artikel

Die ORDER BY Klausel macht die Abfrage langsam. Wenn Du einen Clustered Index auf Preise.Datum setzt, ist die Welt aber wieder in Ordnung,weil das ORDER BY dann weggekürzt wird.

Das würde ich für die schnellste und einfachste Lösung halten.

[Hansa]

Ah, Alzaimar hat mein Beispiel konkretisiert. Und ich habe mal in der richtigen Datenbank nachgeguckt, wie das geht :

Delphi-Quellcode:

CREATE PROCEDURE ERRECHNEPREIS (
    ID_ART INTEGER,
    PGNR SMALLINT,
    ABDATUM DATE)
RETURNS (
    PREIS DECIMAL(15,2))
AS
BEGIN
  SELECT FIRST 1 PREIS FROM ARTPG WHERE
    (PGNR=:PGNR) AND (ABDATUM <= :ABDATUM)
  ORDER BY ABDATUM DESC INTO :PREIS;
  IF (PREIS IS NULL) THEN PREIS = 0;
  SUSPEND;
END^

PG steht für Artikel-Preisgruppe (extra Tabelle). Ist der Preis direkt dem Artikel zugeordnet, dann gehts noch kürzer. Der bisher gezeigte Code ist IMHO zu kompliziert / unleserlich für den Zweck.

[Jelly]

@Hansa: Deine Procedure liefert mir aber nur den Preis eines Artikels. Ich brauche aber eine Liste (Resultsut) von allen Artikeln und dem zugehörigem Preis zu gegebenem Datum.

Aber meine Lösung klappt ja mittlerweilen, warum noch lange rumexperimentieren.