Umstellung Paradox ->Firebird die 2.

[marabu]

Zitat:

Zitat von BrunoT

Das würde ja bedeuten, der Server würde bei Mehrfachaufruf der Anfrage diese optimiert ausführen(sozusagen halbintelligent)?

Grundsätzlich besteht diese Möglichkeit, aber die einzelnen RDBMS unterscheiden sich sehr stark in der Qualität ihrer query optimizer. Einen Parser für SQL bereit zu stellen ist da ungleich einfacher.

Zitat:

Zitat von BrunoT

Wie funktioniert der Application-Cache?

Ich habe dazu eine spezielle Klasse implementiert.

Delphi-Quellcode:

  TReadonlyCache = class
  ...
  public
    constructor Create(Size: integer; onRead: TReadFunc);
    ...
    procedure Clear;
    function Get(Key: integer): string;
  end;

Create() limitiert den Cache auf Size Einträge und definiert eine interne Lesefunktion. Mit Clear() kann der Cache geleert werden, um sich besser an eine neue Darstellung anzupassen. Mit Get() werden die benötigten Feldinhalte bereit gestellt, wobei key die recno des DB-Cursors ist und sich bei einer virtuellen ListView aus Succ(listitem.index) ergibt.

Zitat:

Zitat von BrunoT

Sollte das bedeuten, das ich anstelle dem DBGrid ein StringGrid verwende, eine Stringlist intern zur Verwaltung der benötigten Schlüssel oder Daten(vorauslesend)?

Eher eine TListView oder eine ähnliche Komponente, würde ich sagen.

marabu

[BrunoT]

Hi Marabu,

danke mochmal. Mir raucht der Kopf.
Ich habe mich bisher nicht an SQL-Datenbanken herangetraut, da diese u.U. sehr langsam sind (KHK- Handwerkerpaket mit MS-SQL bei 300.000 Artikelsätzen 10 sec. für eine Suchanfrage unter Paradox 1 sec.) und einen grossen Installationsaufwand bzw. Probleme mit TCP/IP(localhost unter XP) besitzen, ausserdem kaum ausführbar auf älterer Hardware (ab AMD k6/600, P3/700). Firebird scheint da ja besser zu sein.
Ich habe da bloss Manschetten, das die Performance meines Programmes durch ungünstige Zugriffsgestaltung leidet.
Wenn du da noch ein paar Literaturhimweise hättest? Oder nen Beitrag in der DP?

Ist es möglich, mit Firebird, einen Teil (readonly) der Datenbank auf der lokalen Festplatte zu halten und nur den verändelichen Teil(Tabellen) auf dem Server?(readonly = PLZ, Orte, Finanzämter - veränderlich = Kundendaten).
Oder in einen Application-Cache oder sollte ich bei jedem Programmstart diese Daten in einen Stream kopieren und damit arbeiten?

Ich hoffe, ich habe nicht zu grosse Löcher in den Bauch gefragt.

Ansonsten muss ich das erstmal verdauen und dann step by step.

mfg

BrunoT

[marabu]

Zitat:

Zitat von BrunoT

Ich habe mich bisher nicht an SQL-Datenbanken herangetraut, da diese u.U. sehr langsam sind.

Das ist ein Gerücht. Oft ist die Applikationslogik nicht auf Client-Server ausgelegt oder die Server werden falsch administriert. 300.000 Artikelsätze sind für ein RDBMS kein Problem, wenn sonst alles stimmt.

Deine Beschreibungen klingen so, als ob du bestehende Anwendungen aus der LAN-Welt durch "ein paar Änderungen am Quellcode" auf Client-Server migrieren möchtest. Das ist in der Regel unwirtschaftlich, besonders wenn das auch noch ein Forschungsgebiet für dich darstellt. Da wäre ein erfahrener Kollege an deiner Seite goldrichtig.

Zitat:

Zitat von BrunoT

Wenn du da noch ein paar Literaturhinweise hättest?

Eine Antwort darauf traue ich mir nicht zu - vielleicht weil ich schon zu lange in diesem Geschäft bin. Vielleicht gebe ich ein paar Hinweise, wenn ich deinen Kenntnisstand besser einschätzen kann.
Hier im Forum sind recht viele junge Leute unterwegs, die sich vielleicht in einer ähnlichen Lernsituation befinden, wie du. Vielleicht ergibt sich da noch etwas. Ich würde dich jetzt nur mit teurer Fachliteratur zuwerfen, die dir evtl. nicht wirklich was bringt.

Zitat:

Zitat von BrunoT

Ist es möglich, mit Firebird, einen Teil (readonly) der Datenbank auf der lokalen Festplatte zu halten

Natürlich geht sowas, aber ich bin nicht sicher, ob das was für dich ist - momentan - verstehe mich bitte nicht falsch.

marabu

[MagicAndre1981]

Zitat:

Zitat von BrunoT

Übrigens scheint in Firebird LIKE nicht zu funktionieren :gruebel:

Doch, das funktioniert, ist aber bei Strings sehr laaaangsam.

André

[Hansa]

Zitat:

Zitat von MagicAndre1981

Zitat:

Zitat von BrunoT

Übrigens scheint in Firebird LIKE nicht zu funktionieren :gruebel:

Doch, das funktioniert, ist aber bei Strings sehr laaaangsam.

André

Wie kommst Du denn da drauf ? :shock: Ich benutze LIKE z.B. sogar mit 2 %, also %Suchwort%. Jeder DS, der in einem einzugebenden Feld einen Bestandteil des Suchwortes enthält, wird dabei aus der DB gefischt. Dabei sind bisher keinerlei Langsamkeiten aufgefallen. Das dürfte wohl schon langsamer sein, als den genauen Text einzugeben, aber spürbar ist das nicht.

[MagicAndre1981]

Zitat:

Zitat von Hansa

Wie kommst Du denn da drauf ? :shock: Ich benutze LIKE z.B. sogar mit 2 %, also %Suchwort%. Jeder DS, der in einem einzugebenden Feld einen Bestandteil des Suchwortes enthält, wird dabei aus der DB gefischt. Dabei sind bisher keinerlei Langsamkeiten aufgefallen. Das dürfte wohl schon langsamer sein, als den genauen Text einzugeben, aber spürbar ist das nicht.

So wars bei mir. Andreas Kosch hatte in dem Buch zum Interbase das Thema angeschnitten und dann hab ich mir ein Testtool geproggt und da war LIKE langsamer als STARTING WITH.

Kann sein, dass das im FB1.5 anders ist, meine aussage bezog sich auf den FB1.0.3.

[BrunoT]

Hi Marabu,

ich bin hier um zu lernen. Die DP hat mir schon viel geholfen.

zu den "langsamen SQL-Datenbanken": als EDV-Dienstleister bin ich oft über solche schlecht gemachten Client-Server-Applicationen gestolpert.

Natürlich werde ich ein bestehendes Programm nicht zu SQL portieren(never touch a runnig system). Das ist ein neues Projekt, wo ich Teile aus alten Projekten recycle. Als Anfang mit Firebird habe ich mir natürlich eine vorhandene Programmlogik genommen, um mich nicht darum kümmern zu müssen.

Zu den getrennt abgelegten Daten: Ich werde warscheinlich zwei Datenbankdateien auf dem Server ablegen, eine mit den veränderlichen Daten, die andere mit den statischen. Das erleichtert die Datensicherung und ist vieleicht auch für die Performance besser.

Ach so: warum geht in einer Query der Filter nicht?(keine Datensätze) wozu benutzt man den überhaupt, wenn man alles mit SQL-Abfragen erschlagen kann?

Delphi-Quellcode:

procedure TFinanzaemter.TabChange(Sender: TObject);
var
  F: string;
begin
  begin
    if tab.tabindex = 26 then
    begin
//      ZQFinanzamt.Filtered := false
      ZQFinanzamt.Active := False;
      ZQFinanzamt.SQL.clear;
      ZQFinanzamt.SQL.Add('Select * from Finanzamt ORDER BY name');
      ZQFinanzamt.Active := True;

    end
    else
    begin
   {   F := format('Name = ''%s*''', [chr(Tab.TabIndex + 65)]);

      ZQFinanzamt.Filtered := false;
      ZQFinanzamt.Filter := F;
      ZQFinanzamt.Filtered := True; }
      ZQFinanzamt.Active := False;
      ZQFinanzamt.SQL.clear;
      ZQFinanzamt.SQL.Add('Select * from Finanzamt Where Name LIKE ''' + chr(Tab.TabIndex + 65) + '%'' ORDER BY name');
      ZQFinanzamt.Active := True;

    end;
  end;
end;

oder hätte ich dort auch % nehmen sollen?

mfg

BrunoT

P.S. @MagicAndre1981 Abfragen wie sonst? hat sich erledigt s.o.

[marabu]

Zitat:

Zitat von BrunoT

warum geht in einer Query der Filter nicht? (keine Datensätze)

Sollte eigentlich funktionieren, wenn du die richtigen wildcards verwendest.

Zitat:

Zitat von BrunoT

wozu benutzt man den überhaupt, wenn man alles mit SQL-Abfragen erschlagen kann?

Gute Frage. Bei SQL bin ich mir sicher, dass die Daten auf dem Server selektiert werden. Die Filter-Möglichkeiten von TDataset (Filter, Filtered, OnFilterRecord) stammen noch aus einer Zeit, als SQL noch nicht überall verfügbar war - sprich dBase III etc. Damit OnFilterRecord arbeiten kann muss jeder Datensatz erstmal vom Server zum Client transportiert werden. Das kann weh tun, aber ich kann mir auch positive Anwendungen vorstellen.

marabu