lblbw - Do 29.05.08 08:13
Titel: schneller Datenbankzugriff

---

Hallo,

ich will ein Programm schreiben, das sehr schnell auf eine Datenbank zugreifen muss.

Nun meine Fragen:
a) welche Datenbank kann ich dafür verwenden?
b) wie sieht der Zugriff auf a) aus?

Danke im Vorraus!

mkinzler - Do 29.05.08 08:23

---

Ist nicht so einfach zu beantworten. Kommt auf die Struktur der Daten, vorhandene Hardware, ... an.

lblbw - Do 29.05.08 08:43

---

Hardware ist variabel, da auf verschiedenen Rechnern Deutschlandweit. Die Stuktur beinhaltet neben Zahlenwerten, auch Texte variabler Länge.

baka0815 - Do 29.05.08 09:23

---

Sollen die verschiedenen Rechner deutschlandweit auf ein und dieselbe Datenbank zugreifen oder soll jeder Einzelplatz seine eigene DB haben?

Wenn du die DB nur brauchst um pro Client Daten zu hinterlegen, würde sich eine embedded DB anbieten, wie z.B. SQLite, HSQLDB, oder ähnliche.

Ansonsten kommt es auf die Größe des Projekts an und ob bzw. wieviele Lizenzkosten du bezahlen kannst/willst. Für "kleinere" Projekte würde sich z.B. eine MySQL DB anbieten, für größere Sachen PostgreSQL - beide Open-Source und kostenlos, aber für den oben genannten Fall beide der Overkill ;)

PostgreSQL kann ich auf Windows-System auch nur bedingt empfehlen, auf Unix/Linux funktioniert die deutlich besser.

lblbw - Do 29.05.08 10:43

---

Am liebsten wäre es mir, wenn alle Rechner auf eine Datenbank, die auf einen Server liegt zugreifen. Sie können dann zwar die Daten auslesen und hinzufügen, aber nicht bearbeiten.

alzaimar - Do 29.05.08 11:09

---

Definiere doch bitte erstmal, was 'schnell' für Dich bedeutet. Denn eigentlich sind alle DBMS schnell genug, sofern die DB-Struktur ordendlich erstellt wurde.

lblbw - Do 29.05.08 11:27

---

Die Datenbank wird sehr sehr groß sein (über 100MB). Dazu soll er innhalb von maximal 2 Sekunden die Daten ausgelesen bzw. hinzugefügt haben.

alzaimar - Do 29.05.08 11:31

---

Kein Problem, sofern das Suchkriterium (der/die Felder, nach denen gesucht wird) mit einem Index versehen wird. Dann werden das vielleicht 100ms pro Suchvorgang.
Du kannst Access, Firebird, MSSQL Express, mysql, PostGres, ach, egal was, nehmen.

lblbw - Do 29.05.08 11:35

---

Nur das du jetzt eine Sache nicht berücksichtigt hast. Die Zugriffszeit auf die Datenbank ist ja unterschiedlich je nach Verbindung. Ich meine mit den 2 Sekunden jeweils die langsamste Verbindung. Und da ist der Knackpunkt.

alzaimar - Do 29.05.08 11:38

---

Der Zugriff auf die DB ist in dem Bereich (Sekunden) nur abhängig von der Bandbreite. Ob Du ADO, ODBC, BDE, Zeos oder eine native API nimmst, ist hier vollkommen egal.

Wichtig ist eben die richtige DB (also Indexe, 3.NF etc.) und eine Bandbreite, die rein physikalisch in der Lage ist, in der Zeit die Daten zu liefern.

Habe ich Dich jetzt richtig verstanden?

lblbw - Do 29.05.08 12:45

---

Genau, der Zugriff muss innerhalb der vorgeschriebenen Zeit von 2 Sek. auf die Datenbank Zugriff haben, und diese auch ausgelesen haben. Das geht zum Beispiel nicht mit meiner Verbindung, die ich hier habe, da dauerts länger, bei der großen Datenmenge. Achso, was ich vergessen habe zu erwähnen, die Datenbank, hat nur eine einzige Tabelle, in der die Daten stehen.

jaenicke - Do 29.05.08 12:50

---

Das Problem ist wohl kaum die Verbindung, es sei denn mit der großen Datenmenge meinst du die Menge der abgefragten Informationen. (In dem Fall lässt sich da kaum etwas machen, außer mit Komprimierung z.B.)
Denn die Abfrage innerhalb der Datenbank hängt ja nicht davon ab wie schnell die Verbindung ist.

Wie schnell dort die Abfrage dann ist, hängt wie alzaimar bereits gesagt hat von der Struktur der DB, etc. ab. Eine einzige Tabelle der angegebenen Größe ist eben nicht ideal.

alzaimar - Do 29.05.08 14:06

---

Wieso müssen denn so viele Daten eingelesen werden? I.A. benötigt man das nicht. Aber gut, vielleicht muss das eben so sein.

Die einzige Möglichkeit, die ich sehe, wäre die, auf der Serverseite ein kleines tool zu schreiben, das die Abfrage nimmt, das Resultat komprimiert und zum client schickt. Der packt die Sau wieder aus und fertig.

Blöderweise benötigt das Komprimieren auch wieder Zeit, sodaß nur bei sehr schmalbandigen Verbindungen überhaupt ein Performancevorteil entsteht.

Ich meine, das man die Datenmenge beschneiden müsste.
1. Werden wirklich alle Spalten benötigt?
2. Werden wirklich alle Datensätze benötigt?

lblbw - Do 29.05.08 14:21

---

Es werden aus der Tabelle alle Spalten benötigt. Aber es wird nur 1 Datensatz benötigt. Aber dieser Datensatz muss auch erst von 1000 Datensätzen gefunden werden.

alzaimar - Do 29.05.08 14:26

---

Das Finden geht sehr schnell, sofern es im Server stattfindet. Kennst du dich mit SQL aus? Du schickst sowas zum Rechner 'Gibt mir alle Datensätze, deren Spalte "Name" mit 'A' anfängt und deren Spalte "Wert" = 3 ist' und der Server schickt Dir dann alle passenden Daten. Wenn Du also schon den einen Datensatz genau spezifizieren kannst, ist das alles kein Problem.

lblbw - Do 29.05.08 14:32

---

Gut, Danke für die Antwort. Werde mich dann jetzt bei machen und das Programm schreiben!

hazard999 - Do 29.05.08 14:35

---

Du meinst, du fängst mal an darüber nachzudenken wie die Datenbank auszusehen hat und was die Benutzer alles und in welcher Form aus ihr abholen.

Oder fängst du mit dem coden an?

hazard999 - Do 29.05.08 14:38

---

Du meinst, du fängst mal an darüber nachzudenken wie die Datenbank auszusehen hat und was die Benutzer alles und in welcher Form aus ihr abholen.

Oder fängst du mit dem coden an?

lblbw - Do 29.05.08 14:43

---

Ich fange mitdem Coden an, habe Testweise erstmal in der Datenbank 2 Datensätze eingetragen.

baka0815 - Do 29.05.08 16:35

---

Klingt nicht so, als hättest du schon mal mit einer Datenbank gearbeitet.

Eine Datenbank von 100MB ist alles, aber noch nicht groß. Ab 2GB können wir langsam von groß sprechen.

Eine Datenbank von 100MB Größe bei genau einer Tabelle hat ein Struktur-Problem!

Wenn du natürlich die 100.000 Datensätze erst abfragst und zu deinem Client überträgst und dann auf deinem Client aus den 100.000 Sätzen deinen einen raus suchst, dann hast du definitiv was falsch gemacht.

Die Spalten, nach denen du suchst brauchen einen Index (kannst du dir sparen wenn du mit LIKE suchst, da wird der eh nicht genutzt), dann hat jedes vernünftige DBMS deine Daten innerhalb von Millisekunden selektiert.

PS.: Wenn mehrere Leute gleichzeitig drauf zugreifen, würde ich NICHT Access verwenden - aber auch keine embedded DB :)

Und, schau dir unbedingt den Eintrag zu Normalisierung bei Wikipedia [http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)] an!

alzaimar - Do 29.05.08 16:43

---

baka0815 hat folgendes geschrieben:

Eine Datenbank von 100MB Größe bei genau einer Tabelle hat ein Struktur-Problem!

Wieso? Eine Tabelle (Datum, MessNr, Messwert) hat also ein Strukturproblem? Welches? :wink:

baka0815 hat folgendes geschrieben:

K....kannst du dir sparen wenn du mit LIKE suchst, da wird der eh nicht genutzt...

Falsch. Eine Abfrage "LIKE 'Foo%'" kann schon mit einem Index durchgeführt werden. :wink:

Bitte lies die Antworten erst durch, bevor Du eigentlich die gleichen Tipps gibst.

baka0815 - Do 29.05.08 17:02

---

alzaimar hat folgendes geschrieben:

baka0815 hat folgendes geschrieben: Eine Datenbank von 100MB Größe bei genau einer Tabelle hat ein Struktur-Problem! Wieso? Eine Tabelle (Datum, MessNr, Messwert) hat also ein Strukturproblem? Welches? :wink:

Ok, ich korrigiere mich auf "wahrscheinlich ein Strukturproblem". :)

Zitat:

baka0815 hat folgendes geschrieben: K....kannst du dir sparen wenn du mit LIKE suchst, da wird der eh nicht genutzt... Falsch. Eine Abfrage "LIKE 'Foo%'" kann schon mit einem Index durchgeführt werden. :wink:

Stimmt, hab' ich nicht dran gedacht...

Zitat:

Bitte lies die Antworten erst durch, bevor Du eigentlich die gleichen Tipps gibst.

Nun, hat auf mich nicht den Eindruck gemacht, als hätte er alles verstanden und wenn er keine Ahnung von DBs hat, kommt er vermutlich von "3.NF" wohl nicht auf "3. Normalform".

hazard999 - Fr 30.05.08 10:27

---

Das mit dem LIKE stimmt so nicht.

LIKE 'TEST%' ist für einen B*-Tree verwendbar

Verdammt. Wiedermal die 2. Seite übersehen.