Ich hab in einer Oracle-Datenbank als Benutzer mit Admin-Rechten (sagen wir dieser heißt „kinguser“) eine Tabelle angelegt („mytable“) und nötigen Zugriffsrechte für die Tabelle vergeben.
Mit einem Standardbenutzer ohne Admin-Rechte soll nun darauf zugegriffen werden. Das funktioniert aber nur wenn ich das SELECT-Statement folgendermaßen formuliere:
SELECT \* FROM kinguser.mytable
Versuche ich es allerdings mit:
SELECT \* FROM mytable
kommt nur die Meldung: „Table or view does not exist“
Nun, Die Lösung mit der Änderung des Default_Schemas ist „weniger komplex“. Synonyme erzeugen eine weitere Schicht Abhängigkeit (Du musst sie anlegen/pflegen/warten). Ich bin nicht generell gegen Synonyme, wir haben dies früher oft benutzt, die Lösung mit der Änderung des DEFUALT_SCHEMA’s ist einfach eleganter, vor allem , wenn du komplexere Strukturen betreuen musst.
Synonyme erzeugen eine weitere Schicht
Abhängigkeit (Du musst sie anlegen/pflegen/warten).
Und genau deswegen ist alles schön definiert, Objekte von verschiedenen Schemen, Remote-Datenbanken und Fremddatenbanken fließen ein, über langfristig verwendbare Applikationen (ich rede hier von Zeiträumen von 40-50 Jahren) können sich DB-Definitionen ändern - die Applikation bleibt unberührt, es wird lediglich das Synonym „erneuert“ …
Ich bin
nicht generell gegen Synonyme, wir haben dies früher oft
benutzt
Ab welcher Version gab’s eigentlich das DEFAULT_SCHEMA?? Ich habe erst bei der 9er zum ersten Mal davon gehört …
die Lösung mit der Änderung des DEFUALT_SCHEMA’s ist
einfach eleganter, vor allem , wenn du komplexere Strukturen
betreuen musst.
Hm, ich würde eher sagen: Wie man es gewohnt ist. Sobald mehrere Schemen miteinfließen (was bis jetzt bei meinen Projekten IMMER der Fall war), wird’s mit dem DEFAULT_SCHEMA komplexer (meine ganz persönliche Meinung - und davon bringt mich niemand ab
Synonyme erzeugen eine weitere Schicht
Abhängigkeit (Du musst sie anlegen/pflegen/warten).
Und genau deswegen ist alles schön definiert, Objekte von
verschiedenen Schemen, Remote-Datenbanken und Fremddatenbanken
fließen ein, über langfristig verwendbare Applikationen (ich
rede hier von Zeiträumen von 40-50 Jahren) können sich
DB-Definitionen ändern - die Applikation bleibt unberührt, es
wird lediglich das Synonym „erneuert“ …
ja Richtig…ein sauberes Konfigurationsmanagement ist IMMEER Voraussetzung für einen sauberen Betrieb (unter anderem)…ich sage ja nur, dass du ohne Synonyme weniger „Verwaltungsaufwand“ hast.
Ich bin
nicht generell gegen Synonyme, wir haben dies früher oft
benutzt
Ab welcher Version gab’s eigentlich das DEFAULT_SCHEMA?? Ich
habe erst bei der 9er zum ersten Mal davon gehört …
ja, genau
die Lösung mit der Änderung des DEFUALT_SCHEMA’s ist
einfach eleganter, vor allem , wenn du komplexere Strukturen
betreuen musst.
Hm, ich würde eher sagen: Wie man es gewohnt ist. Sobald
mehrere Schemen miteinfließen (was bis jetzt bei meinen
Projekten IMMER der Fall war), wird’s mit dem DEFAULT_SCHEMA
komplexer (meine ganz persönliche Meinung - und davon bringt
mich niemand ab
Auch wir haben praktisch immer n Schema im Einsatz, klar, soweit aber kein Problem damit. Wir entiwckln aber so, dass *alle* Zugriffe
des Clients (in der Regel Appliaktiosserver) über Packages gekapselt werden, und dieses Interface ist in einem Schema konzentriert.
Es gibt auch den Fall, dass mehrere Applikationen auf dieselbe Datenbank, aber unterscheidliche Schema zugreifen, aber auch dies ist kein Problem, da die Applikationen jeweils eigene Applikationsserver
verwenden.
und davon bringt
mich niemand ab
Will ich ja auch nicht…Oracle stellt uns Werkzeuge zu Verfügung…jede Menge…und alles hat seine Berechtigung
*grmpf* … genau DIESE Idee haben wir unserem Oberguru
(technischer Scheffe) ganz schnell wieder ausgetrieben
–> Und warum dies ?
Mitten im Projekt.
bestehende Software sollte angepaßt werden (ca. 1000 Forms und Reports und dementsprechend jede Menge DB-Objekte)
schlicht und einfach: keine Zeit und keine Resourcen für diesen Schritt
Eine Überlegung war es allemal Wert, nur sollte dies am ANFANG festgelegt werden, und nicht nach ein paar Jahren Entwicklung, wo große Teile der Applikation noch unter Forms 4.5 auf einer 7er DB entwickelt wurden (man merkt, das Projekt läuft schon ein paar Jährchen und dementsprechend kann man sich den Umfang vorstellen) und bereits einige Jahre im Echtbetrieb waren bzw. noch immer sind.
)