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.

[mschaefer]

Ja Hansas´s leichte Ironie im Kommentar gibt der Sache immer etwas Würze. Aber letzlich kann ich die Verfahrensweise bei der allgemeinen Suche bestätigen. Sich nicht um alle Feinheiten zu kümmern wird von den Anwendern als Anwenderfreundlich empfunden.

Ist es ja auch, wie bei Goggle tippen und die Lösungvorschläge kommen. Ausser man sucht nach bestimmten Kriterien, wie Rechnungsnummer oder Kundennumme, aber dass kann man durch Kennzeichen am Anfang des Suchwortes oder durch Einstellungsdialoge verfeinern.

Letzlich ist unsere Aufgabe den Anwendern das möglichst Komfortabel zu machen und wenn dabei herauskommt, das man in einen etwas schnelleren Server investieren sollte, dann ist das im Verhältnis zum Stundenlohn meist kein wirkliches Problem. Über den Wert von Software kann man natürlich lange Diskutieren, aber die Entwicklungskosten sind nun mal eine Größe.

Grüße // Martin

[sancho1980]

Nein nein, mit konfigurieren meinte ich natürlich bloß, dass mein Anwender selbst die Datenbank aussucht, mit der er sich verbindet. Und bevor ich da jetzt sebst einen Dialog erstelle, dachte ich mir, wär's doch praktisch, er würde irgendwie den gleichen Database-Editor zu Gesicht bekommen, den ich zur Design-Zeit einstellen kann (wer nicht weiß was ich meine: einfach mal ne TIBDatabase-Komponente auf das Formular ziehen und mit der rechten Maustaste über die Komponente klicken; da gibt's dann im Pop-Up ein Feld "Database Editor" - genau das will ich, dass der User es sieht)
Grüße,
Martin

[Lemmy]

Zitat:

Zitat von Elvis

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

Ähem... UDF sind KEIN StoredProcedures, sondern eben UDF (User defined functions), die in einer "richtigen" Programmiersprache geschrieben werden und per DLL der Datenbank bekannt gegeben werden. Aber das für dich nur als weiteres Hintergrundwissen, denn auch da bietet M$ mehr, denn dort werden StoredProcedures per .NET implementiert und bieten so das entsprechende Feature wesentlich einfacher an...

Grüße
Lemmy

[Hansa]

Zitat:

Zitat von sancho1980

.. dass der User es sieht)

Kann er es nur sehen, so ist es lediglich überflüssig. Ausnahmefall : mehrere Datenbanken mit verschiedenen Daten. Schlimmstenfalls wirst Du lediglich genervt, ob Du "dieses komische Ding" :lol: nicht wegmachen kannst, weil es nur hindert und keinen interessiert. KANN ein DAU aber etwas verändern, z.B. den Zeichensatz, dann WIRD er es irgendwann auch ändern ! Wenn Du mir nicht glaubst dann frage mal Murphy. :mrgreen: Und zu guter letzt kriegst Du noch selber eine auf den Deckel, weil es "eben Ihr Fehler" war, so etwas überhaupt zuzulassen ! 8)

[Elvis]

Zitat:

Zitat von Lemmy

Ähem... UDF sind KEIN StoredProcedures

Das ist mir durchaus klar. ;)
UDF aka XProcs sind funktionen aus nativen DLLs, managed SProcs sind wieder eine komplett andere Geschichte.
XProcs sind genauso ein Vorteil von IB/FB wie es gummierte Reifen für VW/Audi sind. Nämlich keiner, haben alle anderen auch. ;)

[Lemmy]

Ahhh.. ich dachte das X von XProcs stand für StoredProcedures.... Mein Einwurf muss dann nicht mehr beachtet werden ;-)

Grüße
Lemmy

[sancho1980]

Gut, dann lassen wir das mit dem Database-Editor. Noch eine andere Frage: Die Original-Datenbank nutzt bislang den WIN1252-Zeichensatz. Um aber das Terminologie-Programm für so viele wie mögliche Sprachen flexibel zu machen, spiele ich mit dem Gedanken, das Ganze auf UNICODE_FSS umzuändern. Jetzt stellt sich mir nur folgendes Problem: die Sortierung. Angenommen ich will nachher mal mein Wörterbuch ausdrucken, kann ich unmöglich immer die gleiche Sortierreihenfolge verwenden, denn die ist von Sprache zu Sprache unterschiedlich (beispielsweise kommt 'll' im spanischen Alphabet nache 'l' und 'ñ' nach 'n'). Daher meine Frage: Gibt es einer Möglichkeit, wie ich mir eine eigene Sortierreihenfolge erstelle?
Nochmals danke,
Martin

[mschaefer]

Martin, mach für die Frage mal einen eigenen Thread auf,
denn beim Stichwort Unicode werden auch noch andere hellhörig.
Das ist auch so ein Thema, wo man mal die DBMS vergleichen kann;
von Firebird / Fyracel zu Oracle ist es ja auch nicht mehr so weit.

Grüße // Martin

[sancho1980]

Gesagt, getan ;)