Datenbank mit Tabellenverschlüsselung benötigt.

[johndoe049]

Hört sich interessant an.

Kann vermieden werden, dass ein DB Administrator den Trigger zeitweise deaktiviert oder löscht?

Anderen Server, weil das Transaktionsprotokoll gross wird dürfte kein Problem sein. Im Bereich von Hardwareresourcen ist der sehr spendabel.

Firebird hatte ich bisher nicht auf dem Radar. Ich hatte nur mal vor Jahren eine Anwendung als Demo gesehen, wo die fdb automatisch in viele kleine fdb Dateien aufgeteilt wurde. Sollte das Backup vereinfachen. Ist das Standart oder eine Eigenkreation?

Gibt es bei Firebird eine gute Dokumentation zum runterladen oder eine Buchempfehlung?

Wenn wir schon beim "Abschweifen" sind: Wie gut kann Firebird mit Blob Feldern umgehen? Gibt es da Geschwindigkeitsprobleme, wenn viele Blob Daten vorhanden sind? So ca. 80 % Datenbankanteil.

[mkinzler]

Zitat von johndoe049:

Hört sich interessant an.

Zitat:

Kann vermieden werden, dass ein DB Administrator den Trigger zeitweise deaktiviert oder löscht?

Wenn der (Administrator-)Benutzer nicht Eigentümer der Tabelle ist, ja.

Anderen Server, weil das Transaktionsprotokoll gross wird dürfte kein Problem sein. Im Bereich von Hardwareresourcen ist der sehr spendabel.

Zitat:

Firebird hatte ich bisher nicht auf dem Radar. Ich hatte nur mal vor Jahren eine Anwendung als Demo gesehen, wo die fdb automatisch in viele kleine fdb Dateien aufgeteilt wurde. Sollte das Backup vereinfachen. Ist das Standart oder eine Eigenkreation?

Ist nicht der Standard ist aber möglich. Richtige Tabelspaces unterstützt aber FireBird (noch) nicht. Ist/war für FireBird 4.0 geplant wird aber noch diskutiert.

Zitat:

Gibt es bei Firebird eine gute Dokumentation zum runterladen oder eine Buchempfehlung?

Das ist eine "kleine" Archillesferse von FireBird. Es gibt zwar vieles aber nicht so viel/geballt wie für andere Systeme.
Das ändert sich hoffentlich aber noch ( möglicherweise durch die Integration in LibreOffice).
Wenn wir schon beim "Abschweifen" sind: Wie gut kann Firebird mit Blob Feldern umgehen? Gibt es da Geschwindigkeitsprobleme, wenn viele Blob Daten vorhanden sind? So ca. 80 % Datenbankanteil.

FireBird kann Blobs getrennt von den restlichen Feldern einer Tabelle Speichern. Bei größeren Blobs steht dann in der Tabelle nur ein Verweis auf die Daten.

[IBExpert]

Zitat von johndoe049:

Hört sich interessant an.
Kann vermieden werden, dass ein DB Administrator den Trigger zeitweise deaktiviert oder löscht?

Ab Firebeird 3.0 gibt es Trigger auf DDL, also kann selbst ein ALTER TRIGGER getriggert werden. Wenn diese Trigger per EXECUTE STATEMENT ON EXTERNAL das ebenfalls in eine externe Datenbak schreiben und ein Datenbanktrigger ggf. vorher schon Anmeldungen auf der DB restriktiv halten, d.h. nur von bestimmmte IP Adresse erlauben oder andere Tricks erfordert (vor dem ersten commit bestimmte Werte in global Temp Tables oder Session variablen zu setzen, dann müsste der Admin schon extrem gutes Firebird Know haben um daran vorbei zu kommen und nicht sofort eine externe spur hinterlassen zu haben. Wenn man dem so mißtraut, dann sollte man sich lieber andere Mitarbeiter suchen ...

Trotzdem haben wir für Kunden auch spezielle Firebird Versionen erstellt, die das Abschalten der Datenbanktrigger deaktiviert, der Kunde mißtraute dabei nur einem ehemaligen Mitarbeiter, der sich mit einer Software in der selben Branche selbstständig gemacht hat und mit seinem InsiderknowHow fleissig Bestandskunden abgeworben hat und bis zu diesem Zeitpunkt beim Datenimport keine Restriktionen hatte. Dort wird aber demnächst die Database Encryption eingeführt, dann kann er das eh vergessen.

Zitat von johndoe049:

Anderen Server, weil das Transaktionsprotokoll gross wird dürfte kein Problem sein. Im Bereich von Hardwareresourcen ist der sehr spendabel.

Falls es bei Firebird landen wird, melde dich gerne bei uns, wir bauen spezielle Firebird Server, die für das manchmal sehr spezielle Verhalten von Firbeird I/O Operationen optimiert sind. Die sind für ca. 4000 € pro Server sehr nach am Optimum mit Firebird und haben andere Kundenserver für teilweise 30-40k € deutlich hinter sich gelassen beim Firebird Speed. Weil ein Server für andere Datenbanksoftware gut ist, muss der noch lange nicht mit Firebird gut sein.

Zitat von johndoe049:

Firebird hatte ich bisher nicht auf dem Radar. Ich hatte nur mal vor Jahren eine Anwendung als Demo gesehen, wo die fdb automatisch in viele kleine fdb Dateien aufgeteilt wurde. Sollte das Backup vereinfachen. Ist das Standart oder eine Eigenkreation?

Du sprichst vermutlich von secondary files, das war im zeitalter von FAT32 hilfreich, um Datenbank größer 2GB zu benutzen, ist aber momentan nicht erforderlich (obwohl bei NTFS glaub ich das Limit pro Datei aktuell 64TB ist, d.h ab einer DB Größe von 64TB auf Windows kannst du es wieder benutzen

Zitat von johndoe049:

Gibt es bei Firebird eine gute Dokumentation zum runterladen oder eine Buchempfehlung?

Bücher sind selten geworden, ist halt kein Produkt mehr wofür jemand Geld bezahlt
Trotzdem sind die Sachen von Helen Borrie lesenswert, auch wenn die in erster Linie
FB25 fokussieren, über die Releasenotes PDF in jeder Version kommt man schnell in
das rein, was neu und wichtig ist

https://www.ibphoenix.com/products/books/firebird_book
https://firebirdsql.org/en/books/


Außerdem sind hier auch Referenz Dokus und Quickstart Guides
https://firebirdsql.org/en/reference-manuals/

Zitat von johndoe049:

Wenn wir schon beim "Abschweifen" sind: Wie gut kann Firebird mit Blob Feldern umgehen? Gibt es da Geschwindigkeitsprobleme, wenn viele Blob Daten vorhanden sind? So ca. 80 % Datenbankanteil.

Nein, es gab sogar diverse Tests, die sogar festgestellt haben, das Firebird das wesentlich besser macht als das gern überschätzte Filesystem
http://blog.plasticscm.com/2008/09/f...ystem-for.html

Wie toll das Filesystem insbesondere unter Windows ist: Leg einfach mal 10 Millionen Datensätze in einem ordner an und versuche dann mit Bordmitteln wie explorer.exe eine davon zu löschen, viel spaß dabei für die nächsten Tage Wartezeit ...

Das Erstellen eigener Tabellen für Blobs wie von Markus empfohlen machen wir immer so, wenn es sich dabei um zB Bilder und PDFs handelt, Memos oder kleinerer Kram aber eher nicht, weil
Firebird kleinere Blobs inhalte anders speichert.

Ein Referenzkunde (sehr großes Patentanwaltsbüro) speichert ca 2TB als PDFs in einer Datenbank. Die größte DB, von der ich vonanderen Kunden gehört habe, kommt aus dem Medizinumfeld und soll 15TB sein.

Mit ganz simple Techniken (abruf der pdf Inhalte nicht direkt per select auf Tabelle, sondern immer per Stored Proc) kannst du mit eingebauten Techniken die PDFs ähnlich wie das oben erwähnte Transaktionslog jahreweise in eigene Readonly Datenbanken auslagern und deinen AbrufSP sucht passend zu den Metadaten des Datensatzes dann die passende DB raus. Damit haben wir bei dem oben genannten Kunden ca 2 Millionen odfs im ca 500GB Datenbanken abgelegt, brauchen beim täglichen Backup aber nur ca 20GB sichern und nicht 500GB, weil davon ca 490GB monatsweise ausgelagert sind.

Diese PDF Archivdatenbanken können auch wieder ausgeagert sein, Kopien in der Cloub haben, bei High End Userzahlen auf replizierten Servern liegen etc.

Im Oktober ist in Berlin eine Firebird Konferenz, da sind wir auch wieder dabei, wenn Leute vorher Lust auf eine öffentliche Schulung zu der Thematik haben, meldet euch einfach bei mir oder über [e-mail] mit dem Betreff "Interesse öffentliche Firebird Schulung", ggf. koordinieren wir dann wieder mal eine Schulung zu dem Thema, gerne auch z.b. in Frankfurt, was für die meisten ja ganz gut erreichbar sein sollte.

[Dumpfbacke]

Zitat von IBExpert:

Ein Referenzkunde (sehr großes Patentanwaltsbüro) speichert ca 2TB als PDFs in einer Datenbank. Die größte DB, von der ich vonanderen Kunden gehört habe, kommt aus dem Medizinumfeld und soll 15TB sein.

Mit ganz simple Techniken (abruf der pdf Inhalte nicht direkt per select auf Tabelle, sondern immer per Stored Proc) kannst du mit eingebauten Techniken die PDFs ähnlich wie das oben erwähnte Transaktionslog jahreweise in eigene Readonly Datenbanken auslagern und deinen AbrufSP sucht passend zu den Metadaten des Datensatzes dann die passende DB raus. Damit haben wir bei dem oben genannten Kunden ca 2 Millionen odfs im ca 500GB Datenbanken abgelegt, brauchen beim täglichen Backup aber nur ca 20GB sichern und nicht 500GB, weil davon ca 490GB monatsweise ausgelagert sind.

Diese PDF Archivdatenbanken können auch wieder ausgeagert sein, Kopien in der Cloub haben, bei High End Userzahlen auf replizierten Servern liegen etc.

So etwas wollte ich auch schon mal machen. Hast du hier eventuell etwas Code für für mich ? Also wie bekomme ich eine PDF Datei in die Datenbank rein und wie bekomme ich die PDF dann heraus und kann die Datei Anzeigen un doder speichern ? Was ist den der Vorteil von einer Stored Proc und wie würde die Dann aussehen ?

Danke schon einmal Tanja.

[mkinzler]

Die SP entschiedet im Hintergrund (anhand z.B. dem Datum) in welche Datenbank die Daten gespeichert bzw. aus welcher dieser geladen werden. Die eigentliche Anwendung muss so nur die Hauptdatenbank kennen.

[IBExpert]

Zitat von Dumpfbacke:

So etwas wollte ich auch schon mal machen. Hast du hier eventuell etwas Code für für mich ? Also wie bekomme ich eine PDF Datei in die Datenbank rein und wie bekomme ich die PDF dann heraus und kann die Datei Anzeigen un doder speichern ? Was ist den der Vorteil von einer Stored Proc und wie würde die Dann aussehen ?
Danke schon einmal Tanja.

vorteil der stored proc: dein client muss gar nicht wissen wo die inhalte herkommen und schon gar nicht selber nach extern connecten, zB zur cloud archiv db

Dateien rein und raus: mit IBExpert Scripting relativ simpel

https://www.ibexpert.net/ibe/pmwiki....aIntoADatabase

mit Delphi/Lazarus aber auch wenn man beim insert den parameter mit TBlobParam(qry.params[0]).loadfromfile füllt,
geht je nach Komponente leicht anders, sollte aber schon mal helfen weiterzukommen

ein wenig code zu einer möglichen sp, die dann jahresweise auf unterschiedliche firebird aliaseinträge gehen würde

Code:

create or alter procedure BRPGETDATEIX (
    IDX bigint)
returns (
    ID bigint,
    TXT varchar(80),
    DATEI blob sub_type 0 segment size 80,
    TS timestamp)
as
declare variable jj integer;
begin
  select
    datei.txt,
    datei.ts,
    datei.datei
  from datei
  where datei.id=:idx
  into :txt, :ts, :datei;
  jj=extract(year from ts);
  if (datei is null) then
      execute statement ('select datei from datei where id=:id') (ID:=IDX)
        on external 'brp'||jj
        as user 'SYSDBA' password '.....'
        into datei;
  if (datei is null) then
      execute statement ('select datei from datei where id=:id') (ID:=IDX)
        on external '1.2.3.4/3050:brp'||jj                                     --wenn auf der lokalen instanz auch nix in datei ist, dann ggf extern nachschauen, zB auch in der cloud 
        as user 'SYSDBA' password '.....'
        into datei;
  id=idx;
  suspend;
  when any do begin

              end 
  --exception error '#BRPMSG#BRPDAT bzw BRPDATX nicht definiert oder nicht erreichbar#BRPEND#';
end