Leistungsfähigkeit von Interbase?

[Seb]

Mit wie vielen Datensätzen kann Interbase6 in einem Table arbeiten, ohne dass man wartezeiten erhälte.<br>Es ist bestimmt sehr abhänig vom PC, aber den möchte ich vernachlässigen. Ich benutze zur Zeit Paradox un bin bei 100000 Datensäten erheblichen wartezeiten z.T. ausgesetzt. Ich entwickle eine Anwendung bei der Täglich 1000-5000 Datensätze angelegt werden. Ich habe schon zwei Tables erstellt und trenne dadurch Primäre und Sekundäre Daten. Damit ich schneller auf meine primären Daten zufgreifen kann.<br>
Ich greife über die IBX-Querry auf die Daten über den Primärschlüssel zu. Kann ich den Zugriff auf weiter Felder durch einen Index berschleuingen - Wie geht das? Z.B. wenn ich in einer Kunden DB alle Namen wissen will dies man mit select Upper(name) like "%MUSTER%" findet.

[Thomas Steinmaurer]

Prinzipiell ermöglichen Indizes den schnelleren Zugriff, allerdings müssen dann auch die Abfragen so formuliert werden, dass die Indizes auch tatsächlich verwendet werden. Ein Abfrage mit LIKE '%MUSTER%" wird nie einen Index verwenden. Ein LIKE 'MUSTER%" hingegen schon, da es intern von IB in ein STARTING WITH umgewandelt wird und hier sehr wohl der Index auf einer Spalte verwendet wird. Am besten wird es sein, wenn man solche "Suchfelder" redundant als Spalte in der Tabelle mitspeichert und z.B. mittels Trigger wartet (Umwandlung im Trigger in Grossbuchstaben beim Insert/Update) und auf diese Spalte einen aufsteigenden u. absteigenden Index definiert. Ich würde Dir empfehlen ein Tool (IBExpert, EMS QuickDesk, ...) zu verwenden, um zu sehen, ob bei Deiner Abfrage auch tatsächlich die Indizes verwendet werden.
<br><br>
Thoma

[Bernd Havla]

Hallo Seb,
der Interbase ist meiner Erfahrung nach scho a bisserl leistungsfähiger als Paradox.
Aber: Je größer die zu lesende Datenmenge (sowohl vertikal als horizontal) desto länger dauerts halt. Um das möglichst zu vermeiden, sollte man auf jeden Fall Indizes verwenden:

create index MeinIndex
on Tabellenname (Tabellenfeld(er));

Es ist auch denkbar die Indizes im Falle deines Problems Namensuche zu splitten ein Index bis 'L%' der andere ab 'M%'.
Hälfte der Datenmenge.
Doch Vorsicht! Indextabellen müssen natürlich auch gepflegt werden, und das kostet Zeit beim Insert und Update, also nur die wirklich notwendigen anlegen!!!

cu mi

[Seb]

Muß ich bei der Select-Anweisung irgendwie auf den Index verweisen, oder geschicht das automatisch.<br> <br>
Gibt es noch weiterer Möglichkeiten um einen großes Datenvolumen optimieren?<br>1.Index<br>2.Aufsplitten "breiter" Tabellen in einzeln

[Torsten Grundke]

Hallo Seb,

wenn Du Dein Select-Statement in eine StoredProc "verpackst" beschleunigt sich die ganze Sache noch einmal deutlich.

Indizes müssen nicht explizit zugewiesen werden. Der interne Optimizer sucht automatisch die "passenden" Indizes aus. Bei sehr komplexen Select's kann es allerdings vorkommen das der interne Optimizer kein optimales Ergebnis liefert, d.h. das nicht alle Indizes verwendet werden, die sinnvoller Weise verwendet werden sollten. Das betrifft im Normalfall aber nur sehr komplexe Select's.

Mit der Anweisung <b>PLAN</b> besteht die Möglichkeit selber vorzugeben, welche Indizes verwendet werden soll. Bei der manuellen Vorgabe sollte man auf jeden Fall wissen was man tut, sonst wird aus dem erhofften Performancegewinn ein Bremsklotz allererster Güte.

Tschüß

Torste

[Gesine Kuhlmann]

Hi,

1)
Im Gegensatz zu Desktop-Datenbanken ist bei SQL-Datenbanken die Geschwindigkeit der Arbeitsstation für die Ausführung deiner Datenbankoperationen zweitrangig. Der SQL-Server bestimmt mit seiner Hardwareausstattung die Performance.

2)
100.000 Datensätze sind für einen SQL-Server eine lächerlich kleine Datenmenge ( Man muss sich keinesfalls Gedanken über die 'Aufsplittung' von Indizes machen ).
<b>Entscheidend für die Performance deiner Anwendung ist immer die Datenmenge, die wirklich angefordert wird</b>. D.h. ruft deine Anwendung alle 100.000 Datensätze ab, dann musst du mit erheblichen Wartezeiten rechnen. Es gilt: Je größer die zu bearbeitende Datenmenge, desto eher sollte die Verarbeitung serveseitig stattfinden ( über Stored Procedures oder entsprechende SQL-Anweisungen ). Deine Anwendung sollte immer nur die Datenmenge anfordern, die auch tatsächlich benötigt wird ( Select * from XYZ <b>where Bedingung</b> ). Verfügt deine Tabelle auch über viele Felder, so sollte man statt Select * die benötigten Felder ebenfalls definieren ( z.B. Select <b>ID, NAME, BETRAG</b> from XYZ where Bedingung ). Ist eine Datenbank vernünftig normalisiert, dann dürfte es aber kaum Probleme mit der Feldanzahl geben.

Gruß
Gesin

[Christoph Stadler]

Hi Seb,

gehe mal auf die Seite www.interbase2000.org/ib_doc.htm ,
dann auf "Technical Info" und lädst Dir das PDF "Ten Thinks you can Do to make InterBase Scream" herunter. Das ist eine sehr gute Anleitung und Erklärung, um InterBase schneller zu machen und "RICHTIG" einzustellen.

Christop