Hi,

ich habe hier eine DB, die ich aus einer Textdatei heraus erzeugt habe. Diese nahm ich jetzt einmal genauer unter die Lupe und stellte fest, daß keinerlei Index vorhanden ist. Ist das normal ?

Gruß
Hansa

Hi Hansa,

IB legt Indizes nicht automatisch an (Außnahme PrimaryKey). Alle anderen musst Du selbst erstellen.

Lemmy

P.S.: Hast DU dich weiter mit den FIBPlus beschäftigt? Ich hatte immer noch keine Zeit weiterzumachen....

Hi
auch den Primary Key legt IB nur an, wenn er in der Tabelle vereinbart wurde. Allerdings gibt es bei IB keinen Zwang das zu tun.

Gruss Lothar

Hi Lemmy,

Zitat:

P.S.: Hast DU dich weiter mit den FIBPlus beschäftigt? Ich hatte immer noch keine Zeit weiterzumachen....

Ja. Verwende die im Moment. Geht eigentlich ganz gut. Die Frage hier stammt eigentlich sogar aus diesem Zusammenhang. Sie kommen mir sehr schnell vor. Wegen mangelnder Erfahrungswerte teile ich sie mal hier mit : Das Neueintragen von 885 Datensätzen in die DB dauert 17 sek., also 19 ms pro DS. Dies geschieht durch zeilenweises lesen aus einer Textdatei. In der Textform hat ein DS als string 615 Byte. Die zehacke ich dann und füge Feld für Feld (ca. 70) mit dem richtigen Typ in die DB ein. Uff, da bin ich immer noch am ändern.

Vielleicht ist das ja auch langsam. ICH weiß es nicht. Rechner ist ein 900er AMD mit IBM 7200 60GB Festplatte. Als DB-Komponenten habe ich FIBdatabase, FIBtransaction, TdataSource und FIBdataset. Lese hier die ganze Zeit von IBtable, Queries usw. Hab ich bisher noch gar nicht gebraucht. Ja und dann halt die Indices. Habe keine ! Lothar hat recht, automatisch legt IB (bei mir Firebird) keine an. Mein Programm läuft trotzdem. Um einen Datensatz auszuwählen will ich die nr und die Bezeichnung verwenden, deshalb bietet das sich doch für einen Index an, oder ?

Gruß
Hansa

P.S.: Lemmy, herzlichen Glückwunsch noch !

Hi,

Dass die FIBPlus schneller als andere sind steht ja auch auf der HP. Hast Du die Vergleichsproggy mal angeschaut? Beim Vergleich IBX-FIBPlus sind mir die Augen rausgefallen!

Zum Thema IBTable,... Zu was brauchst Du die? Da genügt immer noch die DataSet. Für IBTable gibt es sowieso keinen vernünftigen Einsatzzweck bei einer SQL-DB.

Zum Thema PK: Klar legt IB/FB nicht automatisch einen PrimaryKey an, aber für jeden PrimaryKey wird automatisch ein Index angelegt. Es macht auch Sinn auf PK's zu verzichten, man muss dann halt die benötigten Indizes selbst erstellen....

Grüße
Lemmy

P.S.: Vielen Dank!

Hi Lemmy,

Zitat:

Beim Vergleich IBX-FIBPlus sind mir die Augen rausgefallen!

Meinst Du in etwa so ? Nur in welche Richtung und wer hat verglichen ? Ein Vergleich wäre wirklich interessant (Kann Dir ja mal die Daten und mein Programm rüberjagen). Aber vorerst nicht, probier Du das mal selber. Die Performance kommt zum Schluß dran. Zuerst müssen die logischen Probleme mal dran glauben. Aber die Jungs von FIBplus geben sich auch Mühe. Habe mal so ca. 2 Fragen in die Newsgroup gestellt, Antwort kam am selben Tag. Hab sie sogar verstanden. Außerdem wollen sie von mir nur 150$.

Zitat:

Zum Thema IBTable,... Zu was brauchst Du die?

Genau das frage ich ja. Jeder verwendet sowas, aber wozu ?

Zitat:

aber für jeden PrimaryKey wird automatisch ein Index angelegt.

Nee In meiner DB eben nicht, IB-DB ohne einen einzigen Index, wo gibts sowas ? Datensätze stehen allerdings drin in der Reihenfolge, in der sie eingefügt wurden. Also scheint doch irgendwo ein Index zu sein, nur wo ?

Meine 885 Datensätze sind anscheinend zu wenig, um irgendetwas herauszufinden.

Zitat:

. Es macht auch Sinn auf PK's zu verzichten, man muss dann halt die benötigten Indizes selbst erstellen....

Das ist mir im Moment zu hoch. häh ?

Gruß
Hansa

Hi

hansa hat folgendes geschrieben:

Nee In meiner DB eben nicht, IB-DB ohne einen einzigen Index, wo gibts sowas ? Datensätze stehen allerdings drin in der Reihenfolge, in der sie eingefügt wurden. Also scheint doch irgendwo ein Index zu sein, nur wo ?

Wenn du keinen Index für die Tabelle vereinbart hast, dann ist da auch keiner. Und das heisst du kriegst die Datensätze in der Reihenfolge, in der sie angelegt wurden. Oder in der Reihenfolge der Order by Klausel.

Ein Primary Key ist bei IB nicht zwingend notwendig. Allerdings ist es in den meisten Fällen besser einen zu haben. Aber auch den musst du eben selber vereinbaren.

Gruss Lothar

Hi Hansa,

hansa hat folgendes geschrieben:

Hi Lemmy, Meinst Du in etwa so ? Nur in welche Richtung und wer hat verglichen ? Ein Vergleich wäre wirklich interessant (Kann Dir ja

Das steht auf der FIBPlus-Homepage:
Application for comparing FIBPlus with others db- engines (IBX, ZeosDB, IBObjects. exe and sources). Hier der link: www.devrace.com/file...ibplus_vs_others.zip (872 kB)

Und da hat IBX <> FIBPlus ganz schön Federn lassen müssen...

hansa hat folgendes geschrieben:

sogar verstanden. Außerdem wollen sie von mir nur 150$.

Hast Du die Teile schon gekauft??

hansa hat folgendes geschrieben:

Genau das frage ich ja. Jeder verwendet sowas, aber wozu ?

Wenn ich jetzt schreibe, dass das Warmduscher und MitHandschuSkifahrer sind werde ich bestimmt aus dem Forum gejagt deshalb schreibe ich das auch nicht. Die TTable-Komponente mit all Ihren Nachfahren sind schlicht einfach und schnell zu kapieren. Für einfache Sachen geht das auch noch, aber wenn man irgendwo eingreifen will, geht das halt nicht. Viele fangen mit TTable an, ist auch nicht falsch. Nur sollte man keine DB-Anwendung für mehrere Clients (und auch wenn es nur 2 sind) mit TTables machen, das bringts irgendwann einfach nicht mehr....

hansa hat folgendes geschrieben:

Nee In meiner DB eben nicht, IB-DB ohne einen einzigen Index, wo gibts sowas ? Datensätze stehen allerdings drin in der Reihenfolge, in der sie eingefügt wurden. Also scheint doch irgendwo ein Index zu sein, nur wo ?

Was ?? Unter den "Indexes" steth in der IBConsole nichts was mit RDB$PRIMARY anfängt?? Und Du hast ganz gewiss Primary-Keys definiert?? Unglaublich.. Kannst Du mir mal das Skript mehlen..??

hansa hat folgendes geschrieben:

Zitat: . Es macht auch Sinn auf PK's zu verzichten, man muss dann halt die benötigten Indizes selbst erstellen.... Das ist mir im Moment zu hoch. häh ?

Allo: Bei der Definition der Primary-Keys (und das ist bei IB anscheinend auch der einzige Zweck) werden automatisch von System für jeden PK ein Index angelegt. Diese erhalten dann so nichtsaussagende Namen wie RDB$PRIMARY1. Wenn nun bei einer Fehlermeldung (z.B. doppelte Belegung eines PK) die Fehlermeldung mit dieser Bezeichnung kommt, dann muss man erst mal suchen, welcher PK das ist (weiß man auch normalerweise). Wenn man aber jetzt auf die PK's verzichtet und den Index von Hand anlegt, dann kann man dem nen Namen geben - Klar?? Das ist auch nicht auf meinem Mist gewachsen, sonder das hat ein IB-Guru geschrieben und auf nen Borland-Treffen auch vorgetragen. Ich such mal eben den Ausdruck....

So, hier gibts den Artikel auch zum Nachlesen: community.borland.co...0,1410,27569,00.html.

Hoffe geholfen zu haben....

Lemmy

Hi Lemmy,

Zitat:

Hast Du die Teile schon gekauft??

Traue mich noch nicht. Habe schon genug Bücher gekauft. Da geht es ja noch, wenn einem von 500 Seiten nur 50 helfen. Bei 10 Büchern wären das dann auch zusammen 500 Seiten. Aber es macht wohl keinen Sinn IBX, FIBplus, IBobjects usw. gemischt einzusetzen und an jeder Ecke so 150 $ zu bezahlen.

Aber es sieht zumindest für mich immer mehr so aus:
IBX : scheintot, fang ich erst gar nicht an. IBobjects : auf Anhieb konnte ich ohne größeren Aufwand nix mit anfangen, sind irgendwie seltsam. FIBplus : Tja, sind auch nicht sooo verbreitet, aber auf Anhieb gelang mir fast alles, damit geht es eher andersrum wie sonst. Da funktioniert etwas und ich weiß gar nicht wieso überhaupt. Wenn das so weiter geht, muß ich die Dinger sowieso kaufen. Und wenn sie auch noch so schnell sind.....Aber dieses Jahr werde ich mit meinem Projekt sowieso nicht fertig.

Gruß
Hansa

Also da muss ich jetzt aber schon noch mal eingreifen

Hansa hat folgendes geschrieben:

IBX : scheintot, fang ich erst gar nicht an.

Vielleicht ist genau das dein Problem Klar ist, dass die IBX Kompos einige Schwachstellen und Bugs haben. Allerdings ist davon keiner so gravierend dass man ihn nicht irgendwie ohne grossen Aufwand umgehen könnte.
Den Geschwindigkeitsunterschied zwischen IBX und FIB kann ich nicht beurteilen, aber auch wenn sie schneller sind ergibt sich die Performance immer erst aus dem Zusammenspiel mit deinem Programm.
Ich hab jetzt mehrere Projekte mit der Kombination IBX und IB6 durchgezogen. Darunter auch Baumärkte und Fahrzeugbauer bei denen auch der klitzekleinste Vorgang erfasst und bearbeitet wird. Resultat: Schnell, stabil und seit Jahren nicht das kleinste Problem.

Gruss Lothar

Hi,

Zitat:

Den Geschwindigkeitsunterschied zwischen IBX und FIB kann ich nicht beurteilen, aber auch wenn sie schneller sind ergibt sich die Performance immer erst aus dem Zusammenspiel mit deinem Programm

Was ist schon schnell ? Wenn ich z.B. eine Lookupbox jedesmal mit Daten fülle, sobald ich in das Feld komme, anstatt sie einmal zu bestücken beim öffnen der Form, dann braucht sich niemand zu wundern, das sein Programm langsam wird, z.B. wenn auf der Form 10 große Listboxen sind. Weiß schon was Du meinst. Der Witz ist aber der, daß ich es selber so mache. Natürlich aus Versehen. Ein Bekannter hat das im Quelltext bemerkt. Beim testen des Programms fiel mir das jedenfalls nicht auf.

Aus meiner Sicht ist das wichtigste, wie schnell und wie logisch etwas am Besten eingesetzt werden kann. Das schlimmste ist sowieso, die Indices falsch oder gar nicht einzusetzen. Deshalb frage ich ja hier, da ich nicht genau weiß, wie ich das am besten machen soll.

Habe jetzt gerade gesehen, daß ich gar keinen Primary Key einsetze. Das fiel mir auf, als ich einen unique Index auf die ID setzte. Da hatte ich nämlich den Effekt, bei mehrfacher Übernahme alter Daten ein und dieselben Datensätze mehrfach zu haben. Also langer Rede kurzer Sinn : kann mir mal jemand kurz erklären wie das in Interbase gehandhabt wird, wo soll der Primary Key hin und wann und wofür einen Index benutzen ? In der Theorie (Bücher und so) gehen die immer zu knapp darauf ein oder setzen zu vieles auf einmal voraus.

Gruß
Hansa

Hi
Einen Primary Key solltest du immer da einsetzen wo die Forderung nach einem eindeutigen Wert innerhalb einer Spalte, oder einer Kombination aus mehreren Spalten besteht, und wo dieser eindeutige Wert zum Zugriff auf die Daten verwendet wird. Eine ID-Nummer für einen Kunden oder Artikel wäre also genau so ein Fall.

Weitere Indexes kannst du erzeugen
wenn du häufig innerhalb von Suchkriterien auf eine Spalte zugreifst
wenn du häufig mittels JOIN eine Spalte referenzierst
wenn du häufig mit ORDER BY nach einer Spalte sortierst.

Die Betonung liegt hier auf häufig. Wenn du das nur ab und zu mal für ne Liste oder Auswertung benötigst, ist der Verwaltungsaufwand für einen Index nicht gerechtfertigt.

Du solltest keinen Index erzeugen
wenn in der Indexspalte nur eine geringe Anzahl an unterschiedlichen Werten auftritt
wenn die Daten häufig aktualisiert werden.

Ansonsten kannst du einfach deinen gesunden Menschenverstand walten lassen. Generell gilt aber: weniger ist manchmal mehr.

Gruss Lothar

Hi Lothar,

auf Dich ist wenigstens noch Verlass. Du hast ungefähr das geschrieben, was ich überlege. Ich muß im Moment noch umdenken, da IB ja mengenorientiert arbeitet. Das muß man immer im Hinterkopf haben, oder ?

Habe jetzt folgenden Fall, wo ich nicht weiß wie ich den behandeln soll, also jetzt in diesem Zusammenhang. Es soll über einen Namen gesucht werden. Und zwar über einen beliebigen Bestandteil. Natürlich kommen viele, falls man nach "e" sucht. Außerdem nützt mir eine alphabetische Suche hier dann sowieso nicht, da der Namensbestandteil ja irgendwo in dem Namen stehen darf und nicht nur vorne.

Um aber doch irgendeine Ordnung dort rein zu bringen, hab ichs so gemacht : Index fängt an mit der Nr, der Name hängt da dran (z.B. 1000Karl Meier). Jetzt laufe ich über diesen Index, halt um nicht die ganzen Datensätze zu lesen, sondern erst dann, wenn das Suchkriterium erfüllt wird. Bei mehreren kommen die Namen dann in der Reihenfolge der Kundennummern.

Nun, wie gesagt, ich glaube bei SQL muß ich an sowas anders rangehen. Ich habe da doch keine so waschechte Indexdatei, oder doch ?

Gruß
Hansa

Danke, Danke

Auf einen Index in der Art würde ich lieber verzichten und hier an dieser Stelle nur die Nummer indizieren.
Zum Suchen im Namen bringt der Index nicht, weil den IB nur verwenden würde, wenn der Name die erste Spalte wäre. Und wenn du mit LIKE suchst schon gar nicht.
Beim Suchen in der Kundennummer würde es was bringen, aber dann schleppst du den Namen eigentlich umsonst mit rum. Der einzige Vorteil wäre also eventuell der Vorteil der Sortierung nach Nummer wenn mehrere gleiche Namen (Namensteile) da sind. Das würde in dem Fall aber mit Order by genauso schnell gehen.
Wenn das ein Primary Key ist, bringt die Kombination noch mehr Nachteile, weil du die Eindeutigkeit einer Nummer nur in Verbindung mit dem Namen hast. Es wäre also möglich einen Namen mit verschiedenen Nummern in der Tabelle zu haben.
Ich würde hier die Nummer als PK verwenden und einen zweiten Index auf den Namen alleine anlegen um die Sortierung darauf zu beschleunigen.

Gruss Lothar

Hi,

Zitat:

Der einzige Vorteil wäre also eventuell der Vorteil der Sortierung nach Nummer wenn mehrere gleiche Namen (Namensteile) da sind. Das würde in dem Fall aber mit Order by genauso schnell gehen.

Ich glaube, das ist genau das, was ich anscheinend noch nicht kapiert habe. Bin davon ausgegangen, daß im Zusammenhang mit ORDER BY zumindest sinnvollerweise ein Index benutzt werden sollte. Zweifle aber langsam daran, daß es so ist.

Wegen solcher Geschichten habe ich ja erst mal versucht, eine vernünftige Datenbasis zusammen zu bauen, damit ich das alles testen kann. Wenn ich aber eine Table von so 100MB haben will, dann muß ich die Rechnungs-Positionsdatei nehmen. Dazu muß aber folgendes noch passen : Rechnungs-Kopfdatei -> Kundendatei. Positionen -> Artikel ,oje schreib erst gar nicht mehr weiter. Die entsprechenden IDs müssen ja wohl auch passen. Sonst....siehe oben. Natürlich soll, wenn ein Kunde gelöscht wird auch dessen Rechnungen usw. gelöscht werden. D.h. die entsprechenden Trigger müssen her. Aber ein Trost ist ja, daß es noch andere gibt, die so etwas durchgezogen haben.

Gruß
Hansa

Hi Hansa

Zitat:

Bin davon ausgegangen, daß im Zusammenhang mit ORDER BY zumindest sinnvollerweise ein Index benutzt werden sollte.

Doch, der Index wird schon verwendet. Aber eben nur dann wenn du tatsächlich ein ORDER BY nach den Indexspalten verlangst.

Zitat:

Natürlich soll, wenn ein Kunde gelöscht wird auch dessen Rechnungen usw. gelöscht werden. D.h. die entsprechenden Trigger müssen her.

Da brauchst du gar keine Trigger. Die Kunden-ID in den Rechnungen und die Rechnungs-ID in den Positionen werden als FOREIGN KEY auf die entsprechenden Tabellen mit kaskadierenden Löschen eingetragen, dann brauchst du nur noch den Kundensatz zu löschen und alles weitere geht von selbst.

Gruss Lothar

Hi,

Zitat:

Doch, der Index wird schon verwendet. Aber eben nur dann wenn du tatsächlich ein ORDER BY nach den Indexspalten verlangst

Da komm ich nicht drum rum, das ist wichtig.

Zitat:

Die Kunden-ID in den Rechnungen und die Rechnungs-ID in den Positionen werden als FOREIGN KEY auf die entsprechenden Tabellen mit kaskadierenden Löschen eingetragen, dann brauchst du nur noch den Kundensatz zu löschen und alles weitere geht von selbst.

Ja, genau so, wie ichs im Moment mache. Aber es heißt doch, der Trigger müsse "abgefeuert" werden. Woher soll denn die DB wissen, was da noch alles gelöscht werden soll. Nur durch den Foreign Key ? Man kann den Trigger doch als "after delete" oder "before delete" einstellen, damit er weiß, was noch alles zu tun ist. Ähnlich wie mit einem Generator. Seh ich das falsch ?

Wahrscheinlich kapiere ich es aber nicht, weil die Foreign Keys bei mir auch noch nicht so richtig verwendet werden. Beispiel : Habe einen Kunden, den ich einer anderen Kundengruppe zuordnen will. In dem KG-Nr. Feld sieht man dann, glaube bei OnEnter oder so eine Listbox mit Auswahlmöglichkeit. Bisher ist es mir zwar gelungen die gewünschte KG nach Auswahl im Klartext auf dem Bildschirm anzuzeigen, aber nicht diese auch abzuspeichern, damit sie ab dann gilt.

Offensichtlich mache ich einen Fehler bei der Zuweisung dieses Foreign-Keys an die Kunde-Table, oder es ist in der DB etwas falsch eingerichtet. Stutzig gemacht hat mich, daß im OI kein Key-Feld auswählbar war. An welcher Stelle muß ich denn genau diesen Key zuordnen ?

Gruß
Hansa

Hi
ein Beispiel zur Verwendung von Foreign Keys. Eine fiktive Kundentabelle und eine Tabelle Kundengruppen:


Durch die Definition des Forein Key in der Kundentabelle passiert folgendes: Nehmen wir an du hast eine Gruppe mit der ID 1 und dieser Gruppe sind drei Kunden zugeordnet.
Wenn du die ID in der Gruppentabelle auf 2 änderst, ändern sich die Werte im Feld GR_ID der Kundentabelle automatisch mit.
Wenn du den Datensatz mit der ID 1 löschst, werden auch alle Kundensätze mit der entsprechenden ID gelöscht. Und zwar ohne weiteren Trigger oder ähnliches.

Gruss Lothar

Hi Lothar,

ich muß zugeben, daß das Schlüsselwort CASCADE mir noch nicht auffiel. Jetzt ist mir das (fast) klar. An anderer Stelle wurde beschrieben, wie das mit einem Trigger gemacht wird. Geht es so, wie Du schreibst, das wäre aber wesentlich einfacher. Wo ich aber immer noch nicht weiter komme : wo genau in Delphi sage ich meinem Programm "Kunde xy hast ab sofort Kundengruppe z" ? Die Foreign Keys bau ich nachher mal in die DB ein, aber dann ?

Gruß
Hansa

Hi
ich werd übers Wochenende mal ein kleines Beispiel machen. Hab ich deine eMehl Addi?

Gruss Lothar