# Oracle: Spaleten verschieben bzw. an bestimmter Position einfügen



## Gray (15. März 2007)

Hi, ich verwende Oracle10g und versuche nun in eine Tabelle eine Spalte anzulegen, allerdings soll diese nicht ans Ende gehangen werden sondern mitten rein.
So wie es bei MySQL geht.
Ich habs mit dem Oracle SQL Developer versucht.
Gibt es da eine möglichkeit?


----------



## Nico Graichen (15. März 2007)

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.


----------



## MPr (15. März 2007)

da die Zeilen einer Tabelle in den Datenblöcken in der definierten Reihenfolge gespeichert sind, könnte das Einfügen an einer beliebigen Stelle nicht ohne eine Reorganisation der Tabelle erfolgen. Allerdings sollte eine View den gleichen Zweck erfüllen.

Gruß

MP


----------



## ishino (15. März 2007)

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...


----------



## Konobi (15. März 2007)

Hi,

soviel ich weis geht das bei Oracle nicht! Sollten noch nicht zuviele Datensätze drin sein erstell sie neu. Oder erstelle eine neue Tabelle und schieb die Daten rüber.
mfg


----------



## Exceptionfault (15. März 2007)

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


----------



## MPr (15. März 2007)

um die Liste zu ergänzen: ein weiterer Fall, in dem die Spaltenreihenfolge relevant ist, wäre die table compression.

Gruß

MP


----------



## Exceptionfault (15. März 2007)

MPr hat gesagt.:


> ein weiterer Fall, in dem die Spaltenreihenfolge relevant ist, wäre die table compression.



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...


----------



## MPr (16. März 2007)

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


----------

