MySQL Date Problem

[mixmastertobsi]

Hallo,

ich versuche mich gerade an eine MySQL abfrage und frage mich gerade, ob ich das, was ich mir da vorstelle, überhaupt in einer Abfrage realisieren kann.

Ich mache am besten ein Beispiel mit Tabellen, damit Ihr wisst, was ich meine.

Ich habe eine Tabelle Lagerbestand und eine Tabelle Lager-History mit einem Datum.

Lager

|ID|Artikel|Menge |---| |1|Hose|5

Lager History

|Artikel-ID|Type|Menge|Datum |---| |1|Wareneingang|1|2013-05-01 |1|Wareneingang|2|2014-05-01 |1|Wareneingang|4|2015-05-01

Ich habe noch im Lager 5 Hosen und möchte nun das Datum der ältesten Hose, welche im Lager ist, herausfinden. Nun könnte ich natürlich mit ORDER BY date LIMIT 1 mir das älteste Datum ausgeben lassen, allerdings würde mir dann 2013-05-01 ausgegeben werden, was in dem Beispiel falsch ist, denn wenn ich noch 5 Hosen im Lager habe, müssen 4 Hosen von der Lieferung aus 2015 sind und eine Hose aus der Lieferung von 2014 und somit bräuchte ich das Datum 2014-05-01 als Ausgabe.

Geht das in einer MySQL abfrage?

[TS]

Hello,

bei deinen Bewegungsdaten fehlen die Warenausgänge.
Wenn Du die dazu nimmst, kannst Du gruppieren.

Du willst quasi eine Seriennummern- bzw. Chargenverwaltung bauen. Dazu benötigt man zumindest jeweils alle Daten für eine Charge oder für noch genauer dann eben für jedes Stück.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Ich habe noch im Lager 5 Hosen und möchte nun das Datum der ältesten Hose, welche im Lager ist, herausfinden.

Das geht nur, wenn du deine Hosen strikt nach First In First Out ein- und verkaufst. Ansonsten müsstest du eine Verwaltung jeder einzelnen Hose haben. Aber ich denke, der Aspekt spielt keine Rolle.

Geht das in einer MySQL abfrage?

Jein, denke ich. Mit einer Stored Procedure könntest du eine Schleife erstellen, die rückwärts in der Zeit vom Lagerbestand die Anzahl aus dem jeweiligen Lagerbestand abzieht und wenn das bei 0 angekommen ist, hast du den Datensatz mit dem gesuchten Datum.

dedlfix.

[mixmastertobsi]

Aber diese Abfrage wäre sicherlich sehr rechenintensiv, wenn ich hier diesen Abgelich auf tausende Produkte machen möchte.

[dedlfix]

Tach!

Aber diese Abfrage wäre sicherlich sehr rechenintensiv, wenn ich hier diesen Abgelich auf tausende Produkte machen möchte.

Unter Umständen. Ist sie denn ständig auszuführen? Wird sie ständig mit allen Produkten ausgeführt oder nur beschränkt auf ein oder wenige Produkte? Und vielleicht ist dein Server ja auch viel schneller als du denkst.

So ein RDBMS arbeitet mengenorientiert. Wenn du eine Bedingung formulieren kannst (erstmal in Worten statt konkreter Syntax), mit der du die Menge der relevanten Datensätze beschränken kannst, dann geht das auch in einer Abfrage. Aber du kannst bei deinem Ziel (meiner Meinung nach) nicht jeden Datensatz einzeln betrachten und entscheiden, ob er in die Ergebnismenge kommen soll oder nicht. Du kannst diese Entscheidung nur treffen, indem die Werte anderer Datensätze berücksichtigt werden, an denen du dich entlanghangeln musst. Und du musst beim Vorliegen des Ergebnisses abbrechen und die anderen Datensätze ignorieren. Die zu ignorierenden kannst du nicht vorher ermitteln. Das sind alles Bedingungen, die nicht mengenorientiert abgearbeitet werden können (wie gesagt, nach meinem Dafürhalten).

Du kannst versuchen, das mit User-defined Variables innerhalb eines Select hinzubekommen. Aber das ist mehr Gefummel als eine Stored Procedure/Function und hilft dir auch nicht bei der Performance, weil auch dann jeder Datensatz einzeln betrachtet werden muss und kein Index beim Ausschließen nicht benötigter Datensätze hilft.

dedlfix.

[TS]

Hello @mixmastertobsi,

nur mal so als Nebeninformation:

Darum macht man in einer Warenwirtschaft u. a. auch

• Tagesabschluss
• Wochenabschluss
• Monatsabschluss

In der (den) Abschlusstabelle(n) stehen dann die konsolidierten Werte der jeweiligen Zeiträume. Diese sind nicht nur für das Finanzamt relevant, sondern dienen bei den von Dir vorgesehenen Abfragen als stabile Aufsetzpunkte. Man erzeugt also eigentlich bewusst redundante Daten, um dann die Bewegungsdaten (hier für Eingänge nd Ausgänge) nicht bei jedem Request von Anfang an lesen zu müssen, sondern nur vom letzten relevanten Aufsetzpunkt aus bis zum gewünschten Zieldatum (meistens aktuelles Ende).

Liebe Grüße
Tom S.