SQL Frage zu Select abfrage

[Angus131]

Heyho,

ich hab ein kleines Problem mit einer SQL Abfrage

die Tabelle ist aktuell aus einer übung und beinhaltet daten für ein Tischtennis spiel.

Datenbank sieht aktuell ca so aus (unwichtige sachen lasse ich mal weg):

Spieltag / Spieler
1 / Hans Muster
1 / Sepp Müller
1 / Hannes Meier
2 / Heiri Müller
2 / Hannes Müller
2 / Josef Gasser

nun möchte ich in der Select abfrage das allerdings nicht so haben, das der Tag immer wieder angezeigt wird sondern nur 1 mal.

also so:

Spieltag Spieler
1 / Hans Muster
/ Sepp Müller
/ Hannes Meier
2 / Heiri Müller
/ Hannes Müller
/ Josef Gasser


wie wäre das möglich?

vielen Dank für hilfe

 

[Madman1209]

Hi,

was soll anstelle des Tags angezeigt werden? Du kannst nicht in einer Abfrage einmal eine und einmal zwei Spalten als Ergebnis haben. Entweder muss dann "null" rein oder "leer" oder "---" oder was weiß ich.

VG,
Mad

 

[Angus131]

das sollte dann einfach leer sein

 

[Madman1209]

Hi,

darf man fragen, was da dahinter steckt? Ich sehe gerade nicht, wo die Zahlen stören. Lohnt sich denn der "Aufwand" bzw. was wird damit bezweckt? Der Spieler hat ja nunmal den Tag, den "nur manchmal" anzuzeigen verfälscht eigentlich die Ausgabe...

VG,
Mad

 

[T3Kila]

Das geht nicht. Du kannst mit einer Abfrage nicht spezifische Daten aus manchen Datensätzen heraus filtern. Dafür hat man eine Oberfläche, die aus der Abfrage die "bereinigten" Daten anzeigt

 

[Angus131]

ich habe keine Ahnung.
ein freund hat mich das gefragt, da das eine Anforderung in seiner aktuellen Aufgabe von der Schule ist.
Ich selbst arbeite schon lange mit SQL musste aber sowas noch nie machen ( da es in meinen Augen auch nicht wirklich nützlich ist)
aber interessieren würde es mich trotzdem, welche Lösungsansätze es hierfür geben würde.

 

[Crumar]

Sehe den Sinn nicht, aber gut.

TSQL:

SELECT CASE WHEN RN = 1 THEN Spieltag ELSE NULL END Spieltag
     , Spieler
(
SELECT Spieltag, Spieler, ROW_NUMBER() OVER (PARTITION BY Spieltag ORDER BY Spieler) RN
   FROM Spieltag_Spieler I
) O
ORDER BY RN ASC

Brauchst also eine Funktion, die deine Reihen partitioniert numeriert. Dann eben nur bei der 1. Zeile den Wert anzeigen, bei allen anderen nicht.

Das geht nicht. Du kannst mit einer Abfrage nicht spezifische Daten aus manchen Datensätzen heraus filtern. Dafür hat man eine Oberfläche, die aus der Abfrage die "bereinigten" Daten anzeigt

Geht schon. Ist aber Unsinn, da geb ich dir recht.

 

[Angus131]

Sehe den Sinn nicht, aber gut.

TSQL:

SELECT CASE WHEN RN = 1 THEN Spieltag ELSE NULL END Spieltag
     , Spieler
(
SELECT Spieltag, Spieler, ROW_NUMBER() OVER (PARTITION BY Spieltag ORDER BY Spieler) RN
   FROM Spieltag_Spieler I
) O
ORDER BY RN ASC

Brauchst also eine Funktion, die deine Reihen partitioniert numeriert. Dann eben nur bei der 1. Zeile den Wert anzeigen, bei allen anderen nicht.



Geht schon. Ist aber Unsinn, da geb ich dir recht.

Vielen Dank Crumar, so klappt es eigentlich recht gut. Klar ist es Unsinn, aber wenn es gefordert wird muss man es ja machen

 

[Madman1209]

Hi,

Klar ist es Unsinn, aber wenn es gefordert wird muss man es ja machen

sehe ich anders - gerade als guter Entwickler sollte man bei vollkommen sinnfreien Anforderungen "Einspruch" rufen!

VG,
Mad

 

[Crumar]

sehe ich anders - gerade als guter Entwickler sollte man bei vollkommen sinnfreien Anforderungen "Einspruch" rufen!

Meh, das läuft dann auf eine Grundsatzdiskussion hinaus. Informatiker wollen dieses und jenes nicht entwickeln, weil sie es für sinnlos halten, aber ihre Kunden machen sie dann doch nicht glücklich.

Die Aufgabe hat durchaus eine Daseinsberechtigung. Es gibt andere Anwendungsfälle, wo so eine Logik sinnvoll ist. Und vielen fehlt es eben, bei so was mal "um die Ecke zu denken".

 

[Madman1209]

Hi,

Informatiker wollen dieses und jenes nicht entwickeln, weil sie es für sinnlos halten, aber ihre Kunden machen sie dann doch nicht glücklich.

der Kunde wird sich wohl oder übel auf meine Expertise verlassen. Das ist zumindest meine Erfahrung.

Die Aufgabe hat durchaus eine Daseinsberechtigung. Es gibt andere Anwendungsfälle, wo so eine Logik sinnvoll ist. Und vielen fehlt es eben, bei so was mal "um die Ecke zu denken".

welche wäre das? Ich sehe absolut nicht, wo diese Art Abfrage einen Sinn hätte. Das hat nichts mit "um die Ecke denken" zu tun...

VG,
Mad

 

[Crumar]

welche wäre das? Ich sehe absolut nicht, wo diese Art Abfrage einen Sinn hätte. Das hat nichts mit "um die Ecke denken" zu tun...

Datensätze zu gruppieren, aber anders zu behandeln. Mathematische Gewichtungen.
Median Berechnung pre SQL Server 2012.

Gibt mehrere Sachen, wo eine ROW_NUMBER funktion eine mächtige Hilfe ist. Und dabei auch einiges an Performance rausholen kann.
Klar ist das ersetzen eines Strings da erstmal ein simples Beispiel.

 

[Madman1209]

Hi,

für eine echte Gruppierung nutze ich aber die Aggregatsfunktion und muss nicht selbst etwas schreiben. Und was die Performance angeht: ein Select mit Subselect oder sogar zwei Selects werden bei der Performance in den allermeisten Fällen deutlich schlechter abschneiden als ein einfaches Select mit Aggr-Funktion.

Mir ging es auch nicht um grundsätzliche Ergebnismodifikation - das kann durchaus sinnvoll sein, keine Frage. Aber der aktuelle Fall ist es in meinen Augen nicht, jedenfalls lese ich hier noch kein konkretes Anwendungsbeispiel. Mir fällt auf die Schnelle auch keines ein. Schreibst du ja selbst:

Ist aber Unsinn, da geb ich dir recht.

VG,
Mad

 

[Crumar]

für eine echte Gruppierung nutze ich aber die Aggregatsfunktion und muss nicht selbst etwas schreiben.

Na, die Median Funktion hab ich ja schon erwähnt
Geh die mal suchen, in älteren MSSQL Versionen.
Beispiel mit Row_Number: https://sqlperformance.com/2012/08/t-sql-queries/median

Hi,

Und was die Performance angeht: ein Select mit Subselect oder sogar zwei Selects werden bei der Performance in den allermeisten Fällen deutlich schlechter abschneiden als ein einfaches Select mit Aggr-Funktion.

Allermeiste Fällen. Aber eben nicht alle.. Und davon hab ich auch schon ein paar gesehen.

Das Endziel hier ist sinnlos. Wie man an solche Aufgaben rangeht und ähnliches allerdings nicht.

Aber damit drehen wir uns dann im Kreis.

 

[Madman1209]

Hi,

Das Endziel hier ist sinnlos.

darum ging es mir

VG,
Mad

 

[SoDaTierchen]

Die Gruppierung mit einfacher Gruppenanzeige ist zwar sinnvoll, aber nichts, was SQL-Seitig abgehandelt werden sollte. Das ist ein Anzeige-Gimmik, was die Oberfläche abhandeln sollte, nicht die SQL-Anfrage. Denn die ausgegebenen Daten werden durch diese Anfrage verfälscht, bzw. sind plötzlich nicht mehr sortierbar. Man opfert viele Informationen, die dann auch noch mehr Rechenlast erzeugen, nur weil hier die Trennung zwischen Datenhaltung und Datenanzeige nicht vollzogen wurde.

Daher: Madman1209 hat schon recht, als guter Entwickler ist man in diesem Fall verpflichtet Einspruch zu erheben. Natürlich kann die Anforderung vom Kunden erfüllt werden - nur eben auf einem anderen Wege als der Kunde denkt, weil der vorgeschlagene Weg eben zu viele Nachteile hat. Die Aufgabe hat in diesem Fall nur dann eine Daseinsberechtigung, wenn man einen Drucker besitzt, der direkt SQL-Ergebnisse ausdruckt. Denn anderenfalls opfert man nur Daten. SQL-Statements sollten NIE für optische Gimmicks missbraucht werden, es sei denn, es ist eine explizite Anforderung, die auch trotz Widerspruch noch Bestand hat.

@Topic: Eine Lösung wurde ja schon geliefert, daher hier mal nur meine Gedanken zur Diskussion.

 

[Crumar]

Man lernt (in der Schule!) mit simplen Aufgaben. Führt Leute doch erstmal an etwas heran. Es geht hier um einen Schüler!

Man lernt auch nicht nur durch vorkauen. Eine Nachfolge Aufgabe könnte ja sein, zu erklären, warum das nicht sinnvoll ist oder es was für bessere Alternativen es gibt. Und wieso das so ist..

 

[Andreas_]

wie wäre das möglich?

Geht es wirklich um SQL oder handelt es sich um eine Aufgabe zu Oracles SQL-Plus?

Bei SQL-Plus ist das eine Berichtsoption mit der Funktion Break:
https://docs.oracle.com/cd/A91202_01/901_doc/server.901/a88827/ch43.htm

Seit einem Oracle-Lehrgang vor ca. 20 Jahren habe ich das nicht mehr benutzt ...