Grundsatzfrage zu Datenbankprojekt

[stahli]

Ja, es geht ja gerade um einen Umstieg von der BDE zu einem ordentlichen SQL-DB-Server.

Die Frage ist nun, wie man bei einer Multi-Tier-Anwendung oder auch einer Browseranwendung mit einer großen Tabelle umgeht. Man wird wohl - um in meinem Beispiel zu bleiben - immer erst eine Straße selektieren lassen und alle weiteren Funktionen auf diese Straße begrenzen. Oder?

Wobei ich einen solchen Ansatz aber nicht wirklich schön finde. Das wäre für mich auf jeden Fall ein PRO für eine klassische Datenbankanbindung.


@jobo

Mal zum Hintergrund (wobei es darauf weniger ankommt).
Die Tabellen sind normalisiert. Die Grundstückstabelle enthält die Straßenschlüssel und die Hausnummern. Es gibt ca. 40000 Grundstücke.

Der benötigte Straßenschlüssel wird zunächst in der Straßentabelle ermittelt. Die enthält die Straßennamen und "SortStraßennamen" (mit aufgelösten Umlauten und ss statt ß).

Leerzeichen im Suchtext stehen für ein Wortende. Groß/Kleinschreibung ist nicht relevant.

"n" findet z.B. "Nachtigallensteig"
"n " auch noch
"neu" würde dagegen "Neuragoczystr" finden (siehe Bild oben)
"n p" findet "Neustädter Passage" da es die erste/einzige Straße ist, bei der das erste Wort mit "N" und das zweite mit "P" beginnt.


Mir ging es aber nicht darum, diese Funktion in SQL umzusetzen, sondern einfach darum, wie man in Multi-Tier-Probjekten oder Browseranwendungen mit großen Tabellen umgeht.
Ohne eine "Vorselektierung" oder wenigstens "Datensatzbeschränkung" wird das wohl nicht funktionieren.
Ich fände das aber ziemlich unschön und würde dann eine native Datenbankanbindung wenn möglich bevorzugen. Für das GUI-Design stelle ich mir das einfach besser vor.
Der User kann somit "die gesamte Tabelle" vor sich sehen und muss sich nicht erst bestimmte Häppchen daraus laden.

[WM_CLOSE]

Mach es doch so wie Google bei seiner Bildersuche:
Lade nur den Teil (nach) der gerade z.B. auf Grund der Scrollposition benötigt wird.

[Phoenix]

Schieb doch einfach die Sucheingabe auf den Middle-Tier, lass den Suchen und liefer nur das gefilterte Ergebnis zurück.
Und nein, das geht nicht mit DataSnap, aber DataSnap ist auch kein Middle-Tier Server sondern will nur spielen. Für Real-World Anwendungen ist das Ding nicht zu gebrauchen. Mit einem selbst gebauten Middle-Tier der anständigen Frameworks ist sowas aber kein Problem.

Edit Nachtrag: Beispiel Finanzen.net
Geb mal in der Suchmaske "Mic" ein, warte dann auf die anzeige, und verfeiner dann z.B. mit " Fonds".
Das ganze wird zum Server (Middle-Tier) geschickt, eine Volltextsuche auf die Datenbank losgelassen, bestimmte Schlagworte sorgen für eine genauere Filterung, und der Client bekommt nur noch das Ergebnis zurück. Und dafür müssen nur minimal Daten übertragen werden.

[jobo]

Wenn Du wirklich so große Datenmengen darstellen willst, kommst Du trotz DB Server nicht um eine Clientdatasettechnik rum. (wg Suchgeschwindigkeit, Transferrate und Ressourcenproblemen des Servers)
Dabei spielt natürlich die Anwenderzahl eine Rolle und auch die Hardware.

Durch filigrane Programmierung kann man eine Menge rausholen. Möglich ist vieles, ist aber die Frage wieviel Zeit und Geld man dafür in die Entwicklung steckt.

Eine WildcardSuche der gefragten Größenordnung nach 3 Anfangsbuchstaben mit sortiertem Ergebnis und eingeschränkter Ergebnismenge geht auf einem indizierten Feld unter 0,1 sek. Aber man kann nicht jedes Feld indizieren.

Ob ein gutes Framework in der Mittelschicht per se was bringt, wage ich zu bezweifeln. Die Mittelschicht ist bezogen auf den Server auch schlicht und ergreifend nur ein "Client" mit den gleichen Problemen eines klassischen Client-Server Clients.

[mjustin]

Zitat von jobo:

Eine WildcardSuche der gefragten Größenordnung nach 3 Anfangsbuchstaben mit sortiertem Ergebnis und eingeschränkter Ergebnismenge geht auf einem indizierten Feld unter 0,1 sek. Aber man kann nicht jedes Feld indizieren.

Ob ein gutes Framework in der Mittelschicht per se was bringt, wage ich zu bezweifeln. Die Mittelschicht ist bezogen auf den Server auch schlicht und ergreifend nur ein "Client" mit den gleichen Problemen eines klassischen Client-Server Clients.

Google Search ist ein gutes Beispiel. Da ist 'alles' (mehr oder weniger) indiziert, und es ist schnell. 0,1 Sekunden sind eine halbe Ewigkeit (Man bedenke mal, was eine Grafikkarte in der Zeit schafft). Google läuft auf billiger Hardware, ist aber sehr effizient programmiert.

Wenn es schnell gehen soll, wird der gesamte Datenbankinhalt ins RAM geladen (entweder auf einem einzigen oder mehreren verbundenen Rechnern - verteiltes Caching gibt es auch für Delphi), und komplett indiziert.

Die Mittelschicht (der Applikationsserver) kann viel effizienter als ein DBGrid + ClientDataSet sein, man muß sich nur eine effizientere Behandlung von Updates ausdenken. Wenn alles über den Cache geht, ist der Server immer auf dem aktuellen Stand, und braucht 'nie' auf die Datenbank zuzugreifen (sie wird in einem Backgroundprozess aktualisiert).

Warum sollte man nicht z.B. einem Client (Web oder grafisch) vom Server aus aktiv genau den Datensatz zusenden können, der neu aufgenommen wurde und einem gewählten Filter entspricht, statt den Client ein Close / Open / der gesamten Query machen zu lassen? Kompliziert ist es nicht, wenn man berücksicht, dass eine TCP/IP Verbindung immer zwei Richtungen auf einem Socket unterstützt - der Client kann also Nachrichten vom Server erhalten wenn er Lust hat, initiativ welche zu senden.

Das ist es auch, was Webseiten (Google Search) über Ajax erreichen: der Client macht keinen neuen Request auf das HTML Dokument (das dann erst wieder komplett auf dem Server zusammengebaut und an den Client geschaufelt werden müsste): es wird nur der Inhalt z.B. einer HTML Dropdownliste dynamisch um einen weiteren Eintrag ergänzt. Das geht in wenigen Mikrosekunden, auch mit Delphi. (Für eine Art "Chatsystem" auf TCP/IP Basis habe ich jetzt Raten von 30.000 Nachrichten pro Sekunde zwischen Client und Server - auf sehr einfacher Hardware - p.s. der Client ist in Delphi geschrieben, der Server ein Java Open Source Programm).

[jobo]

Im Prinzip stimmt alles was Du schreibst. Ich bin mir nur nicht so sicher, ob man das Entwicklerbudget und KnowHow von Google und Co hier einfach voraussetzen kann. Auch die Hardware dort ist für sich genommen meinetwegen billig, aber die Masse macht es dann eben. Außerdem wird bei google sicher nicht mit klassischen DB gearbeitet und sie haben mit den Alternativen Technologien auch nicht das Problem, dass sie bis ins letzte Bit ACID brauchen. Schnelle Suche ist DAS google Produkt, der Rest fällt priomäßig unter "ferner liefen".