Berechtigungen neuer Datensatz

[Ramin Goettlich]

Hallo,

da die Multinucletfähigkeit ein wesentlicher Bestandteil der zukünftigen Ausrichtung von Nuclos ist, ist sie nicht „verhandlungsfähig“. Verschiedene Nuclets ggf. sogar verschiedener Hersteller können gleiche Businessobjektnamen (d.h. gleiche Tabellennamen) mit sich bringen und damit muss Nuclos umgehen können.

Es sei angemerkt, dass Nuclos die Tabellennamen in Nuclos-Datenbankobjekten mitmigriert, soweit diese eindeutig identifiziert werden können.

Auf Grund mehrerer angebundener System

Wir würden grundsätzlich empfehlen, dass für Schnittstellen eine Abstraktionsebene eingebaut wird. Dritte Systeme sollten niemals auf die Tabellenstrukturen in Nuclos gehen – die könnten ja geändert werden 😉 – sondern nur auf eine abstrahierte Sicht darauf (explizite Views für das Drittsystem). Diese Views könnten ja z.B. T_EO_* heissen. Immer wenn ein System B direkt auf interne Objekte eines Systems A zugreift, setzt sich System B der Gefahr aus, dass Änderungen in A durchgeführt werden, die B nicht mitkriegt aber davon betroffen ist. Ein Entwickler des Systems A kann ja nicht sehen, dass ein System B auf seine Objekt zugreift, wenn nicht eine explizite Schnittstellenschicht im selben Schema existiert, die nach Änderungen plötzlich nicht mehr kompilierbar o.ä. ist.

und jeder Menge SQL-Code (keine Datenbankobjekte)

Auch ich habe unmengen an SQL Code, die T_EO beinhalten.

Warum überführen Sie diesen SQL-Code nicht in Datenbankobjekte? Dann werden die entsprechenden Stellen mitmigriert.

Notfalls ginge ja auch Suchen und Ersetzen im SQL-Code…

Externe Zugriffe auf Nuclos-Tabellen ohne Indirektion sollten vermieden werden, wir können ja auch nicht garantieren, dass z.B. eine T_MD_STATE immer existieren wird und nicht einmal durch etwas anderes ersetzt werden wird.

Grüsse,
nuclosian