SQL Zeilendifferenzen
 

Hallo!
Ich habe einige SQL-Tabellen, etwa folgenden Aufbaus:

Ich bräuchte nun die Differenz zwischen den Zeilen in einer neuen Spalte, also etwa so:

Geht das in SQL oder muss ich das über eine Schleife rundherum lösen?
fragt sich
roland

select feld1, feld2, (feld2 - feld1) as diff from irgendwo

pong

Und wie heißt's so schön: Wer lesen kann, ist klar im Vorteil!
:(

google nutzen auch :rolleyes:

http://www.adp-gmbh.ch/ora/sql/inser..._subquery.html

pong

Beschreibe genauer, von wo die Differenz genau berechnet werden soll.
Denn die Differenz zwischen 1 und 2 ist nicht 0.

Nicht böse sein, aber wie soll man das noch genauer beschreiben: Die Differenz zwischen zwei aufeinanderfolgenden Zeilen?

Zwischen 2 und 2,4 ist 0,4 Differenz.
Zwischen 2,4 und 3,2 ist 0,8 Differenz.
...
...
...
Zeile(n) - Zeile(n-1)

klar geht das, aber kompliziert... aber vielleicht weiß ja jemand einen einfachen weg

Man könnte es klarer formulieren.
Warum bringst du da 2 Felder ?
Was meinst du GENAU mit der Differenz ?
Differenz zwischen was ?

Man kann erst an einer Problemlösung arbeiten, wenn man eine klare Problembeschreibung hat.

Meinst du das so:
Zeile1: Feld1+Feld2=Summe1
Zeile2: Feld1+Feld2=Summe2
Zeile3: Feld1+Feld2=Summe3

Differenz Zeile1 = Summe 1 - Summe 2 ?
Differenz Zeile2 = Summe 2 - Summe 3 ?

ok, vergiss einmal Feld1. Das hab ich drin, weil es ja eine Reihenfolge der Zeilen geben muss. Ich will ja nicht die Differenz zwischen Zeile1 und Zeile7 berechnen, sondern schön hintereinander Zeile2 minus Zeile1, Zeile3 minus Zeile2, Zeile4 minus Zeile3 usw.
eben wie beschrieben Zeile(n) minus Zeile(n-1).

Und die Differenz ist das Ergebnis einer Subtraktion (sagt die Wikipedia).

Wer MatLab kennt, kennt vielleicht den Befehl "diff".
Gernau das auf SQL bezogen.
Weil hier offenbar auf genaue Definitionen Wert gelegt wird, hier noch eine Begriffsbestimmung, wie MatLab das sieht:

"Y = diff(X) calculates differences between adjacent elements of X.

If X is a vector, then diff(X) returns a vector, one element shorter than X, of differences between adjacent elements:

[X(2)-X(1) X(3)-X(2) ... X(n)-X(n-1)]"

es grüßt
Roland

ich denke nicht, dass sql zeilenbasiert - wie von dir gewünscht - arbeiten kann.

du kannst dir den effekt aber selber zusammenbauen:
lese 1.zeile, merk dir den wert des gewünschten feldes, lese nächste zeile und wende dein diff auf das vorher gemerkte feld und das gewünschte feld dieser zeile an und speichere das ergebnis als neues feld...

wenn man geschickt ist, bekommt man das hin (in einem statement) :D

das ganze ist auch unter dem namen "schleife" bekannt.... und jetzt springen wir mal zusammnen ganz nach oben zum ursprungspost.
und wieder
und wieder
und wieder
und wieder
und wieder!

sry, dann kann dir (von mir) nicht geholfen werden...

(oder will nicht - solltest einmal vielleicht über deinen umgang nachdenken... :rolleyes: )

Jetzt tut's mir aber auch leid!
Ich versteh nicht, was du mit "Umgang" meinst.
Ich stelle eine - mMn präzise - formulierte Frage. Warum? Weil ich eben kein SQL-Könner bin.
Der erste gute Rat, der mich ereilt, zeigt mir, dass die Frage nicht gelesen wurde.

Darauf weise ich - zugegeben - pointiert hin, und ich glaube auch nicht, dass Pong das als Beleidigung aufgefasst hat.

Dein Beitrag beschränkt sich auf
"klar geht das, aber kompliziert... aber vielleicht weiß ja jemand einen einfachen weg".
Danke, sehr hilfreich.

Nebenbei ein Kommentar vom Lord of Midnight, bei dem ich den Eindruck habe, da hat jemand nachgedacht und nicht nur seinen Postingzähler erhöht.

Dann dein zweiter Kommentar, man könne das Zeile für Zeile lesend und subtrahierend lösen.
Jetzt mein Einwand, dass das eine Schleife ist und ich schon die Vermutung geäußert habe, dass das vielleicht eh nur in einer Schleife geht, aber man lernt halt was SQL betrifft immer wieder gerne was dazu.

Irgendwie kann ich nicht erkennen, wie du mir versucht hast zu helfen.

Und nun bist du beleidigt und beschwerst dich über den Umgang.

Tja, leider war ich impulsiv genug, auf deine Postings zu antworten.

Mir hätte es ja schon gereicht, wenn jemand gesagt hätte "vergiss das in SQL, schreib dir eine Schleife in der Skriptsprache deiner Wahl und iteriere durch das Recordset".

Sollte also ein SQL-Könner den Thread mitgelesen haben und dieser Auffassung sein, bitte kurz Bescheid geben.

so long
Roland

Da http://entwickler-forum.de/showthread.php?t=11366 findest ein Beispiel wie eine kumulative Summe berechnet werden kann.
Wenn du von der dann noch den ersten Wert abziehst solltest du deine Differenz haben.
Vielleicht gibt es auch sowas wie eine kumulative Differenz habe auf die schnelle aber nichts gefunden.

danke, opa - genau das habe ich mitundgemeint...

wie war das nochmal?

Ok, jetzt habe ich zumindest die Frage jetzt richtig verstanden.
Ganz verkalkt bin ich also noch nicht.

Funkts mit der obigen Antwort ?

Ps:
Seids doch nicht immer gleich so angrührt und zierts euch nicht so.
:rolleyes:
Seids doch froh, daß ihr im Forum jemand habts, der euch hilft und daß ihr nicht bei allen Problemen auf euch alleine gestellt seid !

Danke Opa für den entscheidenden Hinweis!

hi,

wenn es nicht unbedingt sein MUSS, würde ich das dann aber doch programmatisch lösen. SQL ist nun mal eine mengenbasierende Abfragesprache (das nur als anmerkung, wenn du öfter was in die richtung machen möchtest), wo die Satzreihenfolge keine Rolle spielen sollte - wenn doch so ist das imho. bissl "vergewaltigung" von sql.

Das wichtigste is aber, dass es funktioniert. :D

fg
hannes

Hi!
Hab nun auch noch einiges zur "Mengenbasiertheit" von SQL gelesen (da ist umdenken gefragt).
Die Tabellen liegen von einem Messprogamm im Access-Format vor, da kann ich nichts dran ändern.
Zwischenzeitlich ist das Problem gelöst, mit dem folgenden Statement komme ich wie gewünscht auf die Differenzen der Spalte "s".

Ein wichtiger Grund, warum man manche Dinge kompliziert in SQL löst ist, daß die Performance oft um den Faktor 100 besser ist.
Habe auch schon 1000fache Geschwinigkeiten gesehen im Gegensatz zu einem programmatischen Ansatz.

Bei ein zwar Zeilen ist das egal, aber wenns um Hunderttausende oder sogar um Millionen von Records geht, dann nicht mehr.

hallo,

mit programmatisch meine ich in diesem fall als stored procedure bzw. sollte man der Datenbank auf jeden fall die möglichkeit geben für die abfrage einen execution plan zu erstellen, diesen zu kompilieren und zwar nur 1 mal und nicht bei jeden aufruf des sql scripts.

Vom Programm her einen sql string übergeben ist sicher nicht die performanteste möglichkeit eines DB Zugriffes - manche Entwickler sind sogar der Auffassung, der Zugriff über Stored Procedure sollte die einzig verwendete Zugriffsform auf den DB Layer sein.

...aber das hat jetzt nichts mehr mit dem ursprünglichen Thema zu tun.

fg
hannes

Es hängt einfach davon ab wie die Situation ist.

Was du meinst ist, daß man in den Programmen nicht ständig alle Abfragen neu parsen sollte.
Das ist dann kritisch, wenn es sehr viele Abfragen von sehr vielen Benutzern, und das gleichzeitig gibt.

In meinem Fall ging es um genau ein Sql-Statement.
Und bei dem gewinnt man MASSIV an Performance wenn man in Sql anstatt einer gespeicherten Prozedur macht.

Das Parsing einer einzigen Sql-Query wird in diesem Fall egal sein.
Und natürlich dauert das Parsing bzw. Verarbeiten einer ganzen Prozedur wieder wesentlich länger als das eines einzigen Sql-Statements.

Ebenso ist es natürlich egal, wann man 100 Zeilen bearbeitet.
Das geht in jedem Fall schnell, da muss man sich auch über "schlampige" Methoden keine Gedanken machen.