Select Abfrage einmalig langsam

[Dr. Jack]

OK danke für deine Erklärung.
Ich dachte eigentlich, dass nur die angefragten Daten, also lediglich ein paar Kilobyte, über das Netzwerk geschickt werden und nicht die ganze Datei. Die ist tatsächlich 130 Megabyte groß.
Dann ist es natürlich nicht verwunderlich dass er ca 10 Sekunden braucht um es im RAM zu catchen.
Vielleicht wäre eine Möglichkeit, dass man beim Programmstart erstmal die Datei in den RAM im Hintergrund holt und eine Art Countdown für den User macht.
Oder kann ich das eventuell ändern, dass ich tatsächlich nur die Daten hole, die ich Abfrage? Nehmen wir an dass die Datenbank auf einige Gigabyte wächst, dann wäre das doch eine einzige Katastrophe wenn sie erst geladen werden würde?!
Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

[jobo]

Zitat von Dr. Jack:

Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

Gute Gedanken!

SQLite ist tatsächlich für den lokalen Gebrauch gedacht und bringt diese Effekte mit sich. Viele andere gängige SQL Server sind echte Server und bringen durch ihre Installation genau das mit, was Du als "Requester" bauen möchtest. Davon will ich Dich natürlich nicht abhalten, aber:

Installier Dir z.B. Firebird oder Postgres auf irgendeinem Rechner (zunächst tut's der Entwicklungsrechner) und jeder Client holt per SQL nur die Datenmenge aus der DB, die die Abfrage liefert.
Mit Firebird hättest Du noch das Feature, dass es kompatibel zum "großen Bruder" auch als embedded System lokal eingesetzt werden kann, als Singleusersystem (falls das tatsächlich ein Bedarf ist).

[Bernhard Geyer]

Zitat von Dr. Jack:

Oder kann ich das eventuell ändern, dass ich tatsächlich nur die Daten hole, die ich Abfrage? Nehmen wir an dass die Datenbank auf einige Gigabyte wächst, dann wäre das doch eine einzige Katastrophe wenn sie erst geladen werden würde?!
Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

oder du nimmst einfache einen der "üblichen" Verdächtigen wie MySQL, MS SQL Server, Oracle, Firebird und Co. und lässt diesen SQL-Servern genau das machen.
Dafür wurden diese u.A. auch entwickelt um genau das zu machen.

[p80286]

Zitat von Bernhard Geyer:

Zitat von Dr. Jack:

Oder kann ich das eventuell ändern, dass ich tatsächlich nur die Daten hole, die ich Abfrage? Nehmen wir an dass die Datenbank auf einige Gigabyte wächst, dann wäre das doch eine einzige Katastrophe wenn sie erst geladen werden würde?!
Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

oder du nimmst einfache einen der "üblichen" Verdächtigen wie MySQL, MS SQL Server, Oracle, Firebird und Co. und lässt diesen SQL-Servern genau das machen.
Dafür wurden diese u.A. auch entwickelt um genau das zu machen.

man kann es nicht groß genug schreiben!
Gruß
K-H

[jobo]

Und nicht oft genug:

Zitat von jobo:

.. Viele andere gängige SQL Server sind echte Server und bringen durch ihre Installation genau das mit, was Du als "Requester" bauen möchtest. Davon will ich Dich natürlich nicht abhalten, aber:

Installier Dir z.B. Firebird oder Postgres auf irgendeinem Rechner (zunächst tut's der Entwicklungsrechner) und jeder Client holt per SQL nur die Datenmenge aus der DB, die die Abfrage liefert.
...

[Delphi.Narium]

Sagen wir mal so: Für 'ne Datenbankanwendung sollte man 'ne Datenbank nutzen.

SQLite ist für mich genausowenig 'ne Datenbank, wie damals dBase oder Paradox per BDE. Ja das ging für 'nen Einzelplatz und nicht so übermäßig große Datenmengen oder ein reines Auskunftssystem. SQLite mag auch für das Speichern der Konfiguration des FireFox (oder ähnlichem) gut sein, aber 'nen Mehrbenutzerbetrieb mit 'ner im Netz liegenden Datei halte ich für suboptimal (oder eher absoult abwegig).

Wer auf so 'ne Idee kommt, sollte sich erstmal grundlegend mit dem Sinn und Zweck von Datenbanken beschäftigen und sich Grundlagenwissen verschaffen. Warum haben wohl 1000de Entwickler über Jahrzehnte Hirnschmalz und Manpower in die Entwicklung von Datenbankservern gesteckt, wenn man die gleiche Leistung auch mit 'ner eingebundenen DLL und 'ner Datei irgendwo im Netz hinbekommt?

Die Tatsache, dass man mit 'ner dateibasierten "Datenbank" das irgendwie hinbekommen kann, ist nicht gleichbedeutend mit: "Das ist ein sinnvolles Vorgehen."

[rokli]

Hallo,

und selbst Microsoft gibt Dir die SQL kostenlos (Developer Version) - oder schau mal nach SQLExpress, auch die hat für kleine Datenmengen nur minimale Einschränkungen gegenüber einer gekauften MS SQL DB, bei der Du dann auch die Clients anschaffen musst.

Gruß

[MichaelT]

Nehme eine der üblichen Verdächtigen. Es gibt davon genug.

--

Es gibt eine Datenbank namens cubeSQL (SQLite based 'Server').

Aber meine letzten Erfahrungen die DB an Delphi anzubinden waren eher ernüchternd. Die DB selbst ist wofür sie gemacht wurde ganz in Ordnung. Aber ohne eine sauber implementierten Nativetreiber ... der Aufwand steht nicht dafür.

Zitat von p80286:

Zitat von Bernhard Geyer:

oder du nimmst einfache einen der "üblichen" Verdächtigen wie MySQL, MS SQL Server, Oracle, Firebird und Co. und lässt diesen SQL-Servern genau das machen.
Dafür wurden diese u.A. auch entwickelt um genau das zu machen.

man kann es nicht groß genug schreiben!
Gruß
K-H

[TigerLilly]

Zitat von rokli:

oder schau mal nach SQLExpress, auch die hat für kleine Datenmengen nur minimale Einschränkungen gegenüber einer gekauften MS SQL DB

Wobei "Einschränkungen" sehr großzügig zu verstehen ist. Die Max-Größe pro DB ist mit 10 GB beschränkt + es werden nur 4 Prozessorkerne unterstützt. Dann gibt es noch Einschränkungen bei Failover + Verschlüsselung. Aber wer sowas braucht, denkt eh gar nicht an Express.

Siehe hier: https://www.microsoft.com/de-de/sql-...-2017-editions

[Uwe Raabe]

Zitat von TigerLilly:

Die Max-Größe pro DB ist mit 10 GB beschränkt + es werden nur 4 Prozessorkerne unterstützt. Dann gibt es noch Einschränkungen bei Failover + Verschlüsselung.

Wir reden hier über ein brauchbares Replacement für eine SQLite DB auf einem Netzlaufwerk!