Tabelle neu nummerieren

[schnegg]

[quote]

hallo forum,

ich habe eine mysql-tabelle adressen.tblwohnung.
in dieser tbl stehen Leute mit ihrer wohnanschrift drin.

muster:

row_num Nr Mieter AltWohnung NeuWohnung Einkommen
0 0 Schulze München Berlin 1000,00
0 1 Bauer Paris London 1750,00
0 2 Meier Dresden Hamburg 1200,00
0 3 Stein Dresden Pirmasens 950,00

die leute haben die wohnung gewechselt.

aus einer csv-datei werden ständig neue daten importiert.
innerhalb der csv haben die neuen daten natürlich eine nummerierung, nämlich die zeilennummer.
das bedeutet, daß die zeilennummer 1 importiert wird, obwohl ein datensatz 1 bereits existiert. wenn Nr als 'primary key' definiert ist,
geht das auch gar nicht. Darum habe ich Nr mit einem einfachen Index belegt. jetzt klappt es, doch jetzt stehen zwei datensätze 1 in der tbl.
selbst dann, wenn die zeilennummer nicht mit importiert wird, es muß trotzdem neu nummeriert werden.
im moment muß ich das manuell tun, doch ich hätte dafür gerne einen code.

auf einer webseite fand ich dieses codestück:

SELECT ROW_NUMBER() OVER(ORDER BY CustomerID, OrderDate DESC) AS RowNum,
CustomerID,
SalesOrderID,
OrderDate,
SalesOrderNumber,
SubTotal,
TotalDue
FROM Sales.SalesOrderHeader

das habe ich umgeformt zu:

SELECT ROW_NUMBER() OVER(ORDER BY Einkommen) AS row_num, AltWohnung, NeuWohnung FROM Adressen.Wohnung;

ROW_Number() soll die Zeilen nummerieren und seinen wert in row_num ablegen. row_num ist ein integer und gar nicht indexiert.

wird aber nichts. statt dessen bekomme ich einen Fehler "1064". die syntax stimmt nicht. ich solle im handbuch nachschlagen. ROW_Number() steht nicht in meiner Litheratur. das muß gegoogelt werden.

mfg,
babsy

[quote]

[Altrea]

Hallo,

wenn man schon auf die Idee kommt, einen Schlüssel neu durchnummerieren zu müssen, dann hat man sich bereits verrannt.
Ein Schlüssel in einer Datenbank hat nur den einen Zweck, einen Datensatz eindeutig zu referenzieren und damit auch effizienter finden zu können.
In aller Regel ändert ein Datensatz also niemals seinen Schlüssel. Selbst Lücken in der Durchnummerierung durch gelöschte Datensätze sind teil des Kozepts.

In deinem Fall würde ich mir ansehen, wo die Daten herkommen und wie diese in die Datenbank überführt werden sollen.
Wenn eine Person nur die Wohnung ändert, so hast du im besten Fall zwei Stammdaten Tabellen (Mieter und Wohnungen) und referenzierst über die jeweilige ID der Stammdatentabelle.
Bei Mietern und Wohnungen würde ich eine n:m Beziehung sehen, daher muss für die Referenzierung eine zusätzliche Tabelle her.

Wieso wird hier überhaupt der Umweg über eine csv Datei gegangen und das ganze nicht direkt über eine Anwendung in der Datenbank gepflegt?
Wenn an der csv Datei festgehalten werden soll würde ich auf jeden Fall hergehen und für den Import eine eigene Anwendung schreiben, die die Daten sauber in die Datenbank überführt.
Ein schnöder csv zu mysql import direkt über mysql ist hier nicht mächtig genug, oder nur über viel Aufwand über zusätzliche Trigger und Prozeduren zu einem sauberen Datenbankdesign hinzuwurschtenn.

mit freundlichen Grüßen,
Altrea

[Nobbie]

im moment muß ich das manuell tun, doch ich hätte dafür gerne einen code.

Und wozu?

Wozu brauchst Du eine Zeilennummer in der SQL Tabelle? Welche Funkion soll die haben? Du brauchst einen Primary Key (den solltest Du grundsätzlich und ausnahmslos und immer und ewig "id" nennen und als Primary Key mit AUTO INCREMENT anlegen), die Zeilennummer aus der CSV Datei solltest Du ignorieren, wird nicht benötigt und stört allenfalls.

Die Reihenfolge, wie nachher die Datensätze ggf. angezeigt oder verarbeitet werden, wird ausnahmslos durch "ORDER By ...." Klauseln festgelegt. Eine Zeilennummer oder ähnliches kennt SQL nicht.

WIe Altrea schon schrieb, der Primary Key hat nur die Funktion als Primary Key, das ist nur eine eindeutige Nummer, ohne jeden weiteren Sinn. Das ist keine Zeilennummer, keine Hausnummer, keine Tageszahl, kein nichts kein gar nichts. Das ist einer der wichtigsten Codd'schen Leitsätze (Codd war Datenbank Theoretiker) "The key is the key and nothing but the key".

Also brauchst Du keine Neunummierung, Du brauchst auch keine bestimmte Reihenfolge beim Primary Key, es ist egal, ob es "Lücken" gibt, einzig und allein hat jeder Datensatz eine eigene "id" und sonst nichts. Mit dem Primary Key rechnet man nicht, man leitet keine Eigenschaften her, man benutzt ihn ausschließlich als "Referenz" zu den Daten. Unterschiedliche Datensätze haben unterschiedliche id's. Das ist alles.

[schnegg]

das mit den key's hätte ich gar nicht schreiben sollen, gebt mir info's zu der Funktion row_number(). warum läuft das nicht bei mir ?

[Altrea]

Vielleicht weil die Quelle von der du diese Funktion hast von MSSQL Server handelt und nicht von MySQL/MariaDB?

BTW: Quellen bitte immer mitangeben: => https://www.sqlshack.com/overview-of-the-sql-row-number-function/

MariaDB kennt mitlerweile (ab Version 10.2) zwar auch eine ROW_NUMBER() Funktion, aber ob du MariaDB 10.2 einsetzt geht aus deinen Informationen nicht hervor (laut deinem Profil nutzt du noch XAMPP 1.8.3 was sehr alt wäre).
Ansonsten kann ich nur auf das Manual verweisen: https://mariadb.com/kb/en/library/row_number/

[Nobbie]

das mit den key's hätte ich gar nicht schreiben sollen, gebt mir info's zu der Funktion row_number(). warum läuft das nicht bei mir ?

Du hast die falsche Einstellung. Du solltest dankbar sein, dass wir Dich auf den richtige Pfad bringen. Stattdessen einer Funktion hinterher zu hecheln, die dabei hilft, das richtige Datendesign zu zerstören, kann nicht wirklich Dein Ziel sein. Gehe doch auf unsere Beiträge ein und lasse uns gemeinsam das richtige Datenmodell und die richtige Funktion implementieren. Ich helfe Dir gerne dabei und wahrscheinlich kannst und wirst Du viel dabei lernen.

Davon hast Du zehn Mal mehr, als weiterhin "Datenmüll" zu programmieren. Mit dem falschen Ansatz kommst Du immer sehr schnell an die Grenzen und genau da bist Du jetzt schon angelangt, weil Du eine (sinnlose) Funktion suchst, die alle Zeilennummern neu berechnet. Das ist leider total verfehlt.