Interbase-Beschränkungen

[sancho1980]

Hallo!
Ich habe eine Frage: Ich arbeite momentan an einer mittelgroßen Client-Applikation für ein Terminologiedatenbankverwaltungssystem und habe persönlich noch keine weiteren Erfahrungen mit Datenbankprogrammierung, außer dem, was ich mir in den letzten zwei Monaten so angeeignet habe. Ich habe mich mittlerweile für Interbase entscheiden, um aber auf Nummer sicher zu gehen, wollt ich euch fragen, ob ihr mir sagen könnt, ob es irgendwelche fiesen Beschränkungen gibt, die mich im Nachhinein dazu bringen könnten, meine Entscheidung für Interbase zu bereuen (also z.B. maximale Anzahl an Records in der Datenbank, maximaler Gesamt-Speicherplatz der Datenbank, etc.)
Vielen Dank und Gruß,
Martin

[mschaefer]

Moin, moin,

also von der Seite Speicherplatz und Anzahl hast Du mit keinen relevanten Beschränkungen zu rechnen. Was ich als Hürde sehe ist die Einarbeitung in das Generator - Trigger - System, um mit Datensätzen zu hantieren. Das braucht einfach etwas Zeit und Recherche in der DP. Interbase / Firebird ist sehr Flexibel im Befehlssatz und der Erweiterung mit UDF+Stored-Procedures. Letzlich hast Du damit ein sehr vielfältig nutzbares System, wenn man weiss was man tut.

Ein Problem könnte in der Geschwindigkeit bei komplexen Suchen aufkommen. Meine Beobachtung an einem selbstentwickelten Auftragbearbeitungssystem ist, dass Firebird ab etwa 5000 Datensätezn doch deutlich langsamer wird, wenn man mit Like-Statements arbeitet. Auch Indexe bringen hier nur begrentzt eine Lösung. Da hilft nur ein schneller- Server und der gezielte Einsatz von hochselektiven SQL-Statments um nicht unnötig Müll über das Netz zu schicken.

Grüße aus der Stadt an der Leine // M;artin

[sancho1980]

Danke, gut zu wissen.
Das Ding ist nämlich, dass die Applikation eine Weiterentwicklung einer mit der BDE gemachten Anwendung sein soll und dass die alten Datensätze in das neue Format gebracht werden müssen und da gibt es schon mal so eine halbe Million Einträge, und damit sollte der Server dann bitte hoffentlich echt kein Problem haben.
Grüße aus der fast Olympiastadt Leipzig :party:

[mkinzler]

Zitat:

Zitat von mschaefer

Meine Beobachtung ... ist, dass Firebird ab etwa 5000 Datensätezn doch deutlich langsamer wird, wenn man mit Like-Statements arbeitet. Auch Indexe bringen hier nur begrentzt eine Lösung.

Like-Statements sollte man wenn möglich vermeiden, da für sie keine Indizes verwendet werden können. Sie führen (nicht nur bei FireBird) zu deutlichen Geschwindigkeitseinbußen.

Zitat:

Zitat von sancho1980

da gibt es schon mal so eine halbe Million Einträge, und damit sollte der Server dann bitte hoffentlich echt kein Problem haben.

Die reine Anzahl an datensätze sind nicht das Problem, sondern eher die Anzahl von Änderungen an den Datensätzen und die Struktur der Abfragen ( können Indizes verwendet werden).

[Elvis]

Auch wenn ich früher absolut kein Freund des SqlServers von M$ war...
Der neue Sql2005 ist einfach ein Biest, bei dem MS fast alle Nachteile gegenüber Oracle aufgeholt hat und IMHO aktuell so ziemlich das beste DBMS auf dem Markt haben.
Die Frage ist also eher welche Gründe _gegen_ SQL2005 sprechen. ;)
Klingt wie eine Verkaufsansprache, aber wenn man sich mal genau mit der neuen auseinandersetzt kann man erahnen warum es 5 Jahre seit der letzten Verion gedauert hat...

Zitat:

Interbase / Firebird ist sehr Flexibel im Befehlssatz und der Erweiterung mit UDF+Stored-Procedures. Letzlich hast Du damit ein sehr vielfältig nutzbares System, wenn man weiss was man tut.

Kunststück :roll: UDF aka XProcs sind doch Standard und ein Fehlen dieser Möglichkeit kann sich kein größeres DBMS erlauben.
Wenn es um die interne Scriptsprache von IB/FB geht... Ich weiß nicht wie man bei den 20+ Befehlen in PSQL auf "flexibel" kommen kann.
FB finde ich als embedded sehr nett, aber als richtiges Arbeitstier würde ich ihn nicht einsetzen wollen. IB stufe ich da sogar noch unter FB ein...

Zitat:

Like-Statements sollte man wenn möglich vermeiden, da für sie keine Indizes verwendet werden können. Sie führen (nicht nur bei FireBird) zu deutlichen Geschwindigkeitseinbußen.

Jain...
Wenn das Pattern nicht mit Wildcards beginnt können die "großen" DBMSe immernoch indiziert zugreifen. Wobei es natürlich immernoch lahmer als ein normaler Hash join auf ein indiziertes Feld ist. ;)

[dmagin]

Zitat:

Zitat von mkinzler

Zitat:

Zitat von mschaefer

Meine Beobachtung ... ist, dass Firebird ab etwa 5000 Datensätezn doch deutlich langsamer wird, wenn man mit Like-Statements arbeitet. Auch Indexe bringen hier nur begrentzt eine Lösung.

Like-Statements sollte man wenn möglich vermeiden, da für sie keine Indizes verwendet werden können. Sie führen (nicht nur bei FireBird) zu deutlichen Geschwindigkeitseinbußen.

Zitat:

Zitat von sancho1980

da gibt es schon mal so eine halbe Million Einträge, und damit sollte der Server dann bitte hoffentlich echt kein Problem haben.

Die reine Anzahl an datensätze sind nicht das Problem, sondern eher die Anzahl von Änderungen an den Datensätzen und die Struktur der Abfragen ( können Indizes verwendet werden).

halb falsch hablb richtig:

like operationen laufen nur dann nicht über einen index wenn:

1. das feld kein index hat
2. wenn der like suchstring mit einem % beginnt

also wenn das feld nachname ein index hat wird die operation ... nachname like 'Mag%' voll der index angezogen

auch ist der operator UPPER tödlich für den index weil diese in vielen db's case sensitiv sind. also am besten ein feld machen was per trigger das feld nachname in up_nachname automatisch upper einfügt. dann auf diesem suchen

gruss daniel (m)


ps: ich habe db's mit interbase mit mehr als 2,3 Mio Datensätze in einer Table. die tel-nummer identifikation ist in 120ms erledigt

:-)

[sancho1980]

ich bin überfordert :roll:

[mkinzler]

Zitat:

Zitat von dmagin

2. wenn der like suchstring mit einem % beginnt

ich ging von "echten" LIKE-Abfragen aus (Volltextsuche). Aber auch LIKE-Abfragen zu Teilstringsuche sind aus meiner Beobachtung langsamer als bei "Exakt"-Suche.

Zitat:

Zitat von dmagin

auch ist der operator UPPER tödlich für den index

.Diese Beschränkung fällt mit Einführung des FB2.0 (im Moment beta). dann kann man sogenannte Expression-Indizes anlegen, d.h. berechnete Indizes z.B.

SQL-Code:

create index <index_name> on <tabellen_tame> computed by(UPPER(<feld_name>));

Zitat:

Zitat von Elvis

Die Frage ist also eher welche Gründe _gegen_ SQL2005 sprechen. Wink

Es kommt immer auf die Art der Anwendung7Anspruch an den DB-Server an.
-Der SQL-Server belegt mehr Speicher (Platte/Hauptspeicher) als zm IB/FB, Mysql Sqlite usw.
-Er muß installiert werde und diese ist aufwendiger.
-Die express Version besitzt gewisse Beschränkungen.
-Die "großen" Versionen haben ihren Preis.

Aber auch IB/FB haben natürlich Beschränkungen. z.B. FB unter Windows entweder nicht MP-fähig(SuperServer) oder extrem inperformant(Classic-Server) (Mit Vulcan sollen die beiden Versioenn verschmolzen werden), embedded fb kann nur eine Verbindung handeln. Gc von FB stößt bei schnellen Änderungen schnell an ihre Grenzen. (Problem teilweise mit FB 2.0 behoben).

[sancho1980]

naja angesichts der Tatsache, dass ich mich in Interbase nun schon ein bisschen eingearbeitet habe, und es meinen Anforderungen zu genügen scheint, werd ich wohl dabei bleiben.
Mal eine Frage am Rande: Ihr kennt doch sicherlich den Database-Editor der TIBDataBase-Komponente. Wisst ihr zufällig ob und wie ich den auch zur Laufzeit erzeugen kann, so dass der User meiner Anwengung die Datenbank selbst konfigurieren kann?
Danke und Gruß,
Martin

[Hansa]

Zitat:

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 ? :shock: 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. :lol: 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. :mrgreen: Folge : die Suche sieht so aus :

Delphi-Quellcode:

'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.