Oracle: Spaleten verschieben bzw. an bestimmter Position einfügen
- Themenstarter Gray
- Beginndatum
Nico Graichen
Erfahrenes Mitglied
Hi,
Ich kann dir zwar bei deinem eigentlichen Problem nicht helfen, aber mal eine Frage dazu:
Für was braucht man denn sowas?
Mir fällt beim besten willen nicht ein UseCase ein.
Ich kann dir zwar bei deinem eigentlichen Problem nicht helfen, aber mal eine Frage dazu:
Für was braucht man denn sowas?
Mir fällt beim besten willen nicht ein UseCase ein.
ishino
Erfahrenes Mitglied
An welcher Stelle der Tabelle eine Spalte per Definition steht ist ungefähr genauso interessant wie die Frage, welche Daten in der 4. Zeile der Tabelle stehen...
Wenn Dir die Reihenfolge nicht paßt, dann gebe Deinen Anfragen halt eine entsprechende Selektionsliste mit (SELECT b,a,c FROM tab) und fertig. Außerdem sollte man sich im Zusammenhang mit Datenbanktabellen von dem Verständnis einer "Tabelle", wie man ihn aus Excel oder sowas kennt, verabschieden. Die Reihenfolge der Spalten und Zeilen ist bei Excel möglicherweise interessant, im Zusammenhang mit Datenbanktabellen ist sie piepegal.
EDIT: Um den OP ein wenig in Schutz zu nehmen: Es gibt Konstellationen, in denen eine bestimmte Reihenfolge der Spalten erwünscht ist. Hinsichtlich der Effizienz bei der Speicherung (Stichwort: NULL-Werte) kann das unter Umständen eine Rolle spielen. Wenn es nur um Kosmetik geht, spielt sie überhaupt keine...
Wenn Dir die Reihenfolge nicht paßt, dann gebe Deinen Anfragen halt eine entsprechende Selektionsliste mit (SELECT b,a,c FROM tab) und fertig. Außerdem sollte man sich im Zusammenhang mit Datenbanktabellen von dem Verständnis einer "Tabelle", wie man ihn aus Excel oder sowas kennt, verabschieden. Die Reihenfolge der Spalten und Zeilen ist bei Excel möglicherweise interessant, im Zusammenhang mit Datenbanktabellen ist sie piepegal.
EDIT: Um den OP ein wenig in Schutz zu nehmen: Es gibt Konstellationen, in denen eine bestimmte Reihenfolge der Spalten erwünscht ist. Hinsichtlich der Effizienz bei der Speicherung (Stichwort: NULL-Werte) kann das unter Umständen eine Rolle spielen. Wenn es nur um Kosmetik geht, spielt sie überhaupt keine...
Zuletzt bearbeitet:
Exceptionfault
Erfahrenes Mitglied
Die Reihenfolge von Spalten kann sehr wohl von Interesse sein. Wie Ishino richtig schreibt, geht es vor allem um eine effiziente Speicherung. Bei neueren Oracle Versionen (9i, 10g) fällt dies jedoch nicht mehr so sehr ins Gewicht.
Ein anderer wichtiger Grund können Entwicklungsrichtlinien sein. Beispiel:
- NOT NULL Spalten immer von NULL Spalten.
- Primary Key ganz vorne
- Spalten mit fester Feldlänge(Date) vor Spalten variabler Länge
Nun aber zu deinem Problem. Spalten können in Oracle nur hinten angefügt werden. Im Grunde gibt es zwei mehr oder weniger einfache Möglichkeiten eine Spalte an einer beliebigen Stelle in einer Tabelle zu "erzeugen".
1.) Eine neue Tabelle mit der gewünschten Struktur anlegen
Die Daten mittels INSERT as SELECT kopieren.
Alte Tabelle DROPPEN, neue Tabelle umbenennen
Constraints, Trigger etc. neueinspielen bzw. neukompilieren
2.) ... läuft auf das selbe heraus, genutzt wird jedoch das PL/SQL Package DBMS_REDEFINITION
Der Nachteil der 1. Methode ist der u.u. große manuelle Aufwand wenn viele Objekte von der Tabelle abhängig sind. Die 2. Methode kümmert sich automatisch um alle abhängigen Objekte. Änderungen die während dem Datenkopieren gemacht werden, werden vom PL/SQL Package sogar nachgezogen, d.h. DBMS_REDEFINITION kann ohne Wartungsfenster im Live Betrieb eingesetzt werden. Die Doku hierzu ist nur leider nicht ganz trivial...
http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_redefi.htm#sthref5656
Ein anderer wichtiger Grund können Entwicklungsrichtlinien sein. Beispiel:
- NOT NULL Spalten immer von NULL Spalten.
- Primary Key ganz vorne
- Spalten mit fester Feldlänge(Date) vor Spalten variabler Länge
Nun aber zu deinem Problem. Spalten können in Oracle nur hinten angefügt werden. Im Grunde gibt es zwei mehr oder weniger einfache Möglichkeiten eine Spalte an einer beliebigen Stelle in einer Tabelle zu "erzeugen".
1.) Eine neue Tabelle mit der gewünschten Struktur anlegen
Die Daten mittels INSERT as SELECT kopieren.
Alte Tabelle DROPPEN, neue Tabelle umbenennen
Constraints, Trigger etc. neueinspielen bzw. neukompilieren
2.) ... läuft auf das selbe heraus, genutzt wird jedoch das PL/SQL Package DBMS_REDEFINITION
Der Nachteil der 1. Methode ist der u.u. große manuelle Aufwand wenn viele Objekte von der Tabelle abhängig sind. Die 2. Methode kümmert sich automatisch um alle abhängigen Objekte. Änderungen die während dem Datenkopieren gemacht werden, werden vom PL/SQL Package sogar nachgezogen, d.h. DBMS_REDEFINITION kann ohne Wartungsfenster im Live Betrieb eingesetzt werden. Die Doku hierzu ist nur leider nicht ganz trivial...
http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_redefi.htm#sthref5656
Exceptionfault
Erfahrenes Mitglied
Warum? Die Aussage kann ich leider nicht nachvollziehen?
Meinst du die Table Compression bei Heap Tabellen oder die Key Compression bei IOT`s?
Bei IOT würde ich zustimmen, wobei hier die Spaltenreihenfolge durch den Primary Key gegeben ist.
Table Compression wirkt auf alle Spalten einer Heap Tabelle (ausser LOBs) egal in welcher Reihenfolge. Die vielen Ausnahmen für Table Compression dürften es aber für die meisten Benutzer absolut unbrauchbar machen:
Table Compression geht nur bei Direct-Path Inserts. Dies widerum nur wenn keine Trigger und keiner Referenzielle Integrität auf den Tabellen liegt...
Danke für die Korrektur: Ich hatte an die compression für heap Tabellen gedacht und angenommen (bzw. falsch erinnert), dass der Algorythmus dem der komprimierten Indizes entspräche (was natürlich aus einigen Gründen nicht so ohne weiteres funktionieren könnte) - die Oracle Dokumentation schweigt sich über die Implementierung dieser Funktionalität anscheinend auch ziemlich gründlich aus. Bei Tom Kyte finden sich aber einige Erläuterungen dazu (http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:42513068218995
"It works by streaming the data onto a block and while doing that -- looking for
repetitive data. It factors out the repeating data it finds and stores it in a symbol
table on that block. It replaces the string with an index into this symbol table in the
data on the block itself. That way, each block is a self contained "thing", you only
need that block to decompress it."
Und weiter unten dann noch mal ganz explizit:
"with a table, the "order" would not matter -- it considers all columns in the table (normal
columns, not "large objects") and factors out repeating data IN the row and ACROSS rows. All of the data going on the block is considered."
Somit spielt die Reihenfolge der Daten also keine Rolle (anders als beim compress für Indizes: "The INDEX compression works by removing redundant leading key entries" - weshalb sich ein Index am besten komprimieren lässt, wenn die Spalten mit der geringsten Selektivität am Anfang stehen).
Das table compression nicht in sehr vielen Fällen verwendbar ist, ist sicher richtig - in erster Linie würd ich an DWHs denken. Dazu nochmal Tom Kyte:
"Compressing a table does not prohibit you from using normal DML against it. It is just that the newly added or modified information will not be stored compressed. It would take a rebuild of that segment in order to compress it. So, table compression is most likely to be valuable in these situations:
· Large amounts of static reference information that is read-only or read-mostly
· Data warehousing environments where bulk operations are common
· Audit trail information stored in partitioned tables, where you can compress last month’s auditing information at the beginning of a new month
Table compression should not be considered for most transactional tables where the data is heavily updated. There table compression would be defeated, as each update would tend to “decompress” the row(s)."
Gruß
MP
"It works by streaming the data onto a block and while doing that -- looking for
repetitive data. It factors out the repeating data it finds and stores it in a symbol
table on that block. It replaces the string with an index into this symbol table in the
data on the block itself. That way, each block is a self contained "thing", you only
need that block to decompress it."
Und weiter unten dann noch mal ganz explizit:
"with a table, the "order" would not matter -- it considers all columns in the table (normal
columns, not "large objects") and factors out repeating data IN the row and ACROSS rows. All of the data going on the block is considered."
Somit spielt die Reihenfolge der Daten also keine Rolle (anders als beim compress für Indizes: "The INDEX compression works by removing redundant leading key entries" - weshalb sich ein Index am besten komprimieren lässt, wenn die Spalten mit der geringsten Selektivität am Anfang stehen).
Das table compression nicht in sehr vielen Fällen verwendbar ist, ist sicher richtig - in erster Linie würd ich an DWHs denken. Dazu nochmal Tom Kyte:
"Compressing a table does not prohibit you from using normal DML against it. It is just that the newly added or modified information will not be stored compressed. It would take a rebuild of that segment in order to compress it. So, table compression is most likely to be valuable in these situations:
· Large amounts of static reference information that is read-only or read-mostly
· Data warehousing environments where bulk operations are common
· Audit trail information stored in partitioned tables, where you can compress last month’s auditing information at the beginning of a new month
Table compression should not be considered for most transactional tables where the data is heavily updated. There table compression would be defeated, as each update would tend to “decompress” the row(s)."
Gruß
MP
Zuletzt bearbeitet:
