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.
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.
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
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/
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
info@ibexpert.de 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.