Datenbank mit Tabellenverschlüsselung benötigt.

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

[Frickler]

Zitat von Uwe Raabe:

Zitat von Frickler:

Mit anderen Worten: ist eine buchhalterisch relevante Software (im Fall von 2017 eine Kasse) mit welchem Aufwand auch immer theoretisch spurlos manipulierbar, dann darf der Prüfer hinzuschätzen.

Wenn der nötige Aufwand nach oben unbegrenzt ist, dann wäre das aber wohl immer der Fall, oder? Es gibt immer einen Weg der theoretisch spurlosen Manipulation. Nur wird irgendwann der Aufwand größer als der erreichbare Nutzen.

Beim konkreten Urteil ging es um eine Kassensoftware in Access. Da ist die Manipulationshürde gar nicht mal so hoch. Von Kommentatoren wird das Urteil aber allgemein so verstanden, dass die Datenbank egal ist. Und dass nicht nur Kassen betroffen sind. Das hat vermutlich der erwähnte Auditor so verstanden.


--
P.S.: Eine vollverschlüsselte Firebird-Kassendatenbank kann man aber auch überlisten: morgens den Server anhalten, eine Kopie ziehen, dann kommt die Hochzeitsgesellschaft und den ganzen Vormittag wird kassiert. Z-Bon drucken, die Datenbank zurückspielen und das Geld in die Tasche stecken

[jobo]

Hab den Thread überflogen. Worum geht es am Ende? Verschlüsselung wegen Geheimniswahrung oder Nachvollziehbarkeit?
Verschlüsselungsprobleme und Folgeeffekte (Nutzungseinschränkung) gibt es natürlich, wenn man jeder Spalte verschlüsselt. Das ist selbst bei Geheimniswahrung aber nicht notwendig. Es gibt idR. ein Modell und Nutzdaten, letztere müssen wahrscheinlich auch nur teilweise verschlüsselt werden.

Wenn es "nur" um Nachvollziehbarkeit geht, müsste eine einzige Spalte diese garantieren (bzw. ein einziger Mechanismus, transaktionsbasiert, wie hier auch schon beschrieben), z.B. durch eine Signatur mit Zertifikat. Hab das praktisch noch nicht gemacht, aber es müsste einen Appserver geben, der "als letzter" einen Datensatz signiert. Dabei müsste er einen Rückgabewert über diesen Vorgang erhalten, den er bei der nächsten Signatur mit dem Vorgängersatz vergleicht, um Backup Hacks zu unterbinden.
Referentielle Integrität und Constraints allgemein sind ja Grundfunktionen von ACID Datenbanken und bilden die beste Ausgangsbasis für solche Mechanismen.

Ansonsten gibt es auch fertig Software wie schon angeklungen.
Oracle bietet diverse Sachen an, z.B. Audit Vault, das gleich die Analyse der Audits mitliefert. Wahrscheinlich gibt es das auch kleinteiliger ohne das Endprodukt.

Und ja, es kostet, weiß nicht, was diese Punkte immer sollen. Oder arbeitet hier jemand umsonst für seine Kunden? Spätestens für nicht triviale Anforderungen muss ein Kunde am Ende vielleicht etwas tiefer in die Tasche greifen. Die Problematik des Aufwands für eine "wasserdichte" Lösung wurde ja bereits angesprochen.

[IBExpert]

Zitat von Frickler:

P.S.: Eine vollverschlüsselte Firebird-Kassendatenbank kann man aber auch überlisten: morgens den Server anhalten, eine Kopie ziehen, dann kommt die Hochzeitsgesellschaft und den ganzen Vormittag wird kassiert. Z-Bon drucken, die Datenbank zurückspielen und das Geld in die Tasche stecken

ja, dafür muss aber der Inhaber und ggf der Programmierer zusammenarbeiten und das überhaupt ermöglichen, bei einer Kassensoftware im Kiosk Mode ist das nicht so banal, wenn der Entwickler das nicht völlig daneben umgesetzt hat. Und richtig blöd wird es, wenn dein Hochzeitspaar dann am ende einen Beleg haben will und per Karte zahlen möchte.

Wer übrigens kein Bock auf Steuerbescheisser in der Gastronomie hat, ganz einfacher Tip: niemals bar, immer nach Beleg fragen und per karte zahlen, dann wird es schwierig, für den Gastronomen die Einnahmen vor der Steuer zu verstecken.

p.s.: Und wenn der Wirt dann behauptet, das sein Kartenlesegerät leider gerade jetzt nicht funktioniert, dann sagen, das man kein Bargeld hat, aber den Betrag auch gerne überweisen kann. Man glaubt gar nicht wie viele Kartenlesegeräte sich danach wieder ganz spontan selbst geheilt haben ...

[mkinzler]

Zitat:

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.

Ich hatte eigentlich nicht vorgeschlagen, eigene Tabellen hierfür zu nehmen (schadet natürlich nicht). Firebird entscheidet ja selber ob in der Tabelle die Daten selber oder nur eine Verweis (Blobpointer) auf die eigentlichen Daten steht (diese werden dann in einem anderen Bereich der Datenbank unabhängig gespeichert).

[IBExpert]

Zitat von mkinzler:

Ich hatte eigentlich nicht vorgeschlagen, eigene Tabellen hierfür zu nehmen (schadet natürlich nicht). Firebird entscheidet ja selber ob in der Tabelle die Daten selber oder nur eine Verweis (Blobpointer) auf die eigentlichen Daten steht (diese werden dann in einem anderen Bereich der Datenbank unabhängig gespeichert).

Stimmt, da hatte ich deinem Satz wohl ein paar hinzu gemogelt, ist aber im Prinzip fast egal, dann eben nur ich und nicht du

ich mach das mittlerweile fast immer so, das große Inhalte wie pdf, jpg, png usw. in einer extra Tabelle sind und diese Inhalte sich eben auf verschiedene Datenbanken oder sogar Serverinstanzen verteilen, weil Terabyte DB immer normaler wird mit solchen Inhalten und das am Ende das zentrale Handling dadurch vereinfacht wird, wenn das nicht auf dutzenden Tabellen verteilt ist

[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