![]() |
AW: Select Abfrage einmalig langsam
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... |
AW: Select Abfrage einmalig langsam
Zitat:
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). |
AW: Select Abfrage einmalig langsam
Zitat:
Dafür wurden diese u.A. auch entwickelt um genau das zu machen. |
AW: Select Abfrage einmalig langsam
Zitat:
Gruß K-H |
AW: Select Abfrage einmalig langsam
Und nicht oft genug:
Zitat:
|
AW: Select Abfrage einmalig langsam
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." |
AW: Select Abfrage einmalig langsam
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ß |
AW: Select Abfrage einmalig langsam
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:
|
AW: Select Abfrage einmalig langsam
Zitat:
Siehe hier: ![]() |
AW: Select Abfrage einmalig langsam
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz