OS400 PL/SQL LIbs - generell

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