Hi, Delpher,

warum wird in dem folgenden Code der Index gesetzt?



und was bedeutet filtered?

Danke für Hilfe,
Detlef

Hallo!

Fangen wir hinten an:

D. Annies hat folgendes geschrieben:

und was bedeutet filtered?

Frei übersetzt: gefiltert.

D. Annies hat folgendes geschrieben:

warum wird in dem folgenden Code der Index gesetzt?

Welchen Index meinst Du? Etwa IndexName:='Name';?
Keine Ahnung!
Welchen Typ hat table, was macht first;.
Mehr Informationen, mehr Quelltext, bzw. konkretisiere Deine Frage!

Hi,
ich habe mich jetzt ein wenig belesen, jetzt ist es nicht mehr so dunkel. Filter hat im Vergleich mit Query Vor- und Nachteile.

bis dann,
Detlef

Hi,

wenn ich das mit einem Recordset vergleiche, dann ist First unwichtig. Mit First springt man zum 1. Datensatz, aber ein neu geöffneter Recordset steht immer im 1. Datensatz.

Danke, Jan, guter Hinweis.
Detlef

Hi



Hoffe, das mit dem Index war einigermaßen verständlich, erinnert mich irgendwie an alte COBOL-Zeiten

Gruß

Aga

Hi, Aga,

diesen Codeschnipsel habe ich aus dem Netz, ist nicht von mir.

Danke für deine Erläuterungen, sie geben mir doch Aufklärung, vor allem, was den Index betrifft, denn ich lasse häufig Schülerstammdaten nach dem Kriterium (gleiche) KLASSE ausgeben.

Bis denne,
Detlef

Kurze Nachfrage: Kann ich auch einen Sekundärindex vergeben, wenn ich keinen Primärindex habe?

D. Annies hat folgendes geschrieben:

Hi, Aga, diesen Codeschnipsel habe ich aus dem Netz, ist nicht von mir. Danke für deine Erläuterungen, sie geben mir doch Aufklärung, vor allem, was den Index betrifft, denn ich lasse häufig Schülerstammdaten nach dem Kriterium (gleiche) KLASSE ausgeben. Bis denne, Detlef Kurze Nachfrage: Kann ich auch einen Sekundärindex vergeben, wenn ich keinen Primärindex habe?

Hallo,

wenn du einen Index verwendest, erscheint dir die Datenbank in der Reihenfolge des Index sortiert, in dem Fall also nach Namen. Der Zugriff auf einen einzelnen "Meier" geht dann natürlich viel schneller, als wenn man dafür alles nacheinander durchsuchen müsste. Du kannst natürlich auch einen anderen Index angeben, wenn einer existiert, z.B. PLZ, dann sind die Daten eben nach PLZ sortiert. Ein Index nach PLZ wird nicht eindeutig sein, weil natürlich mehrere Personen die gleiche PLZ haben können. Im Gegensatz dazu ist ein Primärindex immer eindeutig.

Dein Codeschnipsel ist allerdings für die Frage nach Performance ein schlechtes Beispiel, weil dabei der Index keine Wirkung auf die Geschwindigkeit hat: du gehst ja eh die ganze Datenbank von Anfang bis Ende durch - das ginge auch ohne Index (und ist dann eben unsortiert, wahrscheinlich in der Reihenfolge der Eingabe).

Gruss Reinhard

Danke für deine ausführliche Antwort, Reinhard.

Wenn ich das jetzt richtig sehe, sollte ich bei einer DBTabelle, (die sonst natürlich unsortiert ist) sofort einen Index (= Primärindex) vergeben, dann ist sie sortiert nach diesem [eindeutigen] Key und ich brauche sie nicht extra mit einer Query zu sortieren - richtig?

Ist dann zweitens ein weiterer Key automatisch der Sekundärindex, z.B. wenn ich anders ausgeben will?

Ist dann drittens, wenn ich keinen Primärkey habe, der erste Schlüssel, den ich vergebe, der Primärkey oder der erste Sekundärkey?

(Ich hoffe, das war verständlich gefragt)

hoffentlich kommt wieder eine gute Antwort ...

Gruß, Detlef

Hi Detlef

ich nehme an, daß Du mit Deiner Datenbank auch die Noten verwaltest.
Daher wäre zu empfehlen, den Schüler-Stammsätzen eine eindeutige identifizierende Nummer mitzugeben.
Die Tabelle mit den Noten steht dann in einer 1:n Beziehung zur Stammdatentabelle.

Diese Nummer wäre dann Dein primärer Key und die Notendaten verbindest Du dann über die Nummer.

Für die Ausgabe der Schülerliste definierst Du einen sekundären Index, der am besten aus Klasse und Nachname besteht.

Da wird es dann bei Gleichnamigkeit zwar Duplikate geben, aber das macht eigentlich nichts...wenns noch genauer sortiert sein soll, dann nimmst Du noch den Vornamen dazu.

Um zu Deiner Frage zurückzukommen, es ist keineswegs so, daß die Datensätze physisch sortiert in der DB vorliegen, sondern wie gehabt in der Erstellungsreihenfolge.

Der Index wird in einer separaten Datenstruktur gespeichert, darum sollte man sich immer überlegen, ob ein Index Sinn macht, oder nicht, denn die Datenbank muß ja für jeden zusätzlichen Index einen separaten Schreibvorgang ausführen.

Darum kann man als Faustregel sagen, Stammdaten ändern sich selten, es werden auch nicht dauernd welche hinzugefügt, also sich hier sinnvolle Indizes zu überlegen, bringt immer was.
Bei Bewegungsdaten muß man etwas genauer nachdenken, denn hier werden Daten zwar seltener geändert, aber am laufenden Meter welche hinzugefügt.

Wie die Indexverwaltung passiert, hängt wohl vom DBMS ab. Wenn ich mich bei COBOL auf der P4000 richtig erinnere, (da war die Tabellenverwaltung Teil des Betriebssystem, glaub ist bei der AS400 genauso)....wurde ein Index so aufgebaut, daß physisch Lücken gelassen wurden und es gab eine Strategie, nach der dann nach und nach die Index-Daten reingefüllt wurden.
Das mit den ganzen Datensätzen zu machen, wäre natürlich irre, weil es wahnsinnig viel Speicherplatz frißt und das galt damals um so mehr.
Wurde dann der Bereich voll, wurde mit verketteten Listen gearbeitet...also die Index-Bereichsfortsetzung hinten dran gehängt.
Verkettete Listen bedeuten aber, daß die Datensätze, bzw. Indesätze physisch weit voneinander entfernt sind...das wiederum bedeutet Performanceverlust, weil sich der Lesekopf der Platte hin und her bewegen muß.
Um diesen Performance-Verlust zu mindern, mußte man ab und zu den Index reorganisieren.

Um das zu verdeutlichen, stell Dir vor, Du hast 1000 Bücher und 10 Meter Regal...Du willst die alphabetisch geordnet nach Autor in das Regal einräumen....jetzt kannst das natürlich alles erstmal vorsortieren, bildest also stapel mit A, B und so weiter und sortierst dann noch mal fein und räumst dann der Reihe nach ein, oder Du räumst gleich ein, indem Du halbwegs passende Lücken läßt.
Pech nur, wenn eine Lücke für die Menge zu klein war, dann muß derjenige, der ein Buch sucht, ans Ende des Regals laufen, oder Du mußt einige sortierte Stapel rausnehmen und anders positionieren, um wieder genug Raum zu schaffen.

Letztendlich ist es dasselbe Problem, wie bei fragmentiertem Speicher oder fragmentierter Festplatte.

Aber da wird jedes DBMS eben unterschiedliche Ansätze haben.

lies auch mal bei Wiki nach

de.wikipedia.org/wik...C3%A4rschl%C3%BCssel

Gruß

Aga

Hallo,

agawain hat ja schon einiges erklärt, dazu nur noch ein paar Ergänzungen:

Man könnte im Prinzip auch eine Datenbank sortieren (wie die Einträge in einer Listbox o.ä.), aber natürlich nur nach einem einzigen Kriterium, und man weiss in der Regel ja nicht von vornherein, nach welchem, also lässt man es gleich. Ausserdem wären erhebliche Datenmengen hin- und herzuschaufeln. In der Regel ist die Reihenfolge der Records daher unverändert die der Eingabe.

Ein Index ist im Prinzip ganz einfach: der Index für "Name" enthält für jeden Record das Feld Name und die laufende Nummer des Records (oder einen Zeiger darauf, das ist egal), und dieser Index ist tatsächlich physikalisch sortiert. Also sieht man für "Meier" in der Mitte der Indexdatei nach, wenn dort ein Name steht, der alphabetisch nach Meier kommt, dann steht Meier offensichtlich in der ersten Hälfte. Also sieht man in der Mitte der ersten Hälfte nach usw. (binäre Suche).

Sowas kann man auch in Pascal leicht selbst programmieren, ich habe für Werkzeugmaschinen schon Werkzeug-Datenbanken mit BTree+-Indexen geschrieben, die auf Z80-Prozessoren liefen. Etwas schwieriger ist bloss das Einfügen und Löschen von Records.

Primär und Sekundär-Indexe werden in den Datenbanken unterschiedlich gehandhabt, manche lassen nur einen, manche mehrere Primärindexe zu. Die viel wichtigere Unterscheidung ist, ob ein Index eindeutig ist, die meisten meinen mit primär eigentlich eindeutig. Zum Beispiel Kundendaten: ein erfahrener DB-Designer wird wahrscheinlich eine fortlaufende Kundennummer als Primärindex vorsehen, diese Nummer indentifiziert den Kunden dann eindeutig (Rechnung). Der Sachbearbeiter sucht aber (weil er kein Gedächtnisakrobat ist) nach Meier (Sekundärindex Name) und bekommt am Bildschirm eine Auswahl von x mal Meier angezeigt, aus denen sucht er sich den passenden raus. Die Buchhaltung andrerseits kann direkt und eindeutig zugreifen, weil auf der Rechnung ja die Kundennummer steht.

Wenn du über die ganze Datenbank iterierst (while not eof..), dann sind die Records wild durcheinander, iterierst du dagegen über den Index Name (den Index abklappern und mit dem Pointer den Record holen), dann erscheint die DB nach Namen sortiert. Wenn du eine Query sortieren lässt, passiert wahrscheinlich das Gleiche: eine vernünftige DB erstellt einen entsprechenden Index, macht danach die Ausgabe und löscht den Index wieder. Daher lohnt es sich, Indexe für oft gebrauchte Sortierungen fest anzulegen.

Falls noch nicht alle Klarheiten beseitigt sind, in einer Bibliothek oder Buchhandlung gibt es meterweise Literatur dazu. Kaum ein IT-Gebiet ist theoretisch so gut untermauert wie das DB-Design, das fing schon mit den ersten Hollerith-Lochkarten-Sortierern an.

Gruss Reinhard

Hi, Aga und Reinhard,

vielen Dank, mit diesen Informationen kann ich etwas anfangen! Ich bin ja bisher immer um Indizes "herumgeschlichen", nun werde ich wohl ein wenig nachbessern, aber das Prg wird ja nur schneller dadurch. Inzwischen habe ich auch DBASE-Infos bekommen, über die Eigenarten von diesen Indizes.

Vielen herzlichen Dank,
Detlef