Index und die Schnelligkeit

[lisamarie87]

Hallo Leute,

ich bin noch ein Anfänger im Bereich der Programmierung, arbeite jedoch bereits mit Datenbanken.
Ich höre immer von vielen Programmierern, dass Indexes bei vielen Datensätzen eine deutliche Beschleunigung der Tasks hervorbringt, doch ich frage mich wie das genau funktioniert?

Würde mich freuen, wenn ich eine Antwort darauf erhalte.

Meine Tabellenstruktur sieht folgendermaßen aus:

id - name - ort - ortsteil - plz - land - timestamp

Ich habe hier über 250.000 Einträge in dieser Tabelle und frage bei einem SELECT immer den ORT ab. Wie funktioniert dort ein Index? was genau sind die Vorteile und Nachteile?

Freue mich auf euer Feedback!

[Namenloser]

Hallo lisamarie87,

ein Index erhöht die Geschwindigkeit bei der Suche nach einer Zeile. Also sozusagen die "WHERE"-Klausel in der SQL-Abfrage. Welche Spalten du abfragst (SELECT), ist irrelevant. Also ob du "SELECT ort FROM tabelle" ausführt oder "SELECT * FROM tabelle" – das ist egal, da kann der Index nichts beschleunigen.

Wenn du aber z.B. "SELECT * FROM tabelle WHERE ort='Frankfurt'" ausführst – dann macht es einen Unterschied. Denn ohne Index müsste das DBMS alle Zeilen der Reihe nach durchgehen (Full Table Scan) und prüfen, ob die WHERE-Klausel zutrifft. Das wird natürlich immer langsamer, je mehr Einträge in der Datenbank sind. Mit Index geht es wesentlich schneller.

Stell dir ein Telefonbuch (ganz klassisch, aus Papier) vor. Wenn du zu einem Namen die Telefonnummer finden willst, dann geht das recht schnell, weil die Namen sortiert sind. Das ist die Suche mit Index. Jetzt stell dir vor, das Telefonbuch wäre nicht sortiert, sondern die Paare aus Namen und Nummern würden in zufälliger Reihenfolge drinstehen. Dann würdest du ewig nach dem richtigen Eintrag suchen. Das ist die Suche ohne Index.

Ein Index ist in der Regel als balancierter Baum umgesetzt. Es gibt aber auch andere Index-Arten, die z.B. auf Hashtabellen basieren. Alles hat seine Vor- und Nachteile.

[BrightAngel]

Hey! Willkommen in der Delphi-Praxis! :)

Im Prinzip hat Namenloser schon das wesentliche genannt, ich würde nur noch ergänzen, dass deine spezielle Tabelle ja eine Spalte "id" hat und du diese vermutlich als Primärschlüssel (und unique) angelegt hast. Das ist auch schon ein Index der Tabelle dann.
Eine Tabelle kann aber mehrere "Indexspalten" haben, wenn man diese explizit anlegt. Das macht man über CREATE INDEX Aufrufe. An der eigentlichen SELECT, INSERT, UPDATE Anfragensyntax ändert sich dann nichts. Man hat der Datenbank durch den Index nur beigebracht, dass bestimmte Spalten (in Kombination) indiziert werden sollen (so wie Namenloser beschrieb).

Viel Spaß hier bei uns! :)

Brighty

[haentschman]

Moin...:P

Zitat:

Stell dir ein Telefonbuch (ganz klassisch, aus Papier) vor.

...solche Fragen kannst du heute nicht mehr stellen. :stupid: Da kriegst du "Telefonbuch aus Papier? Was ist das?" :stupid: (wie mit dem Walkman :wink:)

Zitat:

Eine Tabelle kann aber mehrere "Indexspalten" haben, wenn man diese explizit anlegt.

Hier muß man vorsichtig sein. :warn: Viel hilft nicht immer viel. Der Index, ausgenommen der PrimaryKey, sollte nur auf den Feldern liegen, die auch zur WHERE Bedingung "passen". Bei Firebird z.B. hatte ich schon mal einen zusammengesetzten Index der langsamer war als die Felder mit einem separatem Index. :wink: Da hilft auch ausprobieren...

PS: Hast du dich mal mit der MySQL Lizenzfalle beschäftigt? Kämen denn andere DBMS auch in Frage?

Zitat:

ich bin noch ein Anfänger im Bereich der Programmierung, arbeite jedoch bereits mit Datenbanken.

An dieser Stelle der Hinweis auf die Normalisierung:
https://de.wikipedia.org/wiki/Normal...ng_(Datenbank)
...ein wichtiger Teil des Datenbankdesigns. 8-) Für den Anfang reicht die erste bzw. zweite Normalform. :thumb:

[lisamarie87]

Hey,

vielen Dank schonmal für die zahlreichen Antworten! Das ging ja extrem schnell :D

Jetzt verstehe ich endlich mal, was ein Index ist und wie es anzuwenden ist. Sehr interessant!
Hab vorhin mal in meiner Tabelle ausprobiert (da einfach ein Index auf die Orts-Spalte gesetzt) und die Abfragen dauern jetzt nicht mehr so ewig. Danke euch!

@ haentschman: Was genau meinst du für eine Lizenzfalle? Davon habe ich noch nie gehört? :?:

[jobo]

Zitat:

Zitat von lisamarie87 (Beitrag 1372596)

Hey,

@ haentschman: Was genau meinst du für eine Lizenzfalle? Davon habe ich noch nie gehört? :?:

Deswegen nennt man es ja Falle :) Wenn es jeder wüsste, wäre es keine Falle.

Du landest bei mySQL recht schnell und unwillkürlich bei dem Problem, dass es bei Verkauf Deiner Programme, die Du ggF. mit mySQL oder mySQL Client Komponenten auslieferst nicht mehr kostenlos ist.
Ich bin da nicht ganz firm, weil ich niemals mySQL einsetzen würde und es mich eigentlich nicht interessiert.

Zum Thema:
Eine Tabelle kann mehrere Indize haben.
Ein Index kann mehrere Spalten indizieren in Kombination, Reihenfolge der Spalten kann dabei von Bedeutung sein (im Verhältnis zur späteren Abfrage)
Ein Index hat einen Namen.
Eine Tabelle mit PK bekommt idr. automatisch einen Index "zugeteilt". (Man hat also Indizes in seiner DB, ohne dass man je darüber nachgedacht hat)
Ein Index ändert nicht die Funktionsweise der Tabellen (nur die Geschwindigkeit)
(Ok, im Fall "ohne Index= unendlich langsam" gewissermaßen auch die Funtkion)
Art, Verwendung und Effekt eines Index ist in jedem DB System und auch in jeder Version eines Systems anders.
Das "Gegenstück" zum Index ist der Optimizer, der vorhande Indizes analysiert und je Abfrage entscheidet, wie er sie benutzen wird.
Der Optimizer erstellt einen Ausführungsplan für jede Abfrage.
Den Ausführungsplan kann man sich anzeigen lassen, falls man sich wundert, warum die Abfrage so langsam ist.

[haentschman]

Zitat:

Du landest bei mySQL recht schnell und unwillkürlich bei dem Problem, dass es bei Verkauf Deiner Programme, die Du ggF. mit mySQL oder mySQL Client Komponenten auslieferst nicht mehr kostenlos ist.

Noch ein paar Informationen dazu:
http://www.delphipraxis.net/182945-m...att-mysql.html

Zitat:

Die Clientbibliothek/ODBC Treiber usw.
Direkter Zugriff ist z.B. mit MyDAC/UniDAC möglich. Hierbei verbindet sich das Programm direkt mit dem server, anstatt eine Schnittstelle der Clientbibiothek zu verwenden.
http://www.devart.com/mydac/

Es gibt andere DBMS Systeme ohne die Falle. :thumb: Mein bevorzugtes ist Firebird, für den Anfang mit ZEOS(kostenlos) statt UniDAC(kostenpflichtig)...:wink:

[Bernhard Geyer]

Zitat:

Zitat von haentschman (Beitrag 1372602)

Zitat:

Du landest bei mySQL recht schnell und unwillkürlich bei dem Problem, dass es bei Verkauf Deiner Programme, die Du ggF. mit mySQL oder mySQL Client Komponenten auslieferst nicht mehr kostenlos ist.

Noch ein paar Informationen dazu:
http://www.delphipraxis.net/182945-m...att-mysql.html

Zitat:

Die Clientbibliothek/ODBC Treiber usw.
Direkter Zugriff ist z.B. mit MyDAC/UniDAC möglich. Hierbei verbindet sich das Programm direkt mit dem server, anstatt eine Schnittstelle der Clientbibiothek zu verwenden.
http://www.devart.com/mydac/

Es gibt andere DBMS Systeme ohne die Falle. :thumb: Mein bevorzugtes ist Firebird, für den Anfang mit ZEOS(kostenlos) statt UniDAC(kostenpflichtig)...:wink:

Wenn man eine andere DB als evtl. eh schon beim Kunden im Einsatz ist, so hat man das Problem das man damit auch die veranwortung für das DBMS übernimmt (Backup, Desaster Recovery, ...). Setzt man auf ein DBMS das schon beim Kunden im Einsatz ist, so hat man hier kein Probleme.

[haentschman]

Zitat:

ich bin noch ein Anfänger im Bereich der Programmierung, arbeite jedoch bereits mit Datenbanken.

...:gruebel:

Zitat:

Wenn man eine andere DB als evtl. eh schon beim Kunden im Einsatz ist, so hat man das Problem das man damit auch die veranwortung für das DBMS übernimmt (Backup, Desaster Recovery, ...). Setzt man auf ein DBMS das schon beim Kunden im Einsatz ist, so hat man hier kein Probleme.

...diese Frage stellt sich nicht. :P

[jobo]

Zitat:

Zitat von haentschman (Beitrag 1372606)

...diese Frage stellt sich nicht. :P

Naja, ich denke aus Bernhards Hinweis spricht viel Erfahrung und einem Anfänger dieses Thema abzusprechen wäre anhand der Infos hier glaub ich etwas Bevormundung.

[Hobbycoder]

Zitat:

Zitat von jobo (Beitrag 1372608)

Naja, ich denke aus Bernhards Hinweis spricht viel Erfahrung und einem Anfänger dieses Thema abzusprechen wäre anhand der Infos hier glaub ich etwas Bevormundung.

Wobei ich aber das hier

Zitat:

Zitat von Bernhard Geyer (Beitrag 1372604)

Setzt man auf ein DBMS das schon beim Kunden im Einsatz ist, so hat man hier kein Probleme.

nicht pauschal unterschreiben würde.

[lisamarie87]

Oh menno - dann sollte ich wohl lieber direkt von Anfang an auf die MariaDB wechseln. Möchte nicht in irgendwelchen Lizenzfallen tappen, die mich dann teuer kosten würden!

Danke für euren Hinweis Leute, ihr seid Spitze!

[jobo]

Mmh, also auch wenn MariaDB gerade eine Millionenförderung bekommt, wäre es auch nicht an vorderer Stelle meiner Wahl.
mySQL und sein Fork maria würde ich evtl. nehmen, wenn ich auf einen billigen Hoster angewiesen bin, der das halt liefert. Aber ohne Not nähm ich es eben nicht.
Bei freier Wahl:
- postgresql
- firebird

bei Mini/Web/lokalen/embedded Projekten
- SQLite

[p80286]

Ruhig Brauner!!
Bevor wir uns jetzt wieder über die Vorzüge/Nachteile verschiedener DBMS in die Haare bekommen. Der/Die TE braucht im Augenblick einen Hinweis für ein brauchbares DBMS. welche Vorteile das eine oder andere hat, sollten wir zunächst noch zurück stellen.

Gruß
K-H

[lisamarie87]

Naja, wenn ich mit etwas anfange soll es ja auch irgendwo verwendbar sein. Wenn ich damit dann Lizenzprobleme bekomme, macht es für mich kein Sinn mit MySQL zu beginnen, oder sehe ich das falsch? :)

[bnreimer42]

Wenn Du auf Nummer sicher gehen willst, nimm ein System, das echt unter einer freien Lizenz steht.

Das ist bei Firebird und PostgreSQL der Fall.

Die Administration von Firebird ist in der Regel einfacher, es gibt erheblich weniger Einstellmöglichkeiten, als z.B. bei Postgres.

Ansonsten ist das Geschmackssache, welches System man verwendet oder es gibt beim Nutzer bereits ein System - wie bereits erwähnt. Da kann man aber reinfallen, wenn man auf das System dann nicht drauf gehen darf, z.B. weil der Hersteller, der ein RDBMs mit ausliefert, das Admin-PW nicht preisgibt.


Ich arbeite intensiv mit Firebird und PostgreSQL und beide Systeme haben Vorteile und Nachteile. Eine allgemeine Aussage, welches System besser oder schlechter ist, würde ich grundsätzlich als unseriös bezeichnen.

Grundsätzlich ist es aber so, dass einfache SQL-Statements auf allen genannten Datenbanksystemn in der Regel zum selben Ergebnis führen, so dass Ausprobieren und eine spätere Migration eine Option sein sollte.

[Bernhard Geyer]

Zitat:

Zitat von Hobbycoder (Beitrag 1372616)

Wobei ich aber das hier

Zitat:

Zitat von Bernhard Geyer (Beitrag 1372604)

Setzt man auf ein DBMS das schon beim Kunden im Einsatz ist, so hat man hier kein Probleme.

nicht pauschal unterschreiben würde.

Streiche kein und setze weniger ein.

[p80286]

Zitat:

Zitat von bnreimer42 (Beitrag 1372839)

Grundsätzlich ist es aber so, dass einfache SQL-Statements auf allen genannten Datenbanksystemn in der Regel zum selben Ergebnis führen, so dass Ausprobieren und eine spätere Migration eine Option sein sollte.

Solange die Dialekte kompatibel sind, halte ich das für selbstverständlich, da dürfen die Statements auch etwas komplexer sein. Interessant wird es z.B. wenn die Casesensivity standardmäßig unterschiedlich gehandhabt wird.
Aber so etwas steht, glaube ich, in den entsprechenden Handbüchern.

Gruß
K-H

[jobo]

Zitat:

Zitat von lisamarie87 (Beitrag 1372824)

Naja, wenn ich mit etwas anfange soll es ja auch irgendwo verwendbar sein. Wenn ich damit dann Lizenzprobleme bekomme, macht es für mich kein Sinn mit MySQL zu beginnen, oder sehe ich das falsch? :)

Richtig. Kommt natürlich drauf an, ob es erstmal nur Lernprojekte sind, die sowieso eingemottet werden. Aber warum nicht gleich richtig, also richtig/passend für das geplante Projekt? Wenn überhaupt, empfiehlt sich mySQL am ehesten für Webprojekte. Dürfte aber ja bei Delphi nicht das Kernthema sein.

Ich will natürlich nicht die Pferde scheu machen, also spar ich mir eine Wiederholung meiner Empfehlung. Es gibt dazu auch einige Threads hier. Falls die Deine Frage nicht passend transportieren, mach einen neuen Thread auf, in dem Du Deine Anforderungen schilderst.

Was Deine Ausgangsfrage hier angeht. Jedes einigermaßen etablierte Relationale Datenbank System arbeitet mit Indizes und das auf einem gewissen Nenner auch untereinander kompatibel.
Es gibt allerdings (mittlerweile) viele verschiedene Arten Indizes, die für unterschiedliche Zwecke immer weiter optimiert werden.
Hier ist eine Aufstellung dazu:
https://en.wikipedia.org/wiki/Compar...ystems#Indexes

Der Rest der Seite enthält noch viele andere Vergleiche, wenn man sich auf ein paar Systeme beschränkt und vergleicht, ist es ganz informativ.
Hier noch ein Link zum SQL Standard:
https://en.wikipedia.org/wiki/Sql#Standardization

Ich habe keine Gegenüberstellung verschiedener Hersteller gefunden. Bei Interesse muss man wahrscheinlich je Hersteller suchen, welchen ANSI SQL Standard er zu wieviel Prozent erfüllt.

[bnreimer42]

Zitat:

Zitat von p80286 (Beitrag 1372849)

Zitat:

Zitat von bnreimer42 (Beitrag 1372839)

Grundsätzlich ist es aber so, dass einfache SQL-Statements auf allen genannten Datenbanksystemn in der Regel zum selben Ergebnis führen, so dass Ausprobieren und eine spätere Migration eine Option sein sollte.

Solange die Dialekte kompatibel sind, halte ich das für selbstverständlich, da dürfen die Statements auch etwas komplexer sein. Interessant wird es z.B. wenn die Casesensivity standardmäßig unterschiedlich gehandhabt wird.
Aber so etwas steht, glaube ich, in den entsprechenden Handbüchern.

Gruß
K-H

Zumindest PostgreSQL und Firebird Dialket 3 (Dialekt 1 nutzt ja wohl keiner mehr, außer bei "Altlasten")kommen problemlos mit entweder ungequoteten Bezeichnern oder mit doppelgequoteten Mixedcase-Bezeichnern zu recht. Hier kann man nach seinem Geschmack wählen, was einem besser liegt.

So sieht es der SQL-Standard glaube ich auch vor.

[jobo]

Ich dachte, hier ging es p80286 eher um Dateninhalte.
Das wäre NLS Settings und Collations in den Griff zu kriegen.

Was das Datenmodell angeht, bin ich sehr konservativ. Objektnamen am liebsten on Englisch, ANSI, kurz ohne Firlefanz.
(Kurz ist wahrscheinlich eine Oracle Angewohnheit bei mir)