Zitat von
sancho1980:
...so dass der User meiner Anwengung die Datenbank selbst konfigurieren kann?
Was heißt konfigurieren ? Du willst doch wohl hoffentlich den Enduser nicht an der
DB-Struktur rumfummeln lassen ?
Soll der User etwa Tabellen usw. anlegen können ? Wie soll denn das Programm auf nicht mal bekannte Daten überhaupt reagieren ? Oder ist nur der Speicherort gemeint ? Den lege ich im Datamodul-Create fest und fertig. TDatabase gehört also in das Teil rein. Funktioniert einwandfrei. Zu Testzwecken habe ich immer so ca. 10 verschiedene DBs mit Originaldaten zur Hand. Den Speicherort lese ich dabei aus einer INI-Datei aus. Ich brauche also das Programm nicht mal neu zu compilieren. Bei Bedarf wird die INI also lediglich geändert. Ich mache das einfach von Hand und bei Erstinstallation kann der User selber den Ort der
DB festlegen. Der wird dann in die INI geschrieben und das wars.
Zur Frage an sich : wer viel frägt, der kriegt auch viele Antworten. Lasse Dich nicht verrückt machen. Es wird immer einen geben, der was madig macht. Und es gibt im
DB-Bereich auch viele, die eine Datenbank nur deshalb verwenden, weil sie irgendwann mal tatsächlich ein funktionierendes Programm damit hingekriegt haben. War das M$-
SQL, tja dann ists doch schön.
Fest steht aber folgendes : unter
IB/
FB hast Du 6 Trigger, Stored Procedures, UDF, Views, Transaktionen usw. MGA hat nur Interbase und das ist gerade im Netzwerk nicht unwichtig. All das ist allerdings keine Selbstverständlichkeit ! Bei
FB gibts dann noch eine embedded Version. Für Demo-Zwecke (z.B. CD) einfach genial. Was will man mehr ? Bei wirklich gigantischen Datenmengen muß man wohl etwas Feinschliff anlegen. Und so was ist auch eher
DB-unabhängig.
Ach ja, das LIKE. Wo und wann braucht man denn das ? Ich benutze es z.B. zum Suchen nach Kunden-Adressen. Nun gilt aber auch folgendes : ein DAU wird vergessen den ersten Buchstaben des Suchwortes einzugeben. Er wird einen Namen kaum korrekt bis zum Ende ausschreiben können. Er wird CAPS-Lock endlich dann ausschalten, wenn der einzugebende Suchbegriff komisch aussieht, aber die mitten im Suchwort stehenden Großbuchstaben nicht nachträglich korrigieren. Mit Eingabe von mehr als 5 Buchstaben ist er grundsätzlich überfordert.
Folge : die Suche sieht so aus :
'SELECT * FROM KUNDE WHERE UPPER (NAME) LIKE UPPER (''%' + edSuch.Text + '%'') ORDER BY NR';
Einige Meckerer werden direkt den * sehen. Es steht 2mal UPPER drin und das % gleich am Anfang und am Ende. Als Anzeige hätte ja auch Anrede, Name usw. gereicht, richtig. Aber obwohl die Datensätze recht fett sind, haben Tests keine merkbaren Verbesserungen gebracht. Da die anderen Felder im Falle einer Fundstelle aber sowieso benötigt werden, spare ich mir den Code um die dann in der Datenmange fehlenden Daten nachzuladen. Sofern die weiter-Taste gedrückt bleibt, kann man nicht mal die gefundenen Adressen lesen, so schnell geht das.
IMHO gibt es Einbußen eigentlich nur bei schlechter Programmlogik. Hatte mal versuchsweise das DS-Afterscroll getestet.
Oh je. 8) Tja, war eben ungeeignete Stelle und dann mußte das eben anders gemacht werden.