Distinct Abfrage aber eben nicht....

Maexx77

Benutzer
Beiträge
5
Hallo,

ich bekomme mit einer größeren Abfrage aus der Datenbank folgende Daten:

Artikel Maschine Material Datum
1 A C 1.1.2017
2 A C 1.2.2017
3 B D 1.1.2017
4 B E 1.1.2017
5 A F 1.1.2017

Nun möchte ich, dass die Ergebnismenge im Feld Material eindeutig ist.
Distinct kann ich nicht nehmen, da ich Artikel und Maschine aus Daten brauche und deshalb die Datensätze nicht herausgefiltert werden würden.
Select TOP 1 als Unterabfrage kann ich auch nicht nehmen, da ich wie gesagt alle Daten brauche und mehrere Unterabfragen zu heftig wären.

Im o.g. Fall will ich den 1. Datensatz rausschmeißen, damit das Material C nur einmal vorkommt. Diese Entscheidung soll auf Grund des Datum gefällt werden. Die Einträge bei Artikel 2 sind neuer.

Hat jemand eine Idee, wie ich das machen kann?
Ich stehe auf dem Schlauch.

Es würde evt. auch reichen, wenn die Bedingung mit dem Datum ignoriert wird. Ich brauche halt nur jedes Material einmal, mit irgendwelchen Infos unter Artikel und Maschine.

Gruß Mäxx
 
Werbung:
In PostgreSQL ginge das mal wieder einfach mit DISTINCT ON (...)

Code:
test=# select * from maexx77 ;
 artikel | maschine | material |  datum   
---------+----------+----------+------------
  1 | a  | c  | 2017-01-01
  2 | a  | c  | 2017-01-02
  3 | b  | d  | 2017-01-01
  4 | b  | e  | 2017-01-01
  5 | a  | f  | 2017-01-01
(5 rows)

test=# select distinct on (material) * from maexx77 order by material, datum desc;
 artikel | maschine | material |  datum   
---------+----------+----------+------------
  2 | a  | c  | 2017-01-02
  3 | b  | d  | 2017-01-01
  4 | b  | e  | 2017-01-01
  5 | a  | f  | 2017-01-01
(4 rows)

test=#

Für nicht ganz so tolle Datenbanken sollte dies aber auch gehen:

Code:
test=# select maexx77.* from maexx77 inner join (select material, max(datum) as datum from maexx77 group by material) foo on ((maexx77.material,maexx77.datum)=(foo.material,foo.datum));
 artikel | maschine | material |  datum   
---------+----------+----------+------------
  2 | a  | c  | 2017-01-02
  3 | b  | d  | 2017-01-01
  4 | b  | e  | 2017-01-01
  5 | a  | f  | 2017-01-01
(4 rows)
 
Lösung die nur mit PG funktioniert für eine andere DB gepostet? Check! :D
Hinweis wie gut PG ist? Check! :D
Alternative Lösung mit analytischen Funktionen? Fail -> Jetzt bin ich etwas enttäuscht :p

Code:
SELECT DISTINCT FIRST_VALUE(ARTIKEL)
          OVER(PARTITION BY MATERIAL
               ORDER BY DATUM DESC) AS AKTIKEL,MASCHINE,MATERIAL,
       FIRST_VALUE(DATUM)
          OVER(PARTITION BY MATERIAL
               ORDER BY DATUM DESC) AS DATUM
FROM T ORDER BY MATERIAL,DATUM DESC
 
Coole Sache. Die funktioniert wirklich.
Leider setzen/müssen wir den SQL 2000 ein. Aber vielleicht nutze ich einen Linked Server dazu.

Wieder was gelernt!
Danke!
 
Wie sieht das eigentlich bei so Verbindungsservergeschichten aus?
Klar, das belastetet das Netzwerk.
Aber im Endeffekt den Quell Server am wenigsten,oder?

Meine Vermutung:
Wenn ich mir irgendwas "baue" um unter 2000 das gleiche Ergebnis zu bekommen ( Unterabfrage, Group By, Max etc....) dann ist das sehr aufwendig.

Wenn ich aber den Quellserver nur die Rohdaten liefern lasse und der 2014-Server verarbeitet diese mit den neuen Möglichkeiten, dann hört sich das erstmal nach weniger Arbeit für den alten Server an.
Nur die Übertragung zum anderen Server erfolgt halt noch.

Jetzt spinne ich mal weiter: Ich installiere parallel zum 2000er Server einen 2014er Server, auf der gleichen Maschine, der nur dazu dient, die 2000er Datenbank abzufragen, dann läuft es doch. Oder???? Ist wahrscheinlich zu kurz gedacht. ;)
Beste Lösung ist natürlich von 2000 weg zu kommen. Hier gibt es aber vom ERP Anbieter keine Freigabe für.
 
Also mit einem Verbindungsserver müsste es auf dem neuen gehen, habe ich aber noch nicht probiert. Beide auf dem selben Server das würde ich vermeiden. Setz deinen Berechnungsserver irgendwo in eine VM, die Rohdaten über das Netz zu verschicken sollte keine große Sache sein und du kannst deine VM getrennt von wichtigen Ressourcen oder eingeschränkt betreiben wenn das wirklich so ein hoher Rechenaufwand ist.
 
Also mit dem Verbindungsserver funktioniert es auf jeden Fall.
Sogar von SQLExpress 2014 auf den Server2000.
Beide Maschinen sind schon virtualisiert.
Das ist echt ideal, um eine alte Datenbank mit neuen Möglichkeiten abzufragen.
 
Werbung:
Das hatte ich ja auch schon geschrieben. Aber ein ERP System ändern man nicht mal eben, nur weil eine Abfrage nicht geht.
Beste Lösung ist natürlich von 2000 weg zu kommen. Hier gibt es aber vom ERP Anbieter keine Freigabe für.

Glaube mir: Wenn ich könnte, würde ich sofort auf eine aktuelle Datenbank migrieren.
 
Zurück
Oben