Folgendes 'Problem'

Rechnungen und Rechnungspositionen. Jede RP hat einen Preis und einen Steuersatz. In den Rechnungen soll die Gesamtrechnungssumme hinterlegt werden. Dieses Feld ist die Summe der RP-Preise + Steuersätze... Eigentlich ganz einfach.

Eine RP kann nachträglich noch verändert werden. Der Kunde will nun nicht jedesmal extra einen Summierungslauf starten, also sollen die Summen irgendwie 'im Hintergrund' auf dem neuesten Stand gehalten werden.

Wenn die Werte per SQL-Konsole nicht immer 100% stimmig sind, macht das nix.

Wie würdet ihr diese summierten Werte pflegen?

Ich habe probiert:

1. Mit Triggern. Jede Änderung in der Tabelle 'Rechnungspositionen' führt dazu, das die entsprechenden Summenfelder in der Tabelle 'Rechnungen' überarbeitet werden.

2. Mit einem 'Dirty'-Flag. Bei jeder Änderung der Rechnungsposition wird ein Feld 'Dirty' in der Rechnungstabelle gesetzt. Vor jeder Abfrage der Rechnungsdaten werden etwaige mit 'Dirty' markierte Rechnungen neu summiert.

3. Mit einer extra Tabelle 'ZuBerechnendeRechnungen'. Bei jeder Änderung in den RP wird die Rechnungs-ID in diese Tabelle geschrieben. Vor jeder Abfrage der Rechnungsdaten werden etwaige in dieser Tabelle enthaltene Rechnungen neu summiert (und die Tabelle anschließend gelöscht).

Bei (1) habe ich ziemliche Performanceeinbußen, da sich die Transaktionen gegenseitig massiv auf die Füße treten. (2) habe ich eben implementiert, kann das aber nicht richtig testen und (3) ist ein Versuch, die Table-Locks auf diese unwichtige Tabelle zu lenken.

Wer hat damit Erfahrungen und kann mir Tipps geben? Wie siehts mit den Locks aus? Gibts noch andere Möglichkeiten?

Danke im Voraus!

Mir würde da spontan eine doppelte Datenhaltung in den Sinn kommen. Eine Spalte, die die jeweils summierten Werte beinhaltet, und eine weitere, die das jeweilige Delta zum vorigen Datensatz speichert. Will man nun eine Summe von "mitten drin" haben, muss nicht aufwendig neu summiert werden, und wenn eine Änderung eines älteren Postens eintritt, muss nur ab diesem, und auch nur dann der Rest der Tabelle neu summiert werden. Wenn mich nicht alles täuscht, macht SAP das zumindest ähnlich.

Hi, ich glaube, Du hast mich nicht verstanden (bzw. war meine Erklärung zu ungenau): Es geht nicht um eine Historie, sondern um die Summen...

Also:

Rechnung Summe = 9 Euro
RP : (3 Einträge) (A, 2 Euro), (B 3 Euro), (C 4 Euro)

A+B+C = 9 Euro.

Wenn ich jetzt 'C' ändere (sagen wir auf 5 Euro) dann müsste die Rechnungssumme in der Tabelle 'Rechnung' ja auf 10 Euro mitgeändert werden. Und da ist eben die Frage, wie?

P.S.: Ich kann ja auch einfach auf das Feld 'Summe' verzichten und bei die Summen bei jeder Tabellenabfrage explizit neu bilden. Aber das sind zu viele Rechnungen. Das dauert u.U. zu lange.

Ich glaube, ich hab richtig verstanden. Mal dein Beispiel als Basis.

Eine Tabelle

markieren

Code:

 name | summe | delta
----------------------
 A   |     2 |    2
 B   |     5 |    3
 C   |     9 |    4

Weils Spaß macht, ändern wir nun den Wert von B von 3 zu 4. Dabei musst du nur den Deltawert in der Zeile B ändern, und kannst ab der Summe in A mit den folgenden Deltas neu summieren. Dabei sparst zu die Summation über alle Zeilen, die möglicherweise vor A kommen, und hast als "Bonus" noch wahlfreien Zugriff auf alle Summenschritte ohne Mehraufwand beim Lesezugriff selbst.
Implementieren würde ich das als Trigger.

\\edit: Das ganze setzt nur voraus, dass du einen eindeutigen Sortierschlüssel verwendest. Der könnte sich allerdings durchaus nachträglich ändern, nur wäre dann in der Tat eine komplett neue Summierung sinnvoll. Aber wer macht sowas schon

Ah, kapiert. Aber beim Ändern von 'B' muss ich auch alle 'folgenden' Zeilen ändern und damit ist der Vorteil wieder dahin. Denn das bringt mir wieder kaskadierte Trigger, die zwar 'NOP' sind (weil die Spalte 'Delta' nicht verändert wurde), aber trotzdem belasten. Und den Vorteil der Teilsummen brauche ich nicht.

Wenn du die Teilsummen nicht brauchst, wird es ja noch hübscher. Du speicherst nur noch die Deltawerte, und in einer zusätzlichen Tabelle oder Zeile die Summe. Wenn du nun eines der Deltas änderst, merkst du dir die Differenz zwischen dem alten und neuen Delta, und musst diese nur noch zu der alten Summe addieren. Damit braucht die Änderung nur noch eine Subtraktion und eine Addition.

\\edit: Zwar nicht mehr relevant, aber der Vollständigkeit halbar: Der Vorteil ist nur bedingt "hin". Er ist es, wenn man gleich den ersten Eintrag ändert, aber bei Tabellen mit mehreren tausend Sätzen, von denen einer im hinteren Drittel geändert wird macht sich das schon bemerkbar, dass man 2/3 nicht neu bearbeiten muss.

Ich würde trotzdem auf das Feld Summe in der Rechnung Tabelle verzichten. Das führt zu Redundanz und ist somit fehleranfällig, da unter Umständen die Summe der Einzelposten nicht mehr mit der Summer der Rechnung übereinstimmen, aus welchem Grund auch immer. Ausserdem bin ich der Meinung, egal welchen automatisierten Mechanismus du wählst, um die Summe dennoch kohärent mit den Einzelbeträgen zu halten (also sei es über Trigger irgendwelche Updates ausführen oder über Delta werte wie vorgeschlagen), dass eine simple join-Abfrage über Rechnung/Posten immer schneller ist, als deine Updates, die du ja dann sparst... Selbst bei 100000 Rechnungen wird ein Join zu der Posten Tabelle rasend schnell bleiben, sofern du deine Indizierung in der Postentabelle natürlich auf deinen Foreign Key gesetzt hast.

Hallo,

benutze eine SP zum Setzen des RP-Wertes.
Dann kannst do dort drin schön die R-Summe berechnen und speichern.

Vom Weglassen der Summe rate ich ab,
trotz der Redundanz.

Performance ist hier das wichtigste.
Ein Join dauert, und ein sum auch, auch wenn es in einem View passiert (als Bsp.)

Du könntest als Check noch das Datum/Uhrzeit der letzten Änderung
(bei RP, und bei R) eintragen, es darf dann keine RP mit neuerem Datum als in der R. geben.
(wenn du es mit der SP machst, holst du dir vor dem Update das Datum/Uhrzeit und setzt
es bei RP und R).

Ein ganz anderer Ansatz ist das Bearbeiten im Client.
Wenn ein Client die PB bearbeitet, hat er auch die R zu aktualisieren.


Heiko

Hier gibt es einfach verschieden Vorgehensweisen, die alle ihre Vor- und Nachteile haben. Nehme mal an, dass die Auswertugnsroutine mit den Rechnungssummen wesentlich weniger häufig gestartet wird, als die Rechnugnsroutine. Unter der Vorraussetzung würde ich folgendes machen.

1. In der Statistiktabelle wird eine Summe aller Rechnungen gehalten, als auch ein ActiveFlag
2. Bei Änderung einer Rechnung wird das ActiveFlag auf false gesetzt.
3. Wird die Auswertungsroutine (Sttistik) gestartet wird geschaut ob das ActiveFlag true ist, dann nur Anzeige durcführen, sonst sonst neu berechnen (SQL-Abfrage)

So müssen sich die Clients während des Rechnungschreibens nicht mit der Statistik herumschlagen, was bei externer Anbindung von Vorteil ist (Aussendienst). Statistikmodule werden üblicherweise nur intern bearbeitet und haben meist einen eingeschränkten Nutzerkreis mit deutlich schnelleren Rechnern.
Fazit: Eine Trennung von Rechnungsclient und Statistikclient erscheint sinnvoll.

PS: Hier mit SP´s zu arbeiten ist möglich, sehe aber keine Notwendigkeit.


Grüße // Martin

Zitat von alzaimar:

...
Eine RP kann nachträglich noch verändert werden. Der Kunde will nun nicht jedesmal extra einen Summierungslauf starten, also sollen die Summen irgendwie 'im Hintergrund' auf dem neuesten Stand gehalten werden.
...

In jeder ernstzunehmenden Buchhaltung ist das schlichtweg VERBOTEN - eine geschriebene Rechnung kann nur durch Gutschrift/neue Rechnung korrigiert werden. Die Gründe sind so naheliegend, dass eine Diskussion darüber ziemlich sinnlos ist.

Folglich habe ich Umsatzstatistiken bisher immer über die aktuelle Summation von Rechnungsbeträgen durchgeführt. Ich wüsste auch nicht, warum man das anders machen sollte - bei Änderung einer Rechnung muss ja der Gesamtbetrag mitgeändert werden, sonst ist die Rechnung schon in sich inkonsistent!

Es ist mir klar, dass Firmenschefs von solchen Einschränkungen häufig nicht begeistert sind, aber Finanzamt und Wirtschaftprüfer sehen das nun mal anders, und sie haben damit Recht, sowohl sachlich als auch qua Amt.

Gruss Reinhard