nicht angemeldet
Hallo,
das ist nicht ideal, einen sogenannten sprechenden schlüssel als primary key zu benutzen. wenn es keine gründe dafür gibt, zum beispiel vorgabe des kunden, dann nimm lieber einen künstlichen schlüssel und mach für die schnittnummer eine extra spalte, die unique und not null contraints besitzt.
Ich habe bis jetzt noch nie verstanden, warum man in einer Tabelle, in der eine Spalte existiert, die einen Datensatz bereits eindeutig identifiziert (was ja die Aufgabe eines Primär-Schlüssels sein soll), noch zusätzlich eine zweite Spalte anlegen soll, deren Wert dann, so vermute ich mal, per Sequenz oder AutoID oder wie auch immer erzeugt wird.
Hat das nur mit "Das macht man halt so" zu tun, oder gibt es einen triftigen Grund dafür.
Ich sehe nämlich in der Verwendung von mehreren Unique Keys, wobei jeder davon nur eine jeweils eine Spaltge betrifft, eher nachteilig, weil mehr Verwaltungsaufwand.
SELECT DISTINCT tab1.hier_spalten_zur_ausgabe_angeben
FROM tablle tab1
WHERE tab1.schnitternummer = (SELECT MAX(tab2.schnittnummer) FROM tabelle tab2 WHERE tab1.gruppe = tab2.gruppe)
OR tab1.schnitternummer = (SELECT MIN(tab3.schnittnummer) FROM tabelle tab3 WHERE tab1.gruppe = tab3.gruppe)
Naja, aber eigentlich wollte der OP MIN und MAX nur von den Gruppen > 0 haben, während für die Gruppe == 0 alle Werte ausgegeben werden sollten.
Abgesehen davon finde ich, dass das UNION-Statement leichter zu lesen ist, abgesehen von allfälligen Performance-Aspekten, die ich so einfach aus der Hüfte aber nicht beantworten könnte.
Grüße
Klaus