SQL Spalte verschieben

[LeKuchen]

Hallo zusammen,

vorab: Bitte fragt nicht warum!

Ich möchte eine Spalte in einer Datenbanktabelle (inkl. Daten) in der Reihenfolge per Scriptbefehl verschieben. (MS SQL 2000)

Gibt es dafür einen Befehl, so nach dem Motto:

ALTER TABLE [dbo].[tabelle] ALTER COLUMN MOVE oder so....

Im EnterpriseManager ist es ja einfach, da brauche ich die Spalte nur per Drag and Drop zu verschieben, aber wie lautet der Skriptbefehl dafür?

Gruß
LeKuchen

[Vinzenz Mai]

Hallo LeKuchen,

vorab: Bitte fragt nicht warum!

also frage ich dich nicht: Warum reicht nicht ein View mit geänderter Spaltenreihenfolge?

Ich möchte eine Spalte in einer Datenbanktabelle (inkl. Daten) in der Reihenfolge per Scriptbefehl verschieben. (MS SQL 2000)

Gibt es dafür einen Befehl, so nach dem Motto:

ALTER TABLE [dbo].[tabelle] ALTER COLUMN MOVE oder so....

nein, da gibt es nur {ADD|DROP}

Im EnterpriseManager ist es ja einfach, da brauche ich die Spalte nur per Drag and Drop zu verschieben, aber wie lautet der Skriptbefehl dafür?

Hehe, ich habe mir im Profiler angeschaut, was im Hintergrund abläuft:

Die Tabelle wird in eine temporäre Tabelle kopiert, anschließend wird die Tabelle mit DROP TABLE gelöscht, neu angelegt mit der neu festgelegten Spaltenreihenfolge, die Daten zurückkopiert, Indizes und ähnliches angelegt, aber kein ALTER TABLE ...

Ein Heidenaufwand für ein einfaches Ändern der Spaltenreihenfolge.

Freundliche Grüße

Vinzenz

[LeKuchen]

Hallo Vinzenz,

schön, dass sich ein Datenbankspezialist meldet...:o)

also frage ich dich nicht: Warum reicht nicht ein View mit geänderter Spaltenreihenfolge?

Lange Geschichte, kurz angerissen:
Versionsumstellung: DB-Tabelle wird dynamisch erzeugt aus einem Dictionary. Tabelle und Dictionary werden zur Sicherheit(!) miteinander abgeglichen. Software für die DB ist so aufgebaut, dass die ID-Spalten leider vorne sein müssen. Alte Version ist seit 2 Jahren draußen, ca. 40 Installationen mit Altdaten etc....Datenbankupdate muss über eine kleine Software/Skripte erfolgen.

Hehe, ich habe mir im Profiler angeschaut, was im Hintergrund abläuft:

Die Tabelle wird in eine temporäre Tabelle kopiert, anschließend wird die Tabelle mit DROP TABLE gelöscht, neu angelegt mit der neu festgelegten Spaltenreihenfolge, die Daten zurückkopiert, Indizes und ähnliches angelegt, aber kein ALTER TABLE ...

Ein Heidenaufwand für ein einfaches Ändern der Spaltenreihenfolge.

Hmpf. Scheiße. (Entschuldige diese Wortwahl kurz vor Weihnachten!) Ich habe es befürchtet. Weißt Du, was mit den Beziehungen der Tabelle passiert? Gehen die dabei verloren? Wahrscheinlich beim Drop Table, oder?

Gruß & Danke,
LeKuchen

[Frank (no reg)]

Hi,

es ist annähernd scheißegal in welcher Reihenfolge Spalten in der
Tabelle für den Benutzer (via Enterprise Manager oder was auch immer)
präsentiert werden. MS SQL speichert die Daten nach eigenem Gutdünken
in den Blöcken und Pages, wobei Festgrößenspalten am Anfang des Blockes
physikalisch abgelegt werden.

Führe dir einfach mal den Unterschied zwischen

SELECT Id, Name, Feldx, Feldy FROM ....
und
SELECT Name, Feldx, Feldy, Id FROM ....

vor Augen. (Wie mag wohl die Tabelle aussehen?)

Es gibt für die Lösung deines Problems definitiv eine alternative und
annähernd gleich oder weniger aufwändige Lösung. Denk nach!

Ciao, Frank

[Rouven]

Hi,

also das mit dem Aufwand würde ich pauschal so nicht sagen. Was ist, wenn du ein schlecht geschriebene Alt-Software hast, die mittels SELECT * arbeitet und dann einfach hofft, das alles in der richtigen Reihenfolge kommt. Vielleicht hast du nichtmal den Quellcode von dem Ding oder was auch immer. Wobei ich dann Vinzenz zustimme, vielleicht wäre ein View angebrachter...

MfG
Rouven

[Auge]

Hallo

Was ist, wenn du ein schlecht geschriebene Alt-Software hast, die mittels SELECT * arbeitet und dann einfach hofft, das alles in der richtigen Reihenfolge kommt.

Mal 'ne unbedarfte Frage: Sollte es in diesem Fall nicht reichen, die Felder des Ergebnisses mit ihrem Namen anzusprechen? Als (hier vielleicht unpassendes) Beispiel PHP: $row = mysql_fetch_assoc(...). Die Felder werden also nicht numerisch $row[1], sondern explizit mit ihrem Namen $row['feldname'] angesprochen.

Da sollte es doch egal sein, in welcher Reihenfolge die Spalten in der DB stehen (zwecks späterer Strukturänderungen), oder?

Tschö, Auge

[Rouven]

Hi,

das ist im Prinzip richtig, sofern man es im Voraus darauf anlegt. Das heißt auch, dass man bei einer gruppierte Abfrage, in der z.B. ach MAX(xyz) verwendet wird, dieser Spalte mit AS einen Namen geben müsste, sonst dürfte das ein Problem geben.

MfG
Rouven

[Ilja]

yo,

Hmpf. Scheiße. (Entschuldige diese Wortwahl kurz vor Weihnachten!) Ich habe es befürchtet. Weißt Du, was mit den Beziehungen der Tabelle passiert? Gehen die dabei verloren? Wahrscheinlich beim Drop Table, oder?

da gilt es erst einmal zu unterscheiden, ob es sich um foreign keys der besagten tabelle handelt oder aber um fk von anderen tabellen, die auf die besagt tabelle verweisen. je nachdem welche fk du hast, könnte es probleme beim löschen der tabelle geben.

eine anderer lösungsansatz wäre, eine zusätzliche spalte in der tabele anzulegen, die werte dort reinzukopieren, dessen spalte vor der id spalte stehen und diese spalte dann löschen, damit die id vorne steht.

Ilja

[Chris]

Hallo Vinzenz,

Ein Heidenaufwand für ein einfaches Ändern der Spaltenreihenfolge.

Der sich aber ggf. für die Verwendung eines neunen Vollindex über mehrere Spalten lohnen kann. Wie das nun genau bei MSSQL ist, weiß ich nicht.

Bei Sybase- und bTrieve-Datenbanken konnte man durch die passende Reihenfolge eine erhebliche Beschluenigung der Indexpflege erreichen.

LG
Chris