Firebird 3 - Feld andere Domain zuweisen

[jobo]

Zitat von IBExpert:

der eine sieht das so, der andere sieht das anders ....

MMh, ist es nicht ein gutes Zeichen, dass ein System erwachsen wird oder sagen wir reif und professionell mit solchen Dingen umgeht. Änderung von Systemtabellen mag mir in der Not vielleicht helfen, aber es lähmt schlimmstenfalls die Weiterentwicklung des Systems, weil zuviel nicht mehr funktionieren könnte, wenn dort dann Umbaumaßnahmen erfolgen würden.
Problematisch ist es natürlich, wenn Dinge unterbunden werden, für die es keinen offiziellem Weg (Interface) gibt.

[IBExpert]

das wir dafür einiges in IBExpert ändern müssen ist das geringste Problem, da steckt eh sehr viel Arbeit in den Erweiterungen für Firebird 3.0

Es gibt aber seit zig Jahren bewährte Verfahren im Firebird Umfeld, die durch diese Entscheidung nicht mehr einsetzbar sind.

Beispiel: Quellcode der SP und Trigger verbergen. Je mehr Business Logik in der DB in SPs und Trigger umgesetzt wurde, um so mehr ist es im Interesse von Unternehmen, Ihre angewandte Business Logik gegenüber Mitbewerbern und anderen zu schützen. In der Vergangenheit war das kein Problem, da man einfach die *SOURCE Spalte in RDB$PROCEDURES und RDB$TRIGGERS überschreiben konnte, da die Ausführung nur die *BLR Inhalte brauchte.

Das geht zukünftig nicht mehr. Quasi zwangsweise Open Source. Wenn Delphi nun den Quelltext deiner Anwendung zwangsweise decompilierbar in die Exe packen würde, dann würdet Ihr das sicherlich auch anders sehen. Wobei das bei VB bzw. .NET Anwendungen nicht so weltfremd ist, aber da versucht man mit Obfuskation die Nutzung schweiriger zu machen.

Es wäre ein einfaches, das den Entwickler durch einen Parameter in der Firebird.conf selbst entscheiden zu lassen, aber das scheint im Moment nicht absehbar zu sein. Bleibt immer noch Hardcore Manpulation der Inhalte mit Tools wie IBExperts Database Inside, mit denen wir das auch zukünftig realisieren können.

[jobo]

[OT]

Zitat von IBExpert:

..
Es gibt aber seit zig Jahren bewährte Verfahren im Firebird Umfeld, die durch diese Entscheidung nicht mehr einsetzbar sind.
..

Das Problem kann ich verstehen und es ist m.E. tatsächlich etwas anders gelagert als der klassische table alter hack oder so, obwohl die Ausgangssituation aber wohl die gleiche ist. Ich hab keine Kenntnis, wie das "Deprecated" Thema bei fb gehandhabt wird und ob oder welche Anwendergemeinschaften es gibt, aber ist dann da nicht irgendwas in der Kommunikation schief gelaufen? FB 3 ist ja nun schließlich schon eine ganze Weile "unterwegs".
Ist es Ironie oder Politik oder beides, dass ein Open Source System die Anwender zwingt, auch open source zu sein? Klingt allerdings auch etwas nach "selbst die Karten gelegt". Ich hab es ja vorhin schon geschrieben, Aufzuräumen ohne Ersatzschnittstellen/ -verfahren zu schaffen, schafft unnötig Probleme, das sieht aus "Hersteller"perspektive etwas nach Selbstmord aus.
Immherin, wenn Ihr es trotzdem schafft, closed source zu sein, steht Ihr ja nicht schlecht da.

Bin ehrlich gesagt überrascht, dass das (closed source) so ein Thema ist, schließlich geht der Trend bei DB ja angeblich so sehr nach Blackbox bzw. austauschbar. Auch hier im Forum hab ich manchmal den Eindruck, dass Businesslogik in der DB gerade zu zwanghaft vermieden wird. Dazu habe ich immer angenommen, es geht genau darum, eben closed source zu bleiben, auch wenn die Ops Faktoren langsamer oder komplexer sind im Client.
[/OT]

[mkinzler]

Vielleicht wird es dann eine andere Möglichkeit geben, den zusätzlichen abgelegten Quellcode einer SP zu löschen oder zu verschlüsseln.

[jobo]

Zitat von mkinzler:

Vielleicht wird es dann eine andere Möglichkeit geben, den zusätzlichen abgelegten Quellcode einer SP zu löschen oder zu verschlüsseln.

Das wäre naheliegend und wünschenswert, aber closed source ist ja nur ein Beispiel gewesen. Wäre doch schade, wenn soetwas wie firebird wegen solcher Probleme an Verbreitung bzw. Akzeptanz verliert.

[mjustin]

Zitat von IBExpert:

Das geht zukünftig nicht mehr. Quasi zwangsweise Open Source.

Technisch besteht - da Firebird Open Source ist - im Prinzip die Möglichkeit, die gewünschten Zugriffs/Löschrechte auf die Quelltexte der Stored Procedures zu erhalten.

[tsteinmaurer]

@Holger:

Zitat:

Beispiel: Quellcode der SP und Trigger verbergen. Je mehr Business Logik in der DB in SPs und Trigger umgesetzt wurde, um so mehr ist es im Interesse von Unternehmen, Ihre angewandte Business Logik gegenüber Mitbewerbern und anderen zu schützen. In der Vergangenheit war das kein Problem, da man einfach die *SOURCE Spalte in RDB$PROCEDURES und RDB$TRIGGERS überschreiben konnte, da die Ausführung nur die *BLR Inhalte brauchte.

Das geht zukünftig nicht mehr

Doch, siehe: http://tracker.firebirdsql.org/browse/CORE-4507

Ab dem Zeitpunkt wo das über die Systemtabellen nicht mehr erlaubt ist, soll es eine entsprechende DDL-basierte Lösung geben.

LG

[IBExpert]

ok, gut zu wissen, ist aber bei der zuletzt von mir getesteten aktuellen
beta 1 Version war das auch noch nicht möglich, aber danke für die info

[mkinzler]

Aus meiner sicht grundsätzlich eine gute Sache, nur wenn man bedenkt, wie lange sich FB3 schon verzögert, sollte man eher die angefangenen Features fertigstellen und FB 3 fertigstellen, bevor man immer neue Erweiterungen plant.