krampi: Letzter Eintrag einer ID finden und löschen oder ggf. bearbeiten

Hallo alle miteinander,

ich habe ein Problem mit einer Tabellenfunktion. Es geht um Angebot und Nachfrage. In meiner Tabelle "orderbook" vorhanden sind stock_id, stock_price, stock_count, ordertype, time, usr_id, order_id. "ordertype" hat 1 oder 0 zur Auswahl. 0 steht für Verkauf, 1 für Kauf. In der Tabelle habe ich mehrere Produkte (stock_id) stehen, dazu die Preise zu denen sie gehandelt werden und die Mengen (stock_count). Anhand von ordertype wird erkannt, ob es sich um einen Kauf oder Verkauf handelt. In der Variable $umsatz ist halt der Umsatz gespeichert, in $differenz der Unterschied zwischen der Umsatzmenge und dem höheren Angebot/der höheren Nachfrage. Dazu gleich mehr im Beispiel

Wir haben im Beispiel 2 Produktgruppen. 1 = Bananen, 2 = Äpfel. Es können auch mal andere Gruppen hinzukommen.

In der Tabelle steht nun (vereinfacht - stock_id, stock_price, stock_count und ordertype)
1 - 0,44 € - 10 - 1
1 - 0,44 € - 12 - 1
1 - 0,44 € - 20 - 0
2 - 0,90 € - 18 - 0
2 - 0,90 € - 3 - 0
2 - 0,90 € - 17 - 1

Wir sehen, dass das Angebot bei ID 1 (Bananen) 20 Einheiten beträgt, die Nachfrage 22 Einheiten. Der Umsatz wäre also 20 Einheiten, die Differenz betrüge 1.
Bei ID 2 (Äpfel) beträgt das Angebot 21 Einheiten, die Nachfrage 17. Umsatz wäre 17, Differenz sei 4.

Entsprechend müssen bei den Bananen 1 Einheit, bei den Äpfeln 4 Einheiten abgezogen werden. Es soll eben ein Gleichstand zwischen Angebot und Nachfrage erreicht werden.

Wie das geschehen soll, habe ich in einer "Denktschrift" niedergeschrieben:

"Solange $Buy>$Sell bzw. $Sell>$Buy ist, soll der jeweils letzte, demnach jüngste Eintrag verkleinert (sofern SUM(x)<Differenz)
oder gelöscht werden (sofern SUM(x)>Differenz)."

Ich hoffe, man versteht, was ich meine. Mein Problem ist unter anderem, wie ich eine Unterscheidung herbeiführe wegen der Produkt-IDs. Ich würde mit einer WHILE-Schleife arbeiten, jedoch ist das eine recht komplexe Sache. Darum habe ich leider auch kaum Ansätze. Dafür bitte ich um Verzeihung.
Vielleicht hat jemand einen Ansatz für mich. Wenn jemand eine komplette Lösung bieten würde, würde ich mich natürlich revanchieren, auch wenn es mir unangenehm und doch wieder genehm wäre.

Beste Grüße,
Christian

  1. Hi there,

    Ich hoffe, man versteht, was ich meine. Mein Problem ist unter anderem, wie ich eine Unterscheidung herbeiführe wegen der Produkt-IDs.

    Und wenn Du einfach den Timestamp mitabspeicherst? Dann hast Du immer den letzten Eintrag, den DU dann auf Deinen gewünschten Wert bringst oder löschst.

    Ich würde mit einer WHILE-Schleife arbeiten, jedoch ist das eine recht komplexe Sache.

    Das ist eine ziemlich dämliche Sache, keine komplexe. Afaik hat jedes Datenbanksystem irgendwelche Aggregatfunktionen. Leider hast Du nicht geschrieben, welche Datenbank Du mit Deinem Problem quälst. Aber falls es eine ist, die SQL versteht, würd' ich mir einmal die Funktionen COUNT und SUM anschauen...

  2. Hi,

    Wir sehen, dass das Angebot bei ID 1 (Bananen) 20 Einheiten beträgt, die Nachfrage 22 Einheiten. Der Umsatz wäre also 20 Einheiten, die Differenz betrüge 1.

    Du Betrüger! Die Differenz zwischen 22 und 20 ist 2, nicht 1.
    Oder wird da noch die ID abgezogen?

    Bei ID 2 (Äpfel) beträgt das Angebot 21 Einheiten, die Nachfrage 17. Umsatz wäre 17, Differenz sei 4.

    Nö, denn dann müßte hier die Differenz 2 sein ...

    Vermutlich willst Du nach stock_id gruppieren, und die Summe aus den stock_count bilden. wobei in Abhängigkeit vom order_type mal der Faktor 1 und mal der Faktor -1 draufgerechnet wird.

    Also im Prinzip sowas wie sum(stock_count * ((ordertype == 1)?-1:1))

    Den ?: Operator mußt Du halt durch ein Konstrukt ersetzen, das das von Dir verwendete DBMS kennt. Bei Oracle könnte man z.B. decode verwenden oder switch.

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    O o ostern ...
    Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
  3. Hallo,

    danke erstmal für die Antworten, auch wenn ich von den ersten beiden Sätzen von Andreas/MudGuard überrascht war.

    Aber zu den fraglichen Teilen meiner Frage: ja, pardon, die Datenbank ist MySQL und ein Timestamp ist eingebaut. Daran hatte ich glücklicherweise schon gedacht.

    Wichtig wäre eben, dass ich den Zahlenunterschied (Differenz sage ich nicht, sonst schimpft MudGuard) von 2 bei ID 1 und 4 bei ID 2 wettmache. Halt dass bei ID 2 der letzte Eintrag mit Menge 3 komplett gelöscht wird, da er kleiner als der Unterschied ist, und dann eben von der 18er-Bestellmenge eine weitere Einheit abgezogen wird, so dass auf beiden Seiten 17 steht.
    Gleiches verfahren bei ID 1, wo 2 abgezogen werden müssten.

    Sum, "Differenz" und so habe ich bereits. Mir ging es nun um die Funktion, um den besagten Unterschied durch Überschuss wettzumachen. Wie mache ich das?

    Oder habe ich eure Hinweise gerade falsch verstanden? Das sollte keine Absicht sein.

    Grüße,
    kampi

    1. Hi,

      danke erstmal für die Antworten, auch wenn ich von den ersten beiden Sätzen von Andreas/MudGuard überrascht war.

      Lies Deinen vor diesen zwei Sätzen stehenden Satz nochmal aufmerksam durch. Vielleicht erkennst Du dann das Wortspiel.
      (Wobei mich überrascht, daß Dich überrrascht, daß die Differenz zwischen 22 und 20 nicht 1, sondern 2 ist ...)

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      O o ostern ...
      Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
    2. Hi,

      danke erstmal für die Antworten, auch wenn ich von den ersten beiden Sätzen von Andreas/MudGuard überrascht war.

      Es war also deine erste Begegnung mit einem Wortspiel?
      Hoffentlich hat's nicht allzu weh getan ...

      SCNR ChrisB

      --
      RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
  4. Hello,

    Wir sehen, dass das Angebot bei ID 1 (Bananen) 20 Einheiten beträgt, die Nachfrage 22 Einheiten. Der Umsatz wäre also 20 Einheiten, die Differenz betrüge 1.
    Bei ID 2 (Äpfel) beträgt das Angebot 21 Einheiten, die Nachfrage 17. Umsatz wäre 17, Differenz sei 4.

    Entsprechend müssen bei den Bananen 1 Einheit, bei den Äpfeln 4 Einheiten abgezogen werden. Es soll eben ein Gleichstand zwischen Angebot und Nachfrage erreicht werden.

    Für eine Buchhaltungssoftware  wäre das der falsche Ansatz.
    Man unterscheidet zwischen Stammdaten und Bewegungsdaten.
    Die Banane als Beschreibung findet sich in einem Stammdatensatz.
    Die physische Banane kannst Du dann in Bewegungsdatensätzen finden, z.B.

    • Warenzugang
    • Warenabgang

    Es gilt der Grundsatz: "Gebucht ist gebucht".

    Das bedeutet, dass an Buchungsdatensätzen nachträglich nicht mehr manipuliert werden darf. Es darf also nicht einfach im Mengenfeld herumgeändert werden!

    Der Bestand errechnet sich aus einer Abfrage aller Zugänge minus aller Abgänge zur ID des Artikels.

    Du kannst zwischendurch "Buchungsschnitte" einführen und die kumulierten Altdaten zum Schnitt auslagern, aber nicht vernichten. Aus kaufmännischen Gesichtspunkten bist Du verpflichtet, diese Daten 10 Jahre lang aufzubewahren (in DE).

    Liebe Grüße aus dem schönen Oberharz

    Tom vom Berg

    --
     ☻_
    /▌
    / \ Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
    1. Um Buchungssoftware, lieber Tom, geht es hier nicht. Es geht um ein Handelssystem, um die Nachbildung von Börsensystemen. Und da träfe eben dieser Mechanismus eigentlich zu. Allerdings wollte ich eine vereinfachte Darstellung darbieten und nannte eben darum Äpfel und Bananen.

      An sich klappt es ganz gut, nur eben scheitere ich an diesem einen Punkt, den ich als Problem schildere.

      1. Hello,

        Um Buchungssoftware, lieber Tom, geht es hier nicht. Es geht um ein Handelssystem, um die Nachbildung von Börsensystemen. Und da träfe eben dieser Mechanismus eigentlich zu. Allerdings wollte ich eine vereinfachte Darstellung darbieten und nannte eben darum Äpfel und Bananen.

        An sich klappt es ganz gut, nur eben scheitere ich an diesem einen Punkt, den ich als Problem schildere.

        Auch wenn Du keine Rechtsvorschriften einhalten musst, kannst Du trotzdem bewährte Techniken einsetzen :-)

        Beim Verzicht auf die Trennung von Stammdaten und Bewegungsdaten muss man sich wirklich bei jedem Query Gedanken darüber machen, ob es Nebenläufigkeitsprobleme geben könnte.

        Bewegungsdaten werden üblicherweise "appending" geführt und das vermeidet das Problem i.d.R.

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bergpost.annerschbarrich.de
      2. Hallo,

        möchtest du ein Bid/Ask/Lot Matching implementieren?

        "Solange $Buy>$Sell bzw. $Sell>$Buy ist, soll der jeweils letzte, demnach jüngste Eintrag verkleinert (sofern SUM(x)<Differenz)

        oder gelöscht werden (sofern SUM(x)>Differenz)."

        Das ist ja schon mal eine Prosa-Beschreibung von dem was du willst. Das kann eigentlich recht gut in SQL Ausdrücken

        "Solange $Buy>$Sell bzw. $Sell>$Buy ist

        ... also, solange, die Differenz (ABS($Buy-$Sell)) <> 0 ist, wobei $Buy die Summe von stock_count WHERE OrderType = 4 ... logischerweise gruppiert (GROUP BY) stock_id.

        Allerdings sind nicht definiert:

        • x   ... was ist x? und was ist dann Sum(x)
        • "jüngst" .. die Bespieldaten können keine Aussage treffen was "jung" oder "alt" ist, du solltest deshalb einen entsprechenden Wert einführen

        (W)alternativ zu "jüngst" könnte man auch "billigst" nehmen. Bzw. das, was für die jeweilige Seite (buy oder sell) am besten ist.

        Ich vermute, du stocherst mit deinen Gedanken bereits zu tief in der Materie herum. Vergrössere noch mal den geistigen Abstand. :-)

        Ciao, Frank