Am Beispiel FB 3.0, Laptop 2,6GHz je nach Satzlänge zwischen 4000 und 30000 Inserts/Sekunde mit meinem erwähnten Bulkload. Und dies incl. ggf. nötiger Typanpassungen.
Dabei ist das Lesen der schnellere Teil und ich erwäge sogar, den Bulkinsert noch mal zu parallelisieren. Also 1x lesen und N x Schreiben.
Wer weiß, ggf. schafft man dann 12000 bis 100.000 Inserts;-)?
Weil: lesen kann man durchaus 100000 Zeilen/Sekunde.
Firebird 3 UDR in Pascal/Delphi
Moderator: thorben.braun
Die UDR öffnet eine Datei und liest zeilenweise daraus, das ist ziemlich direkter Zugriff und nicht übermäßig Umwege gegangen, oder
Eine bewusst einfach gehaltene Beispiel-UDR mit irgendeinem Framework zu vergleichen, ist müßig und geht am Thema vorbei. Es ging darum, wie man UDRs für Firebird schreibt. Und nicht-visuelle Frameworks/Libs lassen sich auch aus UDRs nutzen.
Kein Unterschied. Beides sind Clients. Im einen Fall nutzt Deine Anwendung die Funktionen, im anderen Fall der Server. Der große Unterschied ist, von wo aus die Logik nutzbar ist. Und dass der Server die dll besser, nämlich vollständig, mit DB-Kontext versorgt als ein Client es kann.
Angenommen, ich will bestimmte Datenbankvorgänge in ein Ticketsystem triggern, und habe einen Webclient, 2 Apps, drei Desktopanwendungen in verschiedenen Sprachen und Betriebssystemen, außerdem eine proprietäre Shopschnittstelle und eine Message Queue, die alle auf der DB hantieren. Dann will ich die Logik in der Datenbank. Denn a) muss das nicht in jeder der Anwendungen umgesetzt werden und b) bis die connectivity libs aller Anwendungen die Features unterstützen, die ich evtl brauche, bin ich Großvater. Oder unterstützen eure connectivity libs Firebird 4 vollständig? Ich kenne bisher nur fbintf (Pascal) und https://github.com/FirebirdSQL/fdb (Python) von Pavel Cisar, die das tun. Können eure connectivity libs Booleans, die neuen decimals, abweichende security-DB, Timestamp mit Zeitzonen, batch API, UDRs? Kann man mit C#/VB.Net UDRs schreiben?
Grüße, Volker
Wie gesagt, bei der entsprechenden Konzeption ist dies alles auch ohne UDR möglich.
Ich schreibe eben Desktop und Webapps, die allerdings auch gemeinsame Komponenten haben. Der Unterschied ist lediglich der Frontend.
Webservices können auf dieselben komponenten zugreifen in denen die Geschäftslogik gekapselt ist.
Ich stelle keine Software für verschiedene Plattformen her, da eine Webapp sowieso auf jeder Plattform funktioniert.
Bisher musste ich seit FB 1.5 keinerlei Anpassungen beim Wechsel auf 2.5 und 3.0 durchführen. 4.0 steht noch aus, aber das wird kein Problem werden.
Und wer sich mit dem Thema Zeitzonen schon mal auseinandergesetzt hat (bei mir seit ca. 1985 mit Unix) weiß, dass ein Timestamp in UTC in der Datenbank vollkommen ausreichend ist.
Selbst in den Dateisystemen werden Timestamps in UTC gespeichert, da die Einstellungen des Betrachters für die korrekte Anzeige in Localtime reicht.
Die DB braucht dies nicht zu wissen, da alle Sortier und ähnliche Vorgänge sowieso ohne die Zeitzone erfolgt.
Was die Typunterstützung angeht, so verwende ich immer den .Net FBClient. Solange da die Typen unterstützt werden ist doch alles OK.
Und wenn ich meine Anwendung so betrachte, bin ich bisher mit nur wenigen Typen vollkommen ausgekommen.
Unser Zugriffsschutz läuft seit FB 1.5 vollkommen außerhalb der DB in gekapselten Komponenten und unterstützt schon lange Rowfilter und ich brauchte mich da nicht umstellen. Klar ist, dass ein DB-Klau generell abgesichert sein muss.
Für Fremdanwendungen werden Libs (.Net) oder REST-API's angeboten. Das Schöne an .Net und sogut wie allen anderen Sprachen, natürlich nur Windows, ist die Unterstützung von COM-Interop (Component Object Model).
Somit konnte ich bereits mit .Net 2.0 COM-Klassen bereitstellen, die ich in den alten VB6-Anwendungen verwenden konnte. Die COM-Klassen ließen sich dann ebenso leicht in .Net 4.x umstellen ohne dass ich eine Zeile Code bei den Verwendern der Komponente habe ändern müssen. Und selbst die .Net-Komponente bedurfte nur der Erstellung mit der neuen Runtime, war somit sourcekompatibel.
Tja, und zu guter letzt wäre mit geringem Aufwand der Wechsel zu einem anderen DB-System einfach möglich, da man auf DB-spezifische Abhängigkeiten wie Trigger und UDR's keine Rücksicht nehmen muss.
Wie gesagt: alles eine Frage der Konzepte;-).
Ich schreibe eben Desktop und Webapps, die allerdings auch gemeinsame Komponenten haben. Der Unterschied ist lediglich der Frontend.
Webservices können auf dieselben komponenten zugreifen in denen die Geschäftslogik gekapselt ist.
Ich stelle keine Software für verschiedene Plattformen her, da eine Webapp sowieso auf jeder Plattform funktioniert.
Bisher musste ich seit FB 1.5 keinerlei Anpassungen beim Wechsel auf 2.5 und 3.0 durchführen. 4.0 steht noch aus, aber das wird kein Problem werden.
Und wer sich mit dem Thema Zeitzonen schon mal auseinandergesetzt hat (bei mir seit ca. 1985 mit Unix) weiß, dass ein Timestamp in UTC in der Datenbank vollkommen ausreichend ist.
Selbst in den Dateisystemen werden Timestamps in UTC gespeichert, da die Einstellungen des Betrachters für die korrekte Anzeige in Localtime reicht.
Die DB braucht dies nicht zu wissen, da alle Sortier und ähnliche Vorgänge sowieso ohne die Zeitzone erfolgt.
Was die Typunterstützung angeht, so verwende ich immer den .Net FBClient. Solange da die Typen unterstützt werden ist doch alles OK.
Und wenn ich meine Anwendung so betrachte, bin ich bisher mit nur wenigen Typen vollkommen ausgekommen.
Unser Zugriffsschutz läuft seit FB 1.5 vollkommen außerhalb der DB in gekapselten Komponenten und unterstützt schon lange Rowfilter und ich brauchte mich da nicht umstellen. Klar ist, dass ein DB-Klau generell abgesichert sein muss.
Für Fremdanwendungen werden Libs (.Net) oder REST-API's angeboten. Das Schöne an .Net und sogut wie allen anderen Sprachen, natürlich nur Windows, ist die Unterstützung von COM-Interop (Component Object Model).
Somit konnte ich bereits mit .Net 2.0 COM-Klassen bereitstellen, die ich in den alten VB6-Anwendungen verwenden konnte. Die COM-Klassen ließen sich dann ebenso leicht in .Net 4.x umstellen ohne dass ich eine Zeile Code bei den Verwendern der Komponente habe ändern müssen. Und selbst die .Net-Komponente bedurfte nur der Erstellung mit der neuen Runtime, war somit sourcekompatibel.
Tja, und zu guter letzt wäre mit geringem Aufwand der Wechsel zu einem anderen DB-System einfach möglich, da man auf DB-spezifische Abhängigkeiten wie Trigger und UDR's keine Rücksicht nehmen muss.
Wie gesagt: alles eine Frage der Konzepte;-).