Firebird 3 - Feld andere Domain zuweisen

[Perlsau]

Zitat:

Zitat von dataspider (Beitrag 1298522)

Bei Firebird 3 kommt folgender Fehler:

Die aktuelle Firebird 3.0 Beta 1 ist als unstable gekennzeichnet, also instabil und noch nicht für den ernsthaften Einsatz bereit.

[tsteinmaurer]

Zitat:

Die aktuelle Firebird 3.0 Beta 1 ist als unstable gekennzeichnet, also instabil und noch nicht für den ernsthaften Einsatz bereit.

Ändert nichts an der Tatsache, dass auch eine finale Version von Firebird 3 keine direkten Systemtabellenoperationen erlauben wird.

[Perlsau]

Zitat:

Zitat von tsteinmaurer (Beitrag 1298685)

Ändert nichts an der Tatsache, dass auch eine finale Version von Firebird 3 keine direkten Systemtabellenoperationen erlauben wird.

Und das ist gut so ... :thumb:

[IBExpert]

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

[Perlsau]

Kann ich nachvollziehen: Wenn ich als Entwickler bei IbExpert nun die ganzen DB-Zugriffe im hauseigenen Datenbank-Manager umschreiben bzw. ergänzen müßte (IbExpert muß ja nun beide Datenbank-Zugriffsmöglichkeiten bereitstellen), wäre ich vielleicht auch nicht allzu erfreut :roll:

[jobo]

Zitat:

Zitat von IBExpert (Beitrag 1298725)

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:

Zitat von IBExpert (Beitrag 1298803)

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

Zitat von mkinzler (Beitrag 1298821)

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.