Access oder MySQL

[gocher]

Sorry nein, das meinte ich nicht, ich meinte nur, sicherlich ist man als Neueinsteiger in einen neuen Bereich mehr aus Debugging angewiesen!

Ca 50% meiner Projekte sind ISAPI-DLLs, sonst schreibe ich auch häufig multithreading Programme und DLLs /SOs da ist das Debuggen schwerer als Logging, vorausgesetzt man hat eine thread-sichere Logging Funktion. Desktop Anwendungen sind bei mir eher die Seltenheit.

Bei mir ist halt alles ziemlich objektorientiert und jedes Objekt bekommt als erstes eine Methode zum Rückmelden eines Fehlers verpasst oder hat sie schon durch die Ableitung der Klasse, das geht dann alles zum Application Object und das schreibt dann alles in einen Logfile mit Angaben wie Klasse, Methode und Fehlermeldung. Habe ich das Programm fertig lasse ich diese Funktion noch einige Zeit aktiv und habe dadurch die Möglichkeit Fehler auch im Betrieb zu finden, läuft es dann eine Zeit komplett ohne Probleme, compiliere ich das Programm ohne Logging, dadurch wird es dann noch einmal etwas schneller.

CGI-Application meinte ich schon mit Lazarus nicht mit PHP, ich schreibe auch schon seit einiger Zeit Objekte in PHP, wenn es aber zu viel Objekte sind, wird PHP nun mal langsam. Vor allem wollte ich aber nicht PHP als wirkliche alternative aufzählen, man kann zwar wenn man nicht viel Erfahrung schneller ans Ziel kommen aber jede Ausführung ist langsamer.

[gocher]

Zugriffe auf Access
TickCount Angaben entsprechen Millisekunden 1.CreateOleObject Variante, 2. eigene ADO Komponente und 3. Zeos über ADO
TickCount: 19400, 19000, 19600

Code: Alles auswählen

    rs.Open('SELECT * FROM test', cn, adOpenForwardOnly, adLockReadOnly);
    //list fieldnames
    for i:=0 to rs.Fields.count-1 do
      Write(IIF(i>0, ';') + rs.Fields[i].Name);
    WriteLn();   
    //list values  
    while not rs.eof do
    begin
      for i:=0 to rs.Fields.count-1 do
        Write(IIF(i>0, ';') + VarToStr(rs.Fields[i].Value));
      //bei Zeos und meiner ADO Write(IIF(i>0, ';') + rs.Fields[i].AsString);
      WriteLn();
      rs.MoveNext; //bei Zeos rs.Next;
    end;
    rs.Close;
 

Änderung des Schleifeninhalts, reduziert die Verarbeitungszeit auf 20%-25%
TickCount: 4050, 4290, 5440

Code: Alles auswählen

    rs.Open('SELECT * FROM test', cn, adOpenForwardOnly, adLockReadOnly);
    //list fieldnames
    s := '';
    for i:=0 to rs.Fields.count-1 do
      s := IIF(i>0, ';') + rs.Fields[i].Name;
    WriteLn(s); 
    //list values 
    while not rs.eof do
    begin
      s := '';
      for i:=0 to rs.Fields.count-1 do
        s := s + IIF(i>0, ';') + VarToStr(rs.Fields[i].Value); 
        //bei Zeos und meiner ADO s := s + IIF(i>0, ';') + rs.Fields[i].AsString;
      WriteLn(s);
      rs.MoveNext; //bei Zeos rs.Next;
    end;
    rs.Close
 

Änderung in Einmalige Komplettausgabe, reduziert erneut das Ergebnis auf 15%-20%
TickCount: 2550, 3400, 4350

Code: Alles auswählen

    rs.Open('SELECT * FROM test', cn, adOpenForwardOnly, adLockReadOnly);
    s := '';
    //list fieldnames
    for i:=0 to rs.Fields.count-1 do
      s := s + IIF(i>0, ';') + rs.Fields[i].Name;
    s := s + #13#10;   
    //list values 
    while not rs.eof do
    begin
      for i:=0 to rs.Fields.count-1 do
        s := s + IIF(i>0, ';') + VarToStr(rs.Fields[i].Value);
        //bei Zeos und meiner ADO s := s + IIF(i>0, ';') + rs.Fields[i].AsString;
      s := s + #13#10;
      rs.MoveNext; //bei Zeos rs.Next;
    end;
    WriteLn(s);
 

Genau die Datenbankzugriffe machen in diesem Fall gerade mal 5%-10% aus
TickCount: 940, 980, 2100

Code: Alles auswählen

    rs.Open('SELECT * FROM test', cn, adOpenForwardOnly, adLockReadOnly);
    for i:=0 to rs.Fields.count-1 do
      s := rs.Fields[i].Name; 
    while not rs.eof do
    begin
      for i:=0 to rs.Fields.count-1 do
        s := VarToStr(rs.Fields[i].Value);
        //bei Zeos und meiner ADO s := rs.Fields[i].AsString;
      rs.MoveNext; //bei Zeos rs.Next;
    end;

ADO ist am Ende doppelt so schnell wie Zeos, aber wenn man schlecht programmiert fällt das überhaupt nicht ins Gewicht!

Ach ja habe ich noch vergessen, kleiner Nachtrag, in der letzten Version habe ich nochmal den Zugriff über Zeos auf MySQL getestet, so ist Zeos auf MySQL genau so schnell wie ADO auf ACCESS.

Code: Alles auswählen

program zeos;
{$APPTYPE CONSOLE}
{$mode objfpc}{$H+}
uses Classes, SysUtils, ZConnection, ZDataset;
 
var
  cn: TZConnection;
  rs: TZQuery;
  i: integer;
  s: string;
begin
//connect db
  cn := TZConnection.Create(nil);
  cn.Protocol := 'mysql-5';
  cn.Database := 'testdb';
  cn.HostName := 'localhost';
  cn.Port := 3306;
  cn.User := 'root';
  cn.Password := 'root';
  cn.Connect();
//select
  rs := TZQuery.Create(nil);
  rs.Connection := cn;
  rs.SQL.Add('SELECT * FROM test');
  rs.Open;
//list fieldnames
  for i:=0 to rs.Fields.count-1 do
    s := rs.Fields[i].Name;
//list values
  while not rs.eof do
  begin
    for i:=0 to rs.Fields.count-1 do
      s := rs.Fields[i].AsString;
    rs.Next;
  end;
//close recordset
  rs.Close;
  rs.Free;
//close connection;
  cn.Disconnect;
  cn.Free;
end.

Alle Angaben beziehen sich auf lokale Zugriffe!

[Christian]

Was soll uns das jetzt sagen ?
Zeos nimmt dir alles Datenbankspezifische ab indem es etliche Zwischenschichten einzieht.
Es ist einfach selbsterklärend das ein direkter Zugriff aufs Datenbanksystem schneller ist.
Das ist in der Praxis aber irrelevant, da niemand zigtausende Inserts in der Sekunde macht o.ä.
Der einzige Fall den ich mir vorstellen kann wo das was ausmacht wäre ein import oder export kompletter Tabellen.
Mein ERP z.b. ist durchgängig mit Zeos gebaut und bei allen Vergleichsystemen die aufkommen trotsdem immer das schnellste.

[mschnell]

Und da ZEOS jetzt auch JET (via ADO) kann, gibt es kaum einen Grund, es nicht einzusetzen. Ein Umstellung der Datenbank auf ein anderes Server-System und auch die erstellung eines Programms, das alternativ oder gleichzeitig mit verschioedenen Systemen arbeiten kann, sollte auch kein Problem sein.

Einziger Vorbehalt: wenn neuartige Server auf den Markt kommen oder sich in neuen Versionen eines Servers relevante Änderungen ergeben. muss das ZEOS-Team aktiv werden, bevor die User das verwenden können-.

-Michael

[Christian]

@Michael, ich hab jetzt ne erste version vom Promet fertig mit ner Bilder/Dokumentenvorschau warscheinlich sehr ähnlich zu deinem beschriebenem Bildorganisationsprogramm. Hab das eben mal auf ne Postgres gehängt und kann nur sagen, ich kanns mir nicht flüssiger vorstelln. Hab in der aktuellen Ansicht ca 40 Thumbnails pro Seite die werden aus ner PG DB über ein 10Mbit Netzwerk von nem Linux das auf nem 1,6 Ghz Single Core Atom läuft also alles andere als optimale Bedingungen und man kann absoulut flüssig mit dem Scrollrad durchscrollen.

[gocher]

Ich hab doch eigentlich sehr deutlich geschrieben um was es mir geht!
Vor über einer Woche stelle ich eine nicht optimierte Routine online und gebe Messergebnisse an.
Resultat: kein Mensch stört sich an der Routine
Ich schreib noch eine Möglichkeit für alle Zeos Fans damit diese auch mit machen.
Resultat: ein Download (ich schätze mal von Michael)
Ich gebe Gründe an die für ADO Sprechen (aber nun ja auch unter Zeos genutzt werden können).
Ich spreche meine Empfehlung für die Umsetzung mit Zeos aus, aber Datenbank ist mir egal.
Gestern Morgen mache ich Euch darauf aufmerksam wie relevant Datenbanken in Programmen sind, stoße Euch noch mal auf meine Routinen, fordere Euch heraus und stelle Euch dann noch ein Progrämmchen zum Zeitmessen zur Verfügung.
Gestern Abend kläre ich auf.

Datenbanken haben in den meisten Anwendungen zeitlich eine sehr untergeordnete Rolle, oft auch dadurch das in die Optimierung eines Programms selten viel Zeit investiert wird, viel schneller kommt der schlaue Spruch: "Das gibt die Datenbank halt nicht her, die sollte mal gewechselt werden!"

Es waren nur ein paar Zeilen Code, die ich schon häufiger missbraucht habe um z.B. Kollegen klar zu machen wo das Problem liegt, die auch Euch eigentlich klar machen sollten, in 95% aller Fälle ist es egal ob Ihr ADO(ist halt schneller bei Access) oder Zeos(ist halt schneller bei MySQL) einsetzt, egal welche Datenbank Ihr einsetzt, lernt Eure Fähigkeiten zu nutzen und vor allem wie ich schon mal erwähnt habe überprüft Eurer Wissen (ruhig mal Messen)!

Und so noch einmal für Die die immer zu schnell einen Angriff gegen Zeos von mir sehen, ich spreche mich hier noch einmal für Zeos aus, auch wenn es unter Umständen auch mal langsamer ist, denn dieser Zeitliche Aspekt ist zu vernachlässigen gegenüber der Anwenderfreundlichkeit bei der Entwicklung.

Für einen Datenbank-Einsteiger ist Access jedoch wesentlich anwenderfreundlicher und wenn mehrere Hürden zu nehmen sind sollte man sie nicht stapeln.

[Christian]

Ach so, ich hab nichts gesehn gehabt das jemand den Geschwindigkeits Aspekt infrage gestellt gehabt hat.
Deswegen hat mich die Messerei verwundert.

[ErnstVolker]

Hallo zusammen,

ich habe in Zusammenhang auf Datenbanken einige unterschiedliche Fragen:

1.) Ich habe auf dem Mac (64 bit) eine SQLite DB und greife entsprechend der gefundenen Tutorials darauf zu. Das funktioniert auch, nur das DBGrid auf meinem Formular bleibt leer. Es wird zwar das Zeilengitter angezeigt, aber alles Leer, kein Inhalt. Die Spalten der Testdatenbank sind mit integer für PK und Varchar für Nachname Vorname definiert.

2.) Auf meinem Linux System (32 bit) habe ich das Problem mit PostgreSQL. Das DBGrid bleibt leer. Erweitere ich die Datenbank mit pgAdmin um einen Eintrag, wird später das leere Gitter des DBGrid um eine Zeile erweitert. Aber keine Inhalt in den Zellen.

3.) Auf Windows habe ich es noch nicht versucht.

4.) Auf dem Mac hatte ich versucht dasselbe Problem auch mit PostgreSQL und MySQL zu versuchen. Hier kam jeweils die Meldung, dass DLL's fehlen würden um die Datenbanken ansprechen zu können. Ich solle die Lazarusinstallation prüfen. Durch Netzrecherche habe ich herausgefunden, dass alles 64 bit sein muß. Lazarus und Datenbankserver. Da Lazarus für Mac nur 32 bit ist, Pech gehabt. Oder kann man für PostgreSQL und MySQL 32 bit DLL's (die Dinger nennen sich beim Mac nicht DLL - dynlib oder so) nachinstallieren? Wenn ja, wie geht das und wo bekommt man sie her?

Vielen Dank und viele Grüße

Volker

[af0815]

ich habe in Zusammenhang auf Datenbanken einige unterschiedliche Fragen:

1.) Ich habe auf dem Mac (64 bit) eine SQLite DB und greife entsprechend der gefundenen Tutorials darauf zu. Das funktioniert auch, nur das DBGrid auf meinem Formular bleibt leer. Es wird zwar das Zeilengitter angezeigt, aber alles Leer, kein Inhalt. Die Spalten der Testdatenbank sind mit integer für PK und Varchar für Nachname Vorname definiert.

2.) Auf meinem Linux System (32 bit) habe ich das Problem mit PostgreSQL. Das DBGrid bleibt leer. Erweitere ich die Datenbank mit pgAdmin um einen Eintrag, wird später das leere Gitter des DBGrid um eine Zeile erweitert. Aber keine Inhalt in den Zellen.
.. .
Volker

Ad1 u 2) Ich würde in einer Testschleife mir die Werte im Debugger ansehen, was da hereinkommt. Ob das Grid recht hat oder nicht.

[ErnstVolker]

Hallo af0815,

blöde Frage: Wie stelle ich das an?

Ich hab' das komische Gefühl, dass irgendwo im Objektinspektor eine Einstellung falsch ist, aber keine Ahnung wo.
Auch wenn ich im OI für SQLQuery unter SQL select * from adressen eingebe und Active auf true setze passiert im DBGrid nichts. Nur in der Datenanzeige des SQLQuery selbst werden die Daten angezeigt. Also wenn man das SQL-Statement über den grünen Pfeil des "Statement-Editors -so nenne ich ihn mal" abschickt.

Vielen Dank

Volker

[ErnstVolker]

Hallo Zusammen,

ich muß hier nochmal auf einen alten Beitrag einsteigen. Ich habe meine Anwendung damals doch mit Access erstellt. Alleine schon deswegen, weil mir auf der Arbeit nix anderes zur Verfügung stand/steht. Allerdings gab es ein Problem:

Ich hatte die fertige Anwendung geteilt, in ein Frontend und ein Backend. Das Backend auf einen Rechner "A" gelegt, das Frontend mit Formularen, Abfragen und Berichten auf einen Rechner "B". Mittels des Tabellenvernüpfungsmanger habe ich die Verbindung zwischen beiden hergestellt und meine Kollegen gebeten, doch mal einige Tests durchzuführen und die DB mit Daten zu füttern. Nur leider stürzte die Frontendanwendung nahezu schneller ab als ich sie starten konnte. Aus völlig heitrem Himmel brach alles zusammen. Von einem weiteren Rechner "C" war es nicht ganz so häufig aber auch der Fall. Da habe ich dann aufgegeben.

Jetzt überlege ich daran Access mit Firebird zu verknüpfen. Das Backend auf Firebird zu bauen und für Formulare und Berichte Access zu nehmen. Was haltet Ihr davon?
Bei meinen ersten Tests stoße ich jedoch auf ein Problem mit Blobs. In der FB-DB ist ein Feld mit "Blob Sub-Type 0 Segment Size 80" definiert. Das wird in Access als OLE-Objekt angezeigt. Wenn ich mit "MiTeC IB Query" (unter Windows mein Administrationsproramm) ein Bild einfüge, wird es in Acces nicht geöffnet. Füge ich jedoch in Access in OLE-Objekt ein Bild ein, kann ich es öffnen. Es wird jedoch bei "MiTeC" nur als Hex angezeigt. Eigentlich reicht ja der Weg von Access nach Firebird. Ich will halt die Bilder in der DB speichern und dann monatlich und ggf. am Jahresende mit "gbak" ein Backup ziehen und getrennt wegsichern. Access hat für Bilder den Datentyp "Anlage", aber der funzt nicht mit Firebird.

Zum Thema Backup würde ich gerne wissen, wie die dump-Programme von MySQL oder PostgreSQL gegenüber gbak funktionieren. Kann man mit "...-dump" erzeugte Backupdateien auch "einfach" wegsichern und ggf. bei Restore vorher wieder an den ursprünlichen Ort kopieren?

Viele Grüße

Volker

[Michl]

Zum Thema Backup würde ich gerne wissen, wie die dump-Programme von MySQL oder PostgreSQL gegenüber gbak funktionieren.

Ich habe lange kein MySQL mehr getestet, aber Postgres im Einsatz, daher antworte ich mal nur für PostgreSQL.

Kann man mit "...-dump" erzeugte Backupdateien auch "einfach" wegsichern und ggf. bei Restore vorher wieder an den ursprünlichen Ort kopieren?

Ja kann man. Man kann aber auch den Pfad des Backups angeben und die Sicherungsfiles fortlaufend nummerieren oder mit einem Zeitstempel im Namen versehen, dann braucht man diese nicht zu zwingend kopieren.

Unter PostgreSQL kannst du ein mitgeliefertes externes Tool (pg_dump) nutzen und es z.B. mit TProcess mit entsprechenden Paramtern aufrufen. Funktioniert einwandfrei. Bei einem Backup muss man allerdings aufpassen, dass man vorher alle Verbindungen zur Datenbank freigibt, sonst kann es nicht aufgespielt werden. Weitere Infos sind hier: https://www.postgresql.org/docs/9.5/sta ... gdump.html

[Eb]

Kann man mit "...-dump" erzeugte Backupdateien auch "einfach" wegsichern und ggf. bei Restore vorher wieder an den ursprünlichen Ort kopieren?

Geht bei mysql auch. Wo die Sicherungsdatei liegt ist egal.
Sichern und wiederherstellen mache ich so:

Code: Alles auswählen

procedure Tfrm_einstellungen.db_backup(pfad,zieldatei : string);
var
  AProcess: TProcess;
  kommando: string;
  S : Longint;
begin
 
  AProcess := TProcess.Create(nil);
  {$IFDEF WIN32}
        case radio_mysql_version.ItemIndex of
             0     : kommando := 'cmd /c "C:\Programme\MySQL\MySQL Server 5.0\bin\mysqldump" -hlocalhost -uBenutzername -pPasswort Datenbankname > ' + pfad  + zieldatei;
             1     : kommando := 'cmd /c "C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqldump" -hlocalhost -uBenutzername -pPasswort Datenbankname > ' + pfad  + zieldatei;
             else    showmessage('Fehler bei Einstellungen - Mysql-Version');
        end;
 
        AProcess.CommandLine := kommando;
        AProcess.Execute;
  {$ENDIF}
 
 
  {$IFDEF LINUX}
 
    S:=Shell ('/usr/bin/mysqldump -hlocalhost -uBenutzername -pPasswort Datenbankname > ' + pfad + '/' + zieldatei);
 
 
    if S <> 0 then showmessage('Error! Command exited with status :' + inttostr(S))
              else showmessage('Sicherung OK');
 
   {$ENDIF}
 
 
  AProcess.Free;
 
end;
 
procedure Tfrm_einstellungen.db_restore(pfad,quelldatei : string);
var
  AProcess: TProcess;
  kommando: string;
  S : Longint;
begin
 
  AProcess := TProcess.Create(nil);
  {$IFDEF WIN32}
 
 
  case radio_mysql_version.ItemIndex of
       0     : kommando := 'cmd /c mysql -hlocalhost -uBenutzername -pPasswort Datenbankname <  ' + pfad + quelldatei;
       1     : kommando := 'cmd /c "C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql" -hlocalhost -uBenutzername -pPasswort Datenbankname <  ' + pfad + quelldatei;
       else    showmessage('Fehler bei Einstellungen - Mysql-Version');
  end;
 
  AProcess.CommandLine := kommando;
  AProcess.Execute;
 
  {$ENDIF}
 
  {$IFDEF LINUX}
    S:=Shell ('/usr/bin/mysql -hlocalhost -uBenutzername -pPasswort Datenbankname < ' + pfad + '/' + quelldatei);
 
    if S <> 0 then showmessage('Error! Command exited with status :' + inttostr(S))
              else showmessage('Restore OK');
 
  {$ENDIF}
 
  AProcess.Free;
 
end;  

Eb