Berechtigungen neuer Datensatz

[Matthias Haake]

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.

Das verstehe ich – es ging mir auch gar nicht darum, dies zu verhandeln. Natürlich benötigt jedes Nuclet ein eindeutiges Präfix, das wurde auch nie in Frage gestellt. Aber es leuchtet mir technisch nicht ein, warum der Präfix ausschließlich willkürlich von Nuclos vergeben werden muss. Wir haben nur ein Nuclet – und da ist es technisch doch egal, ob das Präfix nun „T_EO“ oder „XYZ_“ ist, so lange es eindeutig ist. Beim Import von neuen Nuclets kann Nuclos da ja auch gerne die Hand drüber halten; aber bei der Migration eines bestehenden Systems mit nur einem Nuclet erzeugt das mehr Arbeit als sein müsste. Es geht mir nur um den „Bestandsschutz“ langjähriger Kunden.

Und natürlich haben wir den Zugriff versucht zu kapseln. Zwischen den externen Anwendungen (mit Schreibzugriff) und der Datenbank steckt das Microsoft Entity Framework. Um da alle Features nutzen zu können, braucht es nun einmal Tabellen und keine Views.

Über das Thema Datenbank-Objekte ist schon mal gesprochen worden. Es funktioniert(e) einfach nicht zuverlässig mit dem SQL-Server bzw. war beim Einstieg in die Nuclos-Welt noch gar nicht vorhanden / funktionsfähig. Angefangen damit, dass es das Statement „CREATE OR UPDATE“ auf dem SQL-Server nicht gibt, müsste man im Quelltext immer über die „sys.objects“-Tabelle abfragen, ob es das Objekt bereits gibt, um zu entscheiden ob das Statement nun CREATE oder UPDATE sein muss. Die fehlende Codevervollständigung und Syntax-Highlighting macht die Sache auch nicht sonderlich effizient im Alltag. Somit sind u.a. alle berechneten Attribute direkt in der DB angelegt.

Das die Migration Arbeit machen wird, ist sicher allen klar. Daher ist jede Aussicht auf Aufwandminimierung sehr willkommen, um die Downtime gering zu halten und den vorangehenden Vorbereitungsaufwand auf Kundenseite (Erstellung von Migrationsskripten für SQL-Funktionen anhand der auftretenden Probleme im Testsystem) nicht unnötig aufzublähen.

Viele Grüße,
Matthias