Datensätze in einer Spalte durchnummerieren

[Xea]

Hallo,

ich habe eine Datenbank mit rund 8500 Datensätzen. In der Spalte "post_id" sind viele verschiedene Zahlen mit teils großen Lücken, da es sich um Überreste von Forenbeiträgen handelt. Nun möchte ich die Werte der Spalte "Post_id" durch sauber durchnummerierte Warte ersetzen, welche bei 15 beginnen. Sprich:

Aus 6, 23, 145, 146, 147, 148, 152, usw...

möchte ich

15, 16, 17, 18, usw... machen. Wie realisier ich das? Am besten wärs natürlich, die Werte einfach per SQL-Befehl zu ändern, aber auch eine andere Lösung mit php oder löschen und neu erstellen der Spalte "post_id" wär mir recht.

Ich hoffe, ihr könnt mir helfen und bedanke mich schonmal im Vorraus.

[mtth]

alter table test add column (id int primary key auto_increment);

[Xea]

Das funktioniert schonmal super, danke! Aber die Datensätze sind in der falschen Reihenfolge, wenn ich den Befehl ausführe. Habs jetzt mal mit

SELECT * FROM phpbb_posts_backup ORDER BY phpbb_posts_backup.post_time ASC;
ALTER TABLE phpbb_posts_backup ADD COLUMN (post_id int PRIMARY KEY AUTO_INCREMENT);

versucht, da ich die Datensätze mit der Spalte post_time in die richtige Reihenfolge bringen kann. Aber wenn ich den Befehl ausgeführt habe, sind die Datensätze trotzdem in der alten, falschen Reihenfolge. Wie kann ich das Problem jetzt lösen?

Edit: Ich habs mit der Sortierung schonmal geschafft. Allerdings werden die Datensätze ab 1 nummeriert, ich möchte sie aber ab 15 nummeriert haben.

[mtth]

Vielleicht kannst Du mal 10 Datensätze hier einstellen, oder Beispiele, damit man besser sehen kann, was das Problem ist.

drop table test1;
create table test1 (post_id int , text text);
insert into test1 values ('15','laberlaber'),('173','loderloder'),('234','r abarber'),('256','obstsalat'),('178','Pflaumenmus' );
alter table test1 add column id int auto_increment primary key;
select * from test1;

In diesem kleinen Test werden die Datensätze nicht in der Reihenfolge verändert, nur nummeriert.

Das Problem mit der 15 würde ich einfach so lösen, dass ich 14 Datensätze vorne einfüge, die irgendeinen Erklärtext enthalten.

[Falk Prüfer]

Hallo,

...Nun möchte ich die Werte der Spalte "Post_id" durch sauber durchnummerierte Warte ersetzen, welche bei 15 beginnen. Sprich:

Aus 6, 23, 145, 146, 147, 148, 152, usw...

möchte ich

15, 16, 17, 18, usw... machen.

Warum? Normalerweise gibt es dafür keinen vernünftigen Grund, geschweige denn eine Notwendigkeit. Außerdem ist sowas in einem DBMS immer sehr kurzlebig. Spätestens nach dem nächsten DELETE hast du wieder eine Lücke.
Und nur mal so ... das Feld Post_id sieht verdammt nach einem Schlüsselfeld für einen Foreign-Key aus - hast du dir wirklich Gedanken gemacht welche Konsequenzen es hat dieses Feld zu ändern?

... Aber die Datensätze sind in der falschen Reihenfolge, wenn ich den Befehl ausführe. Habs jetzt mal mit

In SQL gibt es keine falsche Reihenfolge! Die Reihenfolge der DS wird bei der Abfrage miitels ORDER BY angegeben. Wie die DS tatsächlich physisch in der DB abgelegt sind ist absolut irrelevant.

Gruß Falk

[Falk Prüfer]

Hallo,

...Das Problem mit der 15 würde ich einfach so lösen, dass ich 14 Datensätze vorne einfüge, die irgendeinen Erklärtext enthalten.

...und bei jeder Abfrage mußt du dann dran denken die DS mit ID < 15 nicht zu berücksichtigen, da es nur "Dummys" sind!? Was ist denn das für eine Grütze... Das hat NICHTS mit sauberer Datenhaltung zu tun, das ist unsinnige Murkelei und gehört in die Schublade "Datenbankrogrammierung für DAUs"!

Gruß Falk

P.S.: Sorry, wenn das etwas drastisch formuliert ist, aber ich möchte eindringlich auf die Unsinnigkeit solchen Tuns hinweisen!

[mtth]

Falk: Die Dummies kann man ja nachher wieder löschen, wo liegt das Problem?
Man kann sie auch sinnvoll nutzen.

Wenn Du weißt wie es geht dann sags.

[Falk Prüfer]

Falk: Die Dummies kann man ja nachher wieder löschen, wo liegt das Problem?

Wenn das deine übliche Vorgehensweise ist, dann kannst du das so machen. Das Problem ist es offensichtlichen Neueinsteigern solche "Tricks aus der unteren Schublade" als Lösung zu präsentieren ohne auf die technischen Nebeneffekte hinzuweisen. Und bei 15 ist das vlt. kostentechnisch noch im Rahmen aber was macht er mit deinem Lösungsansatz wenn die nächste Tabelle bei 5.000.000 beginnen soll?

...Man kann sie auch sinnvoll nutzen.

Ja klar

...Wenn Du weißt wie es geht dann sags.

Wie ich bereits sagte, für die "Neunummerierung" einer ID-Spalte gibt es für mich keinen vernünftigen Grund.
Wenn es in der Darstellung nur darum geht eine schöne, bei 15 beginende fortlaufende Nummer, unabhängig von der Sortierung, zu haben, dann hab ich dafür auch eine Lösung:
[highlight=sql]
set @lfdNr = 14;

select @lfdNr:=@lfdNr+1 lfdNr, a.*
from <tabelle> a
order by a.<spalte>;
[/highlight]
Ganz ohne Dummy-Zeilen

Gruß Falk

[mtth]

Na, ob das nun einfacher ist?
Das ist 'ne ganze Spalte Dummys, für einen Anfänger auch nicht leicht zu überblicken.

In diesem Fall ist es doch einsichtig, warum die Datensätze nummeriert werden sollen.

[Falk Prüfer]

...In diesem Fall ist es doch einsichtig, warum die Datensätze nummeriert werden sollen.

Achso, Warum denn? Klär mich bitte auf, hab da wohl was übersehen.

Und lass dir bitte eine gute Begründung einfallen, die den Aufwand rechtfertigt in einer DB schwer wartbare Daten vorzuhalten (und eine fortlaufende Numerierung in der "richtigen" Reihenfolge ist in einer "lebenden" DB nunmal schwer wartbar), wenn diese mit einfachen Mitteln bei der Ausgabe aus bestehenden Daten erzeugt werden können.

[mtth]

Nun möchte ich die Werte der Spalte "Post_id" durch sauber durchnummerierte Werte ersetzen, welche bei 15 beginnen.

Ich denke, dass die Optik der zerissenen Werte den Anwender sehr bei der Anwendung stört und eine sichtbare Orientierung gewünscht wird, die beim ersten Blick klarmacht, das die Reihenfolge "stimmt".
Lücken werden als "unsauber" empfunden. Die Hilfsabfrage @lfdNr ist natürlich praktischer, überzeugt den Anwender aber nicht davon, dass die Daten noch in der richtigen Reihenfolge sind, so wie das bei den Posts ja sein soll. Eine durchnummerierte feste Spalte macht Veränderungen "augenfällig" .

Letztlich ist meine id Spalte dasselbe wie Deine lfdNr, nur bleibt sie an die Tabelle gebunden. Kann man auch mit deiner Methode erreichen.
Wegen der Wartbarkeit: Wenn durch einen Fehler die post_id gelöscht würde, gäbe es in der Tabelle von Xea keine Möglichkeit mehr, die ursprünglich Reihenfolge wiederherzustellen. Die von mir vorgeschlagene id autoincrement hilft, mit der Tabelle zu arbeiten, ohne die post_id überhaupt anzutasten.

Insofern hast Du Recht, meine Antwort ist für Laien, aber nicht aus der untersten Schublade

[mtth]

Hallo,
Das hat NICHTS mit sauberer Datenhaltung zu tun"!

Falk, ich gehe das Ganze aus einer archivischen Sicht an, und da hat das spurlose Löschen von Datensätzen wiederum überhaupt nichts mit einer sauberen Datenhaltung zu tun. Für jeden gelöschten Datensatz muss ein Verweis entstehen, wann, von wem und warum ein Datensatz gelöscht wurde, möglichst auch mit einem Hinweis darauf, was er enthielt und wie er evntl. rekonstruiert werden kann. Die Ordnungsnummer eines Datensatzes dürfte also niemals verschwinden(wie es bei Datenbanken oft der Fall ist) es müßte stattdessen ein Hinweis eingefügt werden, warum der Datensatz gelöscht wurde.
Datenbanken umgehen diese archivische Grundpflicht sehr oft, wegen ökonomischer Notwendigkeiten, verwenden aber große Kapazitäten darauf, Operationen aufzuzeichnen und ggf rückgängig zu machen.
Die scheinbare Datenoptimierung wird also mit einer sehr aufwendigen Registratur erkauft und produziert Fehlerquellen.
Eigentlich ist dies nicht mehr notwendig, da die Speicherkapazitäten unbegrenzt sind und Verweise und Kassationen denselben Aufwand benötigen, wie die betroffenen Datensätze. Man könnte also ebenso jede Datenbank als Backup bestehen lassen. Beim Elektronikmarkt um die Ecke gibts bereits Terabite-Platten zum Schnäppchenpreis. Optimierung ist insofern veraltet.

Die von Dir beklagte "erschwerte Wartung" beruht meiner Ansicht nach darauf, dass Datenbanken heutzutage schwerwiegende archivische Fehler produzieren und in Kauf nehmen, um an Performance zu gewinnen.

Wenn man eine Datenbank als Prozess begreift, ok.
Dann ist sie nur ein Tool (wende ich selbst auch an) und dann kann man sie ad hoc verwerfen.

Wenn eine Datenbank ein "Gedächtnis" sein soll, sollte der Fehler der "Optimierung" genau überlegt sein, sie sollte besser "tote" Information mitführen und diese nicht einer vordergründigen Optimierung opfern.

Beide Optionen schliessen sich nicht aus und man sollte beide verwirklichen.
Die prozessegebundene Datenbank liefert Information, die für den aktuellen Prozess notwendig sind, die archivische Datenbank liefert Information über den Prozess und dessen Werden.

Nötig sind beide.

[Xea]

Danke für die vielen Antworten. Hab die Datensätze über "Operationen" sortiert, dadurch waren sie in der richtigen Reihenfolge, welche richtig war, um die Datensätze richtig auszulesen. Hätte ich sie nicht sortiert, wären sie am Ende kreuz und quer gemischt. Die Nummerierung ab 15 hab ich mittels der Dummies gelöst. Einfach, aber eine super Lösung. Dass ich nicht selbst drauf gekommen bin... Es hat also alles funktioniert! Danke nochmal, vor allem an mtth!

[Falk Prüfer]

Hallo mtth,

ich möchte das Ganze jetzt nicht in die Länge ziehen, außerdem ist es OffToppic und Xea hat ja sein Problem mit deiner Hilfe gelöst. Trotzdem noch ein paar Anmerkungen .

Ich denke, dass die Optik der zerissenen Werte den Anwender sehr bei der Anwendung stört und eine sichtbare Orientierung gewünscht wird, die beim ersten Blick klarmacht, das die Reihenfolge "stimmt".

Was ist bei SQL "die Reihenfolge"? Es gibt keine "Reihenfolge" für Datensätze, es sei denn sie wird durch das ORDER BY in einer Abfrage vorgegeben.

...Die Hilfsabfrage @lfdNr ist natürlich praktischer, überzeugt den Anwender aber nicht davon, dass die Daten noch in der richtigen Reihenfolge sind, so wie das bei den Posts ja sein soll. Eine durchnummerierte feste Spalte macht Veränderungen "augenfällig" .

Kann ich nur meine obige Frage wiederholen: Was ist bei SQL "die Reihenfolge"?

...Insofern hast Du Recht, meine Antwort ist für Laien, aber nicht aus der untersten Schublade

Naja, aber irgendwie passt sie mit dem Einfügen und Löschen von "Dummy"-Datensätzen so gar nicht zu deinem Statement über archivische Datenhaltung.
Wenn es denn dann schon eine neue explizite "Sortierspalte" sein muß, dann wäre ein Update auf Grundlage meiner lfdNr wohl doch besser gewesen.
[highlight=sql]
ALTER TABLE phpbb_posts_backup ADD COLUMN (
another_id int);

set @lfdnr = 14;

update phpbb_posts_backup set
another_id = @lfdnr:=@lfdnr+1
order by post_time ASC;
[/highlight]

...Die Nummerierung ab 15 hab ich mittels der Dummies gelöst. Einfach, aber eine super Lösung.

Einfach vielleicht, aber ...

...wie gesagt, ich will das eigentlich nicht weiter breittreten.

Gruß Falk

[mtth]

Reihenfolge

Was ist bei SQL "die Reihenfolge"? Es gibt keine "Reihenfolge" für Datensätze, es sei denn sie wird durch das ORDER BY in einer Abfrage vorgegeben.

Gruß Falk

Hallo Falk,

Es gibt in jedem Falle eine Reihenfolge der Datensätze, im mindesten die des Zeitpunktes ihres Entstehens, darüber hinaus die Folge der Bearbeitung oder eine Sinnfolge oder auch bloss die Folge der Eingabe.

Ohne eine Ursprungsreihenfolge der Daten ist eine Datenbank völlig wertlos. ORDER BY ist bloss ein willkürlicher Bearbeitungsschritt.



Gruß mtth