5
MySQL ROW-NUMBER auf bestimmte Zeile zugreifen
Hallo,
ich habe eine Tabelle die ich mit ROW_NUMBER auswerten möchte.
Also ich lasse folgenden Befehl laufen.
Das klappt auch gut.
Wie kann ich denn nun dieses benutzen um damit zu arbeiten. Also zum Beispiel wenn ich auf Zeile 1 auf Löschen klicke dann Zeile 1 auch gelöscht wird usw.
Da hänge ich gerade richtig und glaube dass ich hier ein Verständnisproblem habe. Es muss doch möglich sein dann weiter mit diesen Zeilennummern zu arbeiten. Ich habe gesucht, leider ohne Erfolg.
Danke
Grüße
MarFra
ich habe eine Tabelle die ich mit ROW_NUMBER auswerten möchte.
Also ich lasse folgenden Befehl laufen.
SELECT *, ROW_NUMBER() OVER(ORDER BY id) as RN FROM termine;Das klappt auch gut.
Wie kann ich denn nun dieses benutzen um damit zu arbeiten. Also zum Beispiel wenn ich auf Zeile 1 auf Löschen klicke dann Zeile 1 auch gelöscht wird usw.
Da hänge ich gerade richtig und glaube dass ich hier ein Verständnisproblem habe. Es muss doch möglich sein dann weiter mit diesen Zeilennummern zu arbeiten. Ich habe gesucht, leider ohne Erfolg.
Danke
Grüße
MarFra
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5455797662
Url: https://administrator.de/forum/mysql-row-number-auf-bestimmte-zeile-zugreifen-5455797662.html
Ausgedruckt am: 19.12.2024 um 16:12 Uhr
5 Kommentare
Neuester Kommentar
Nein das ist in SQL nicht möglich. Du kannst ROW_NUMBER() auch nicht in der WHERE-Kausel des selben Statements nutzen da es erst zur Laufzeit überhaupt existiert / Werte enthält. Diese Werte stehen aber nicht in der eigentlichen Datenbank-Tabelle, die existieren nur im Ergebnis.
Grundsätzlich hat jeder Datensatz i.d.R. einen Primärschlüssel und den verwendest du um mit deinem Front-End Datensätze zu schreiben.
PS: Natürlich kann man mit Subquerys die ROW_NUMBER() auch als Update-Kriterium nutzen aber das wäre ganz großer Schmu. Die ROW_NUMBER() ist variabel und nicht eindeutig! Zwischen Datenabruf und Update-Befehl kann sich der Inhalt der Tabelle ändern.
Grundsätzlich hat jeder Datensatz i.d.R. einen Primärschlüssel und den verwendest du um mit deinem Front-End Datensätze zu schreiben.
PS: Natürlich kann man mit Subquerys die ROW_NUMBER() auch als Update-Kriterium nutzen aber das wäre ganz großer Schmu. Die ROW_NUMBER() ist variabel und nicht eindeutig! Zwischen Datenabruf und Update-Befehl kann sich der Inhalt der Tabelle ändern.
1
Auch Hallo
Du hast doch für jede Zeile eine ID?! Die musst für dein DELETE oder UPDATE im WHERE verwenden.
Manuel
Du hast doch für jede Zeile eine ID?! Die musst für dein DELETE oder UPDATE im WHERE verwenden.
Manuel
1
@ukulele-7
DANKE! Das hat mir geholfen. Ist dass grundsätzlich so dass die Funktionsergebnisse nur angezeigt und nicht weiterverarbeitet werden können? Also wie kann ich den SQL z.B. sagen. Zähle alle Zeilen und ändere bei jeder Zeile die ID in die Zeilenummer.
Mit Primärschlüssel meinst du in meinem Fall die ID oder?
In meinem "kleinen" Fall denke ich kein Problem ABER das ist sehr gut zu wissen. Da werde ich auf jeden Fall dran denken.
Also Grundlegend ist es bei SQL so dass ich IMMER mit dem Primärschlüssel arbeiten sollte wenn ich etwas verändern möchte?
@manuel-r
Die Sache ist ja dass sich jedesmal wenn ich eine Zeile lösche oder eine neue hinzufüge die ID um 1 erhöht. Wie sollte ich denn das am besten angehen? Deswegen wollte ich ja die Zeilen mit ROW_NUMBER() Nummerieren da Zeile 1 ja immer Zeile 1. Hab ich da einen Denkfehler? Ist es auch SQL Standart dass man die Primärschlüssel immer A_I macht oder gibt es Szenarien wo man diesen manuell vergibt?
Ich danke euch beiden sehr. Das bringt mich wirklich weiter und beantwortet viele Fragen.
Einen schönen Abend euch!
Grüße
MarFra
da es erst zur Laufzeit überhaupt existiert / Werte enthält. Diese Werte stehen aber nicht in der eigentlichen Datenbank-Tabelle, die existieren nur im Ergebnis.
DANKE! Das hat mir geholfen. Ist dass grundsätzlich so dass die Funktionsergebnisse nur angezeigt und nicht weiterverarbeitet werden können? Also wie kann ich den SQL z.B. sagen. Zähle alle Zeilen und ändere bei jeder Zeile die ID in die Zeilenummer.
Grundsätzlich hat jeder Datensatz i.d.R. einen Primärschlüssel und den verwendest du um mit deinem Front-End Datensätze zu schreiben.
Mit Primärschlüssel meinst du in meinem Fall die ID oder?
PS: Natürlich kann man mit Subquerys die ROW_NUMBER() auch als Update-Kriterium nutzen aber das wäre ganz großer Schmu. Die ROW_NUMBER() ist variabel und nicht eindeutig! Zwischen Datenabruf und Update-Befehl kann sich der Inhalt der Tabelle ändern.
In meinem "kleinen" Fall denke ich kein Problem ABER das ist sehr gut zu wissen. Da werde ich auf jeden Fall dran denken.
Also Grundlegend ist es bei SQL so dass ich IMMER mit dem Primärschlüssel arbeiten sollte wenn ich etwas verändern möchte?
@manuel-r
Du hast doch für jede Zeile eine ID?! Die musst für dein DELETE oder UPDATE im WHERE verwenden.
Die Sache ist ja dass sich jedesmal wenn ich eine Zeile lösche oder eine neue hinzufüge die ID um 1 erhöht. Wie sollte ich denn das am besten angehen? Deswegen wollte ich ja die Zeilen mit ROW_NUMBER() Nummerieren da Zeile 1 ja immer Zeile 1. Hab ich da einen Denkfehler? Ist es auch SQL Standart dass man die Primärschlüssel immer A_I macht oder gibt es Szenarien wo man diesen manuell vergibt?
Ich danke euch beiden sehr. Das bringt mich wirklich weiter und beantwortet viele Fragen.
Einen schönen Abend euch!
Grüße
MarFra
Ja deine Denkweise ist falsch, sry wenn das jetzt harsch klingt. Erstmal ein paar Grundprinzipien:
- Eine Tabelle hat nie eine eigene Ordnung in irgend einer Form. Sortierung ist immer eine Eigenschaft bei der Ausgabe die in der Abfrage dann spezifisch gesetzt wird aber es gibt keine Default-Reihenfolge.
- Eine Tabelle hat auch keine eigene Datensatz ID (okay stimmt nicht immer zu 100% aber die ist für dich eigentlich nicht nutzbar), die wird in der Tabellen Definition von dir erst als Primary Key deklariert. Das DBMS sorgt dann dafür das die ID eindeutig sein muss, ansonsten kommt kein Datensatz rein.
- Format und Inhalt der ID sind völlig egal. Du kannst eine Zahl hoch zählen oder einfach zufällig wählen, eine Zeichenkette nutzen oder mehrere Spalten kombinieren. Das Ergebnis muss nur eindeutig sein.
- Zur ID gibt es immer einen Index und der sorgt für die Geschwindigkeit beim Wiederauffinden von Daten anhand der ID. Indexe haben eine eigene Sortierung!
Daraus ergibt sich das es ziemlich blödsinnig ist eine ID überhaupt zu ändern, das macht man eigentlich nicht. Würde man das tun müsste man auch jedes Mal den Index anpassen und zwar für alle Datensätze. Ganz zu schweigen von Fremdschlüsseln die auf deine ID zeigen, alles anpassen, alles in einer Aktion. Theoretisch können auch noch exportierte oder replizierte Daten einen Bezug zu deinen Daten haben, der geht in dem Moment verloren. Daraus ergibt sich dann auch das eine ID nicht der Sortierung dient sondern nur der Identifizierung.
Du kannst dir eine Spalte Zeilennummer basteln (eventuell auch als berechnete Spalte aber wir reden hier über MySQL) oder du kannst dir mit ROW_NUMBER() im Ergebnis eine Zeilennummer anzeigen lassen. Willst du aber den Datensatz bearbeiten dann ist diese Zeilennummer nichts wert weil in dem Moment wo die Abfrage durch gelaufen ist kann sie sich durch eine andere Aktion in der Datenbank (also z.B. ein anderer Benutzer) ändern weil ja jeder Datensätze einfügen, ändern oder löschen kann. Die Tabelle ist nicht gesperrt und deine Zeilennummer ist nur für dein Ergebnis zwingend gültig.
- Eine Tabelle hat nie eine eigene Ordnung in irgend einer Form. Sortierung ist immer eine Eigenschaft bei der Ausgabe die in der Abfrage dann spezifisch gesetzt wird aber es gibt keine Default-Reihenfolge.
- Eine Tabelle hat auch keine eigene Datensatz ID (okay stimmt nicht immer zu 100% aber die ist für dich eigentlich nicht nutzbar), die wird in der Tabellen Definition von dir erst als Primary Key deklariert. Das DBMS sorgt dann dafür das die ID eindeutig sein muss, ansonsten kommt kein Datensatz rein.
- Format und Inhalt der ID sind völlig egal. Du kannst eine Zahl hoch zählen oder einfach zufällig wählen, eine Zeichenkette nutzen oder mehrere Spalten kombinieren. Das Ergebnis muss nur eindeutig sein.
- Zur ID gibt es immer einen Index und der sorgt für die Geschwindigkeit beim Wiederauffinden von Daten anhand der ID. Indexe haben eine eigene Sortierung!
Daraus ergibt sich das es ziemlich blödsinnig ist eine ID überhaupt zu ändern, das macht man eigentlich nicht. Würde man das tun müsste man auch jedes Mal den Index anpassen und zwar für alle Datensätze. Ganz zu schweigen von Fremdschlüsseln die auf deine ID zeigen, alles anpassen, alles in einer Aktion. Theoretisch können auch noch exportierte oder replizierte Daten einen Bezug zu deinen Daten haben, der geht in dem Moment verloren. Daraus ergibt sich dann auch das eine ID nicht der Sortierung dient sondern nur der Identifizierung.
Du kannst dir eine Spalte Zeilennummer basteln (eventuell auch als berechnete Spalte aber wir reden hier über MySQL) oder du kannst dir mit ROW_NUMBER() im Ergebnis eine Zeilennummer anzeigen lassen. Willst du aber den Datensatz bearbeiten dann ist diese Zeilennummer nichts wert weil in dem Moment wo die Abfrage durch gelaufen ist kann sie sich durch eine andere Aktion in der Datenbank (also z.B. ein anderer Benutzer) ändern weil ja jeder Datensätze einfügen, ändern oder löschen kann. Die Tabelle ist nicht gesperrt und deine Zeilennummer ist nur für dein Ergebnis zwingend gültig.
1
@ukulele-7
Hi und danke für deine Antwort!
Das ist nicht harsch, das ist die Wahrheit.
Ich danke dir sehr für deine Zeit und merke dass ich falsch an die Sache rangegangen bin.
Das hat mir sehr geholfen und mich hoffentlich in die richtige Richtung geschubst.
DANKE DIR!
Hi und danke für deine Antwort!
Ja deine Denkweise ist falsch, sry wenn das jetzt harsch klingt.
Das ist nicht harsch, das ist die Wahrheit.
Ich danke dir sehr für deine Zeit und merke dass ich falsch an die Sache rangegangen bin.
Das hat mir sehr geholfen und mich hoffentlich in die richtige Richtung geschubst.
DANKE DIR!
