OS400 PL/SQL LIbs - generell

[MGJ79]

Hallo Zusammen,

derzeit spiele ich mich mit PL/SQL auf der ISeries.
In der DB2 Welt gibt es Bibliotheken - Libraries in denen z.B. eine
Stored Procedure erstellt wird.. soweit so gut.

Wenn ich diese Procedure ausführe werden die Objekte der Lib zum Erstellungszeitpunkt aufgerufen.

Somit müsste es eine Procedure z.B.
PRODLIB.MyProcedure
TESTLIB.MyProcedure
geben.

Wie wird dass in der Praxis gehandhabt ist das der richtige Ansatz mit mehren Libs und Procedures??
Oder gibt es da andere Lösungen bei denen die Procedure auf einen anderen Pfad (evtl set Path) zeigt um auf z.B. die Testdaten zu lesen/schreiben.

Schließlich möchte ich die zu benutzenden Objekte ja nicht Vollqualifiziert, also Lib-befreit, benützen.

[Fuerchau]

Die Definition der Art Zugriffes wird zur Compilezeit (egal welche Sprache) entschieden.
Hier wird das sog. "Naming" verwendet:
*SYS = Suche über Bibliotheksliste, Qualifiziert in der Form "Schema/Name"
*SQL = Suche über Standardschema, Qualifiziert in der Form "Schema.Name"
Schema = Bibliothek
Beim Verbindungsaufbau zur DB wird automatisch, falls vorhanden, eine Lib mit dem Namen des Users gesucht und als Default eingetragen. Per Set Schema kann das zur Laufzeit angepasst werden.
Nun unterstützt SQL leider nur ein Default-Schema, so dass ohne weitere Qualifizierung beim Naming = *SQL sowohl Prozeduren und Funktionen als auch Tabelle und Views in derselben Lib gesucht werden.

Nun muss man also für die Anwendung generell entscheiden:
Packt man alles in genau 1 Lib?
Trennt man ggf. Programme, Prozeduren, Funktionen von den Daten in 2 oder gar mehr Libs?

Dies bleibt letztlich jedem selbst überlassen.

Meine persönlichen Erfahrungen sind da besser mit dem Typ *SYS, da ich durch entsprechende Reihenfolge der Libs die Zugriffe steuern und auch besser Test- und Echtsysteme trennen kann.

Es gibt aber auch andere Erfahrungen, die besser mit dem Typ *SQL fahren.

[BenderD]

... das ist so gewollt, dass das qualifiziert zur Compiletime vernagelt wird - bei Triggern regt sich keiner drüber auf. Ein Schema und eine Library werden zwar beide als *LIB implementiert, aber konzeptionell sind das zwei völlig verschiedene Dinge.
Verbiege ich nun die Sache und erstelle Datenbanken (= Schema), die verschiedene Bibliotheken überspannen, bekomme ich save restore Anomalien, die ich mir möglichst erspare - die schlagen nämlich im Wiederherstellungsfall unbarmherzig zu (logische Dateien, die auf den falschen physischen hängen, kaputte Objekte, wegen nicht auflösbbarer Referenzen...).
Ganz crude wird es, wenn man Datenbankobjekte nach *LIBL zugreift (beliebt sind hier unvollständige Testumgebungen, die durch dahinter stehende Prod Bibliotheken "ergänzt" werden). Zugriff dann nach dem Muster: ich habe hier eine Auftragsposition, schau mal, ob Du irgendwo eine Position findest und schreiben darfst Du nur, wenn die Artikel irgendwo vorhanden sind - und das mit einer Datenbank, die referentielle Integrität sicherstellen kann.
Je nach vorhandenem Wahnsinn, kann man dann Dateien noch mit share öffnen lassen...

Es gibt Umgebungen (leider viel zu viele), die bereits so verbogen sind, dass man das kaum wieder grade kriegt, aber wenn man die Wahl hat nimmt man Datenbank (alles kommt innerhalb einer Bibliothek zum Abschluss) und nicht Datenschrank.

D*B

[Fuerchau]

Nun, ein Schrank ist für mich persönlich immer noch sicherer als eine Bank.
Allerdings ist wiederum Software immer noch besser als Schrankware (gekauft und in den Schrank gestellt).

[BenderD]

Nun, ein Schrank ist für mich persönlich immer noch sicherer als eine Bank.
Allerdings ist wiederum Software immer noch besser als Schrankware (gekauft und in den Schrank gestellt).

... als ehemaliger Banker, kann ich da kaum widersprechen. Allerdings ist mir im Laufe langer Jahre auch Software über den Weg gelaufen, die im Schrank besser aufgehoben gewesen wäre als installiert und eingesetzt...