Suche SQL-Befehl

[Wanginator]

Habe eine große Datenbanktabelle mit Einträgen der Art:

id name
1 a
2 e
3 c
4 b
5 d

wobei id der unique primary key mit auto_increment ist. nun möchte ich die gesamte tabelle nach name sortieren, also so:

id name
1 a
4 b
3 c
5 d
2 e

und dann die id dementsprechend neu vergeben:

id name
1 a
2 b
3 c
4 d
5 e

Gibts dafür einen einfachen (oder auch komplexeren) SQL-Befehl, mit dem sich das einfach und vor allem inplace lösen lässt. Könnte natürlich auch alle Zeilen auslesen, sortieren und wieder einfügen.

[ethrandil]

Sehe ich es richtig, dass du innerhalb der Tabelle die IDs ändern willst, sodass sie anschließend die alphabetische Ordnung (lexikalisch oder lexikographisch? xD) repräsentieren?
Oder willst du das in einer neuen Tabelle haben?

- eth

[Gast]

Darf man fragen wozu das gut sein soll? Ich würde eher nen Index auf die Strings legen, dann kannst du auch schnell alphabetisch drauf zugreifen.

[Wanginator]

Sehe ich es richtig, dass du innerhalb der Tabelle die IDs ändern willst, sodass sie anschließend die alphabetische Ordnung (lexikalisch oder lexikographisch? xD) repräsentieren?
Oder willst du das in einer neuen Tabelle haben?

ja ersteres.

Darf man fragen wozu das gut sein soll? Ich würde eher nen Index auf die Strings legen, dann kannst du auch schnell alphabetisch drauf zugreifen.

es geht nicht primär um die zugriffszeit, sondern darauf, dass die paar-relation id<->name konsistent bzgl. der lexigrographischen Ordnung ist. ich glaub, ich werd wohl nicht darum kommen, die daten auszulagern und wieder einzufügen...

[ethrandil]

es geht nicht primär um die zugriffszeit, sondern darauf, dass die paar-relation id<->name konsistent bzgl. der lexigrographischen Ordnung ist. ich glaub, ich werd wohl nicht darum kommen, die daten auszulagern und wieder einzufügen...Ich kann mir spontan keinen Anwendungsfall vorstellen. Macht es vielleicht sinn in deinem Fall die ID wegzulassen und den Namen als primärschlüssel zu verwenden?

- eth

[darph]

es geht nicht primär um die zugriffszeit, sondern darauf, dass die paar-relation id<->name konsistent bzgl. der lexigrographischen Ordnung ist. ich glaub, ich werd wohl nicht darum kommen, die daten auszulagern und wieder einzufügen...Blöde Frage meinerseits: Warum solltest du das wollen?

Je nach Größe des Datenbestandes kann sowas ja... eh... aufwändig sein. Außerdem sorgt sowas ganz schnell für Inkonsistenzen, wenn irgendwas auf id 5 verweist und a erwartet, aber jetzt e geliefert bekommt.

SELECT * FROM tabelle ORDER BY name ASC - inwiefern wäre die Reihenfolge der ID denn jetzt für deine Applikation relevant?

[Wanginator]

vielleicht lässt es sich auch anders lösen, aber folgendes ist das ziel: das paar (id, name) soll konsistent bzgl. lexikographischer sortierung sein. man soll die namen über die id finden können, da mit der id berechnung durchgeführt werden (+,-,*). nun kommen abundzu einige neue datensätze dazu (z.b. 10) und damit das ganze konsistent bleibt soll ein skript nun loslaufen und die ids neu berechnen.

[Gast]

Berechnungen mit den IDs? *Zehennägel hochrollt*

Was auch immer du damit vor hast. Es gibt einen besseren Weg ;)

[kloffy]

Möglicherweise kann man es mit einem "REPLACE INTO ... SELECT ..." hinkriegen. Habs jetzt aber auf die Schnelle nicht geschafft, also trivial ist es sicher nicht.

[darph]

vielleicht lässt es sich auch anders lösen, aber folgendes ist das ziel: das paar (id, name) soll konsistent bzgl. lexikographischer sortierung sein. man soll die namen über die id finden können, da mit der id berechnung durchgeführt werden (+,-,*). nun kommen abundzu einige neue datensätze dazu (z.b. 10) und damit das ganze konsistent bleibt soll ein skript nun loslaufen und die ids neu berechnen.
Ähm.

Wenn du das sortiert aus der Datenbank ziehst... und das Ergebnis in eine Liste oder ein Array packst... kannst du dann nicht einfach den Index des Arrays hernehmen? Weil... das paßt auf jeden Fall, sortiert ist es ja schon.

[Gast]

...also trivial ist es sicher nicht.Ich glaube auch gar nicht, dass es dafür eine direkte Lösung gibt, denn das ist ja kein Anwendungsfall für ein relationales Datenbankmodell. Mir sträuben sich die Nackenhaare, wenn ich lese, dass jemand die Daten von den zugehörigen Schlüsseln trennen und dann anderen Schlüsseln zuweisen will.

[kloffy]

Ich glaube auch gar nicht, dass es dafür eine direkte Lösung gibt, denn das ist ja kein Anwendungsfall für ein relationales Datenbankmodell. Mir sträuben sich die Nackenhaare, wenn ich lese, dass jemand die Daten von den zugehörigen Schlüsseln trennen und dann anderen Schlüsseln zuweisen will.
Ja, ich kann auch nicht nachvollziehen wozu man sowas brauchen könnte. Aber da ich die Anwendung nicht kenne, gehe ich einfach mal davon aus das Wanginator schon seine Gründe dafür hat.

[Wanginator]

Wenn du das sortiert aus der Datenbank ziehst... und das Ergebnis in eine Liste oder ein Array packst... kannst du dann nicht einfach den Index des Arrays hernehmen? Weil... das paßt auf jeden Fall, sortiert ist es ja schon.

jo, das ist die bisherige lösung. ist aber nicht "inplace", da die daten ja ausgelagert werden. dachte es gäbe evtl. eine schöne lösung über SQL, aber scheint wohl ein spezielles problem zu sein.

ja, mit relationalem modell hats nicht mehr viel zu tun. es sei zudem noch erwähnt, dass es die einzige tabelle sei, also keine relationen über mehrere entitäten. somit werden auch keine funktionalen abhängigkeiten verletzt.

[Pompos]

Ich glaub nicht, dass das möglich ist.

Aber warum packst du die Daten nicht einfach in eine neue Tabelle (table-temp) so wie du sie gern sortiert haben möchtest? Die IDs kannst du dann ja weiterhin als Schlüssel deklarieren und mit auto_increment erstellen.
Wenn alle Daten in der neuen (temporären) Tabelle sind, löscht du die original Tabelle und benennst die temproräre Tabelle in den Namen der originalen Tabelle um.