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.