Hallo zusammen,
gibts bei Oracle sowas ähnliches wie in mysql
alter table xxx add yyy number(10) FIRST
Also, das FIRST mag oracle nicht, aber ich möchte eine Spalte eben ganz vorne hinzufügen.
Gruß, Alex
- Nein, gibt es nicht. Ist meiner Ansicht nach auch völlig irrelevant, in welcher Reihenfolge die Splaten in der Tabelle vorkommen.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Danke für die Antwort. Aber es gibt Situationen, das ist das vielleicht nicht relevant, aber wäre praktisch zu haben. Aber wie Du sagst ist das Ansichtssache und muss hier nicht ausdiskutiert werden.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo,
es gibt einige Datenbanken, die das machen. Oracle eben nicht. Ich habe es auch schon vermisst, schon alleine aus dem Grund, dass ich gerne den Primärschlüssel zusammenhalte. (Z.B. wenn man eine DB nachträglich mandantenfähig machen will)
Immerhin: Oracle hat sich schon gebessert. Früher konnte man noch nicht ein,mal eine Spalte löschen oder umbenennen.
Aber so ist die Welt: reicht man einem den kleinen Finger, wollen sie gleich die ganze Hand.
Gruß
Peter
Hallo zusammen
gibts bei Oracle sowas ähnliches wie in mysql
alter table xxx add yyy number(10) FIRST
Also, das FIRST mag oracle nicht, aber ich möchte eine Spalte
eben ganz vorne hinzufügen.Gruß, Alex
- Nein, gibt es nicht. Ist meiner Ansicht nach auch völlig
irrelevant, in welcher Reihenfolge die Splaten in der Tabelle
vorkommen.Danke für die Antwort. Aber es gibt Situationen, das ist das
vielleicht nicht relevant, aber wäre praktisch zu haben. Aber
wie Du sagst ist das Ansichtssache und muss hier nicht
ausdiskutiert werden.
- Nein, gibt es nicht. Ist meiner Ansicht nach auch völlig
irrelevant, in welcher Reihenfolge die Splaten in der Tabelle
vorkommen.Danke für die Antwort. Aber es gibt Situationen, das ist das
vielleicht nicht relevant, aber wäre praktisch zu haben. Aber
wie Du sagst ist das Ansichtssache und muss hier nicht
ausdiskutiert werden.
Hallo Alexander,
nein, diese Situationen gibt es nicht. In deinem Programm steht ja ausschliesslich
SELECT col1, col2, col3,... FROM tab1
und nicht etwa
SELECT \* FROM tab1
was ja die einzige Situation wäre, wo das relevant sein könnte. Wenn aber irgendein unglückseliger Programmierer das doch getan hat, dann kannst du dir so behelfen:
CREATE TABLE tab (b NUMBER, c NUMBER);
ALTER TABLE tab ADD (a NUMBER);
RENAME tab TO tab\_t;
CREATE VIEW tab AS SELECT a, b, c FROM tab\_t;
HTH
Martin
Und es gibt sie doch. Mein Programm hat für den Admin-Login eine Schnittstelle, die direkten Datenbankzugriff gewährt. Damit kann ich jede beliebige Tabelle auslesen und manipulieren und kann somit Korrekturen vornehmen, die dem User im Programm nicht möglich sind. Das ist sehr praktisch, da es ein komplexes Programm ist und es keinen Sinn macht, jede Eventualität auszuprogrammieren, zumal man die meisten Problemfälle im Voraus gar nicht kennt. Und einen direkten DB-Zugriff habe ich auch nicht, da die DB hinter einer Firewall sitzt und ich Entwickler bin und kein technischer Admin, trotzdem muss ich außer Entwickeln auch die Applikation betreuen.
So, wenn ich nun eine x-beliebige Tabelle auslese, ist eine definierte Reihenfolge der Spalten sehr vorteilhaft, denn oft sind es sehr viele Spalten und die passen gar nicht alle auf einmal auf den Schirm. Da ist es schon praktisch, wenn die relevanten Spalten vorne stehen und man nicht immer scrollen muss. Natürlich kann ich mir eine view anlegen oder auch die Reihenfolge der Spalten für die Schnittstelle in eine extra Tabelle legen, aber das bedeutet schon wieder Mehraufwand. Da wäre ein FIRST halt etwas einfacher gewesen.
Alex
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hi!
nein, diese Situationen gibt es nicht.
Doch, doch, leider … allerdings würde ich statt der View gleich wieder eine Table kreieren:
CREATE TABLE tab (b NUMBER, c NUMBER);
ALTER TABLE tab ADD (a NUMBER);
RENAME tab TO tab\_t;
CREATE TABLE tab AS SELECT a, b, c FROM tab\_t;
DROP TABLE tab\_t;
(natürlich mit allen Einstellungen der ursprünglichen Table)
Grüße,
Tomh
Noch eine Ergänzung
Hallo Tomh,
dir wird das ja nicht passieren, aber für Anfänger:
Die Fremdschlüssel nicht vergessen. Man will ja nicht, dass ein Unglück passiert (z.B. wegen ON DELETE CASCADE)
Viele Grüße
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hi!
dir wird das ja nicht passieren, aber für Anfänger:
Die Fremdschlüssel nicht vergessen.
Warum sollte mir das nicht passen? Am liebsten wären mir Tabellen ausschließlich mit Foreign-Keys 
- oder sprichst Du auf die „künstliche ID“-Diskussion an?
Man will ja nicht, dass
ein Unglück passiert (z.B. wegen ON DELETE CASCADE)
siehe unter
(natürlich mit allen Einstellungen der ursprünglichen Table)
Grüße,
Tomh
PS: Ich glaub, ich hab mein ganzes Leben noch kein einziges DELETE CASCADE kreiert … dazu bin ich zu feig 
- ich setz lieber Gültigkeitskennzeichen und/oder lege Journal-Tabellen an oder schreibe endlos langen PL/SQL-Code …
Hallo alexander,
hat ein wenig gedauert mit einer Antwort.
Und es gibt sie doch. Mein Programm hat für den Admin-Login
eine Schnittstelle, die direkten Datenbankzugriff gewährt.
Sowas kenne ich, mir wird aber immer meistens ein wenig übel, wenn ich davon höre.
Damit kann ich jede beliebige Tabelle auslesen und
manipulieren und kann somit Korrekturen vornehmen, die dem
User im Programm nicht möglich sind.
Korrekturen? Macht man sowas nicht mit Patches? Oder stört das nicht weiter, wenn der gleiche Fehler immer wieder einmal auftritt?
Das ist sehr praktisch,
da es ein komplexes Programm ist und es keinen Sinn macht,
jede Eventualität auszuprogrammieren, zumal man die meisten
Problemfälle im Voraus gar nicht kennt.
Autsch. Heisst das dein Programm funktioniert „manchmal“? Dass die Analyse nicht immer alle Problemfälle im voraus zu Tage fördert ist aufgrund der Fehleranfälligkeit menschlichen Denkens und Handelns immanent, aber „die meisten“ nicht zu erkennen weist eher darauf hin, dass gar keine Analyse stattgefunden hat. Ich würde diesbezüglich die Entwicklungsstrategien bei Eurer Software nochmal dringend überdenken.
Und einen direkten
DB-Zugriff habe ich auch nicht, da die DB hinter einer
Firewall sitzt und ich Entwickler bin und kein technischer
Admin, trotzdem muss ich außer Entwickeln auch die Applikation
betreuen.So, wenn ich nun eine x-beliebige Tabelle auslese, ist eine
definierte Reihenfolge der Spalten sehr vorteilhaft, denn oft
sind es sehr viele Spalten und die passen gar nicht alle auf
einmal auf den Schirm. Da ist es schon praktisch, wenn die
relevanten Spalten vorne stehen und man nicht immer scrollen
muss.
Das sehe ich ja noch ein, ich bin wie gesagt nur der Meinung, dass man so eine Schnittstelle gar nicht oder nur so selten braucht, dass jeder zusätzliche Aufwand umsonst ist.
Natürlich kann ich mir eine view anlegen oder auch die
Reihenfolge der Spalten für die Schnittstelle in eine extra
Tabelle legen, aber das bedeutet schon wieder Mehraufwand. Da
wäre ein FIRST halt etwas einfacher gewesen.
Den zusätzlichen Aufwand sehe ich nicht: Das Script zum Erstellen des Views kannst du dir beim ersten Mal generieren lassen und dann abspeichern. Wenn eine neue Spalte dazu kommt, dann kannst du die an beliebiger Stelle in das Script einfügen. Das dauert mA in etwa 12 Sekunden länger als nur ein ALTER TABLE alleine. Dafür kannst du auch in Zukunft die Spalten im View umsortieren, ohne die Tabelle gleich wieder reorganisieren zu müssen (weshalb ich diese Lösung auch jederzeit einem CREATE … AS SELECT… vorziehen würde, insbesondere weil bei der CREATE AS SELECT - Variante auch die Indices, Constraints, Triggers etc. neu zu erstellen sind sowie die STORAGE Parameter, Tablespace richtig angegeben werden müssen).
Ich hoffe das war jetzt nicht zu oberlehrerhaft.
Liebe Grüße,
Martin
Hi Tom,
nein, diese Situationen gibt es nicht.
Doch, doch, leider …
Ich bleibe bei meinem nein - ausser du lieferst mir wirklich ein gutes Argument (also keines wie „weil da ein anderer Mist gebaut hat“).
allerdings würde ich statt der View
gleich wieder eine Table kreieren:
Warum?
(natürlich mit allen Einstellungen der
ursprünglichen Table)
Das genau wäre der Grund für mich, das eben nicht zu tun. Wenn ich sowas schon machen muss (und ich das ja bekanntermassen nur deshalb tue, weil da ein anderer Mist gebaut hat), dann mache ich mir nicht auch noch unnötig Arbeit damit.
Grüße,
Tomh
Ebensolche,
Martin
Hallo Martin,
ich denke, Du hast das falsch verstanden. Das Programm funktioniert immer und auch immer korrekt. Mit Korrekturen ist z.B. folgendes gemeint:
Ein Anwender soll einem Vorgang zustimmen. Dazu hat er zwei Buttons, JA und NEIN. Wenn er JA klickt, wird das entsprechend vermerkt, zusammen mit dem aktuellen Datum. Jetzt gibt es aber auch Leute, die zustimmen müssen, aber zu faul, zu doof oder sonstwas sind, um die Applikation zu bedienen. Sie schicken ein Mail (wahrscheinlich machts die Sektretärin, die auch alle eingehenden Mails ausdruckt…), aber nicht an mich, sondern an den Fachbereich. Dieser leitet es irgendwann an mich weiter, ich darf darf dann im Namen desssen auf JA klicken. Natürlich wird dann auch das Datum meines Klicks übernommen. Der Fachbereich will aber, dass als Datum das Maildatum erscheint, also ein paar Tage vorher, damit man eben sieht, was die Zustimmung genau erfolgte. Nun kann ich dank meiner allgemeinen Schnittstelle in 5 Sekunden das Datumsfeld in der Tabelle editieren. Sowas kommt in der Woche einmal vor, das macht im Jahr grob 5 Minuten Aufwand. Erheblich mehr Aufwand wäre es, die Editierbarkeit des Feldes für gewisse Rollen zu implementieren. Und dafür hat der Kunde kein Geld.
Es gibt aber zig Beispiele wie diese, die alle selten vorkommen, insofern war der einmalige Aufwand für die Schnittstelle sinnvoll.
Außerdem hat sie noch einen ganz anderen Vorteil. Ich kann mir auf einen Schlag einen Überblick über den Inhalt einer Tabelle verschaffen. Ich kann individuelle SQLs absetzen, die mir sofort die Ergebnisse liefern, die ich benötige.
Gruß, Alex
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]