mysql: Query gesucht

[Rolf B]

Hallo Pit,

doch, das ist genau richtig so. Willst Du den ganzen Satz zum MAX-Wert haben, brauchst Du entweder zwei Queries (und setzt in die zweite den gefundenen MAX Wert ein), oder Du musst die MAX-Ermittlung in die "ganzer Satz" Query einsetzen.

Wüst wird das ganze, weil dein Datenmodell nicht in Ordnung ist. Ich nehme an, dass Du mittlerweile genug Legacy-Code am Bein hast, dass Du das Modell nur mit massivem Aufwand ändern kannst. Aber diese Query schreit nach Modellverbesserungen, also denk bitte drüber nach und hol Dir vorher ein Buch über Datenmodellierung.

So, wie es jetzt ist, verletzt Du mit "meineSpalte" die erste Normalform, weil zwei Informationen in einer Spalte stehen: Status und Nummer. Deswegen musst Du "meineSpalte" mühsam zerlegen, um an die Nummer heranzukommen.

Die Unterscheidung KL / KLB kommt mir auch unnormalisiert vor. Du bestimmst das Maximum der laufenden Nummer für "KL" OR "KLB" - d.h. die beiden teilen sich einen Nummernkreis für die laufenden Nummern? Daraus folgere ich, dass das B in KLB sehr gerne eine eigene DB-Spalte wäre. Ich kenne die Semantik dieses B nicht, darum kann ich da nur hypothetisieren. Ich nenne das mal "statusOpt" wie "Status-Option". Aber vielleicht geht's ja auch nicht anders. Ich kenne deine Daten nicht.

Wäre die Table so designed:

|ID|yourStatus|statusOpt|deineSpalte |-|-|-|-|- |1|KL| |12 |2|KL|B|13 |3|FC|L|1 |4|FC| |2

dann könntest Du das Maximum für KL viel einfacher bestimmen:

SELECT MAX(deineSpalte)
FROM yourTable
WHERE myStatus = 'KL'

und den ganzen Satz bekommst Du mit

SELECT id, yourStatus, statusOpt, deineSpalte, fooSpalte, barSpalte, bazSpalte
FROM yourTable
WHERE myStatus = 'KL'
  AND deineSpalte = (SELECT MAX(deineSpalte) FROM yourTable WHERE myStatus = 'KL'))

Datenmodellierung vor dem Bau der Anwendung mag lästig klingen und auch Kopfschmerzen bereiten. Daten, die aus der Datenbank kommen, für die Darstellung immer erstmal aufbereiten zu müssen, ist auch lästig.

Aber deine Query ist ein Musterbeispiel für die Folgen fehlender Normalisierung und display-orientierter Datenspeicherung. Das macht einem am Ende viel mehr die Birne weich, als die vorherigen Workshops und zähen Diskussionen über "was wollen wir mit den Daten eigentlich machen" und "wie speichert man was am besten". Ich hab da Erfahrung mit. Ich arbeite seit '85 in einer großen Versicherung. Unsere DB-Admins sind wirklich anstrengend, wenn sie Modellierungsfehler wittern. Aber bisher hat es sich immer gelohnt.

Rolf