nicht angemeldet
Full Table Scan schneller als Index Scan
TSHallo Forum,
ich habe eine Frage zu Indexen in den relationalen Datenbanken.
Folgende (theoretische) Situation: Ich habe eine große Tabelle und einen B-Baum-Index auf eine der Spalten.
Trotzdem stelle ich bei einer Bereichsanfrage (auf die indexierte Spalte bezogen) fest, dass Index nicht benutzt wird und ein Full Table Scan zustande kommt.
Woran könnte es liegen?
Schönen Dank im Voraus
Julia
-
Hello Julia,
Trotzdem stelle ich bei einer Bereichsanfrage (auf die indexierte Spalte bezogen) fest, dass Index nicht benutzt wird und ein Full Table Scan zustande kommt.
Woran könnte es liegen?
Ich nehme jetzt mal MySQL oder MariaDB als Datenbank an:
Um eine konkrete Antwort geben zu können, müssten wir die Spaltendefinition, die Indexdefinition und die Abfrage kennen.
Du kannst die Aufgabe auch der Datenbank stellen mit "EXPLAIN".
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo Tom S.,
vielen Dank für Deine Antwort!
Ich nehme jetzt mal MySQL oder MariaDB als Datenbank an:
Bei der Frage handelt es sich um eine grundsätzliche Frage mit einem konstruierten Beispiel.
D.h. ich versuche herauszufinden, unter welchen Bedingungen ein Full Table Scan einem Index Scan bevorzugt wird (Ist ja erstmal nicht der Sinn der Sache).
Du kannst die Aufgabe auch der Datenbank stellen mit "EXPLAIN".
Ich kann QEP nicht so gut interpretieren, dass ich daraus eine allgemeinere Regel für mich finden könnte.
Viele Grüße
Julia
-
Hello Julia,
Ich kann QEP nicht so gut interpretieren, dass ich daraus eine allgemeinere Regel für mich finden könnte.
? Bei "QEP" kenne ich jetzt den Langtext nicht. Was ist das?
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo TS,
Ich kann QEP nicht so gut interpretieren, dass ich daraus eine allgemeinere Regel für mich finden könnte.
? Bei "QEP" kenne ich jetzt den Langtext nicht. Was ist das?
query evaluation plan.
LG,
CK
-
-
-
-
Hallo Julia,
hach, endlich mal wieder eine interessante Datenbank-Frage 😀
Folgende (theoretische) Situation: Ich habe eine große Tabelle und einen B-Baum-Index auf eine der Spalten.
Trotzdem stelle ich bei einer Bereichsanfrage (auf die indexierte Spalte bezogen) fest, dass Index nicht benutzt wird und ein Full Table Scan zustande kommt.
Woran könnte es liegen?
Das wird vermutlich daran liegen, dass die Selektivität bzw. Kardinalität der Abfrage zu niedrig ist bzw. die des Index zu hoch ist.
Um einen Index zu befragen, muss die Datenbank (via Seek) auf der Festplatte hin- und herspringen. Wenn der Index also nicht so spezifisch ist, dass die Ergebnismenge klein ist, müsste das DBMS sehr viele Index-Vergleiche machen und deshalb häufig auf der Platte hin- und herspringen. Das ist sehr aufwendig.
Im Vergleich dazu kann die Datenbank bei einem Full Table Scan einfach in einem Rutsch die Tabelle sequentiell einlesen. Sequentielles Lesen ist deutlich weniger teuer als Random-Reads, weil der Festplattenkopf nicht ständig neu positioniert werden muss. Deshalb kann es günstiger sein, einen Full Table Scan zu machen als einen Index zu nutzen.
Der Performance-Unterschied zwischen Random-Reads und Sequential-Reads wird bei modernen SSDs immer kleiner, weshalb man die Performance-Penalty für Random Reads bei SSDs gerne herunter setzt; ist die Performance-Penalty für ein Seqscan etwa 1.0, dann setzt man sie bei konventionellen Festplatten gerne auf 4.0 und bei modernen SSDs auf 1.1.
LG,
CK-
Hallo Christian,
vielen Dank für Deine ausführliche und sehr hilfreiche Antwort!
Das wird vermutlich daran liegen, dass die Selektivität bzw. Kardinalität der Abfrage zu niedrig ist bzw. die des Index zu hoch ist.
Um einen Index zu befragen, muss die Datenbank (via Seek) auf der Festplatte hin- und herspringen. Wenn der Index also nicht so spezifisch ist, dass die Ergebnismenge klein ist, müsste das DBMS sehr viele Index-Vergleiche machen und deshalb häufig auf der Platte hin- und herspringen. Das ist sehr aufwendig.
Im Vergleich dazu kann die Datenbank bei einem Full Table Scan einfach in einem Rutsch die Tabelle sequentiell einlesen. Sequentielles Lesen ist deutlich weniger teuer als Random-Reads, weil der Festplattenkopf nicht ständig neu positioniert werden muss. Deshalb kann es günstiger sein, einen Full Table Scan zu machen als einen Index zu nutzen.
Ok, ich glaube, ich habe es verstanden und fasse zusammen:
- Wenn wir eine kleine Tabelle haben, macht es keinen Sinn, Index Scan zu nutzen.
- Wenn die Anfrage ein Ergebnis mit hoher Kardinalität (also mit vielen Zeilen) liefert, macht es auch Sinn Full Table Scan zu nutzen.
Gilt es nur für B-Baum-Indexe (Daten nicht nur in den Blättern, sondern auch in inneren Knoten)? Oder für alle Index-Strukturen? (B+/B*-Baum, Hash-, Bitmap-Index)?
Noch mal Danke und viele Grüße
Julia
-
Hallo Julia,
- Wenn wir eine kleine Tabelle haben, macht es keinen Sinn, Index Scan zu nutzen.
Richtig.
- Wenn die Anfrage ein Ergebnis mit hoher Kardinalität (also mit vielen Zeilen) liefert, macht es auch Sinn Full Table Scan zu nutzen.
Richtig.
Gilt es nur für B-Baum-Indexe (Daten nicht nur in den Blättern, sondern auch in inneren Knoten)? Oder für alle Index-Strukturen? (B+/B*-Baum, Hash-, Bitmap-Index)?
Das gilt prinzipiell für alle Index-Strukturen, allerdings unterscheidet sich das Verhalten ein wenig je nach Index-Art und der Natur Daten.
LG,
CK-
Hallo Christian,
alles klar, danke Dir!
Viele Grüße, Julia
-
Hello,
Um einen Index zu befragen, muss die Datenbank (via Seek) auf der Festplatte hin- und herspringen. Wenn der Index also nicht so spezifisch ist, dass die Ergebnismenge klein ist, müsste das DBMS sehr viele Index-Vergleiche machen und deshalb häufig auf der Platte hin- und herspringen. Das ist sehr aufwendig.
Um eine sehr große Sequenz einzulesen muss der Kopf i.d.R. auch sehr oft auf der Platte hin- und herspringen. Die Datei liegt normalerweise ja in Clustern auf der Platte, die in der Praxis selten direkt hintereinander liegen. Es ist auch kaum anzunehmen, dass sich die gesamte Datei bereits serialisiert im RAM befindet.
In sofern verstehe ich deine Erklärung jetzt nicht. Ob zehn Indexseiten geholt werden müssen, oder 3.000 quer über die Platte verteilte Datenblöcke, die kaum alle im Cache gehalten werden können.
Wo liegt denn da nun mein Verständnisproblem?
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo TS,
Wo liegt denn da nun mein Verständnisproblem?
In der Annahme, alle Dateisysteme wären fragmentiert. Sind sie aber nicht. Moderne Dateisysteme halten die Fragmentierung klein und gering.
LG,
CK-
Hello,
Wo liegt denn da nun mein Verständnisproblem?
In der Annahme, alle Dateisysteme wären fragmentiert. Sind sie aber nicht. Moderne Dateisysteme halten die Fragmentierung klein und gering.
Dann wäre es doch sinnvoller, zunächst mal den Index unfragmentiert zu halten, bzw. im Cache.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo TS,
Wo liegt denn da nun mein Verständnisproblem?
In der Annahme, alle Dateisysteme wären fragmentiert. Sind sie aber nicht. Moderne Dateisysteme halten die Fragmentierung klein und gering.
Dann wäre es doch sinnvoller, zunächst mal den Index unfragmentiert zu halten, bzw. im Cache.
Der Index ist aufgrund seiner Datenstruktur „fragmentiert.“ Um in einem Baum zu suchen musst du ja innerhalb dieses Baumes den Knoten folgen.
Und ja, große Teile des RAMs auf dedizierten Datenbankservern wird für Cache verwendet, da hat ext recht. Das wird in die Kostenabschätzung auch mit einbezogen. Bei PostgreSQL gibt es dafür etwa den Parameter
effective_cache_size. Mehreffective_cache_sizemacht es wahrscheinlicher, dass ein Index benutzt wird.LG,
CK-
Hello,
Dann wäre es doch sinnvoller, zunächst mal den Index unfragmentiert zu halten, bzw. im Cache.
Der Index ist aufgrund seiner Datenstruktur „fragmentiert.“ Um in einem Baum zu suchen musst du ja innerhalb dieses Baumes den Knoten folgen.
Selbstverständlich. Das war dumm ausgedrückt.
Die einzelnen Blätter des Index-Baums sollten unfragmentiert vorliegen. Das versucht man ja, indem man die Blattgröße mit der Blocksize im Dateisystem harmonisiert, bzw. die Blätter/Blöcke mit genügend "Luft" ausstattet.
Aber z. B. zehn Zugriffe über den Index würde schon eine erhebliche Indextiefe (Spezifität) bedeuten, während 10 Zugriffe auf die Daten (die müssen ja totzdem die Buffersize beachten) vielleicht erst 0.1% der Datei erfasst haben.
Vielleicht hänge ich, geprägt von Novell und Elevator Seeking und ähnlichen Techniken noch zu dicht an der Hardware, oder aber Ihr nicht dicht genug?
Und in meiner Vorstellung kann ein mit z. B. 128 GB RAM ausgestatter Host die auch nicht "mal eben" komplett für einen einzigen DB-Filezugriff zur Verfügung stellen, sondern muss seine Gunst verteilen. Und da gäbe es als Flaschenhals auch immer noch die maximale Datentransferrate zwischen HDD und RAM. In z. B. 10x8ms (für die vermuteten Indexzugriffe) wird man kaum die komplette Datei in den RAM bewegen können.
Nach meinem Verständnis hinkt das immer noch. Da muss es erlaubt sein, nach der Kompexität der Abfrage und näheren Details zur Index- und zur Spaltendefinition zu fragen :-O
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo TS,
Aber z. B. zehn Zugriffe über den Index würde schon eine erhebliche Indextiefe (Spezifität) bedeuten, während 10 Zugriffe auf die Daten (die müssen ja totzdem die Buffersize beachten) vielleicht erst 0.1% der Datei erfasst haben.
Du hast das Kriterium missverstanden oder nicht beachtet. Der Index wird ignoriert, wenn entweder das Resultset zu groß wird, so dass ein Index-Scan sich nicht mehr lohnt oder wenn die Tabelle zu klein ist. Wenn du eine große Tabelle hast und ein kleines Resultset (10 Rows sind sehr klein), dann wird der Index benutzt. Niemand hat gesagt, dass ein Index keinen Sinn macht.
Und in meiner Vorstellung kann ein mit z. B. 128 GB RAM ausgestatter Host die auch nicht "mal eben" komplett für einen einzigen DB-Filezugriff zur Verfügung stellen, sondern muss seine Gunst verteilen. Und da gäbe es als Flaschenhals auch immer noch die maximale Datentransferrate zwischen HDD und RAM.
So funktioniert Caching auch nicht. Gecached wird, was häufig gebraucht wird. Auf einem dedizierten DB-Server ist das oft genug die vollständige Datenbank, wenn die allerdings nicht in den Speicher passt, dann sind das nur die Teile, die am häufigsten gebraucht werden. Caching funktioniert nicht so, dass bei einer einmaligen Anforderung alles in den RAM geladen wird.
Wenn du aber weiterhin auf sequential read vs random read abziehst: dann hast du immer noch die falsche Prämisse im Kopf. Bei einer großen Tabelle (ich setzte hier deine theoretischen 128gb an) und einem kleinen Resultset (ich setze hier deine 10 Rows an) wird natürlich ein Index verwendet.
Plakatives Beispiel: wenn du aber von den 128gb bei einer Abfrage 100gb der Rows zurück bekommen würdest, wird kein sinnvolles DBMS der Welt den Index verwenden.
Oder, alternativ: deine Tabelle belegt gerade mal eine Page, von denen du 10 Rows haben willst, da wäre ein Index-Zugriff völlig bescheuert.
Nach meinem Verständnis hinkt das immer noch.
Das liegt daran, dass du die Kriterien, nach denen das entschieden wird, immer noch nicht verstanden zu haben scheinst.
Aber du brauchst dich ja nicht auf mein Wort zu verlassen. PostgreSQL und MySQL haben das vorzüglich dokumentiert. Lies es dort nach.
LG,
CK-
Hello CK,
ich sortiere mal etwas um:
Aber du brauchst dich ja nicht auf mein Wort zu verlassen. PostgreSQL und MySQL haben das vorzüglich dokumentiert. Lies es dort nach.
Ich vertraue deinem Wort i. d. R. schon und auch meistens gerne :-)
Ich möchte nur deinen Gedankengang verstehen und auch herausfinden, wieso die Bewertung der Frage scheinbar unabhängig von den Randbedingungen stattfinden kann.Du selber schreibst doch nun hier einige Wenns und Abers. Die Reaktion des Optimizers hängt also augenscheinlich doch von Bedingungen ab.
Aber z. B. zehn Zugriffe über den Index würde schon eine erhebliche Indextiefe (Spezifität) bedeuten, während 10 Zugriffe auf die Daten (die müssen ja totzdem die Buffersize beachten) vielleicht erst 0.1% der Datei erfasst haben.
Du hast das Kriterium missverstanden oder nicht beachtet. Der Index wird ignoriert, wenn entweder das Resultset zu groß wird, so dass ein Index-Scan sich nicht mehr lohnt oder wenn die Tabelle zu klein ist. Wenn du eine große Tabelle hast und ein kleines Resultset (10 Rows sind sehr klein), dann wird der Index benutzt. Niemand hat gesagt, dass ein Index keinen Sinn macht.
Soweit kann ich das nachvollziehen. Allerdings: woher soll das DBMS wissen, ob ein Ergebnis zu groß werden wird. Selbst bei einer so vagen Abfrage "... WHERE <SPALTE> LIKE 'Sch%'" muss das Ergebnis nicht groß werden und erfahrungsgemäß wird hier auch ein Index benutzt, falls er auf <SPALTE> existiert. Anders sieht es bei "... WHERE <SPALTE> LIKE '%sch'" aus. Da wird der Index (üblicherwweise von links nach rechts indiziert) keinen Sinn haben. Ich will aber nicht in Abrede stellen, dass es auch DBMS mit einem Reverse Index (also von rechts nach links indiziert) geben könnte.
Das nur soweit, dass Du verstehst, warum ich auf Nennung des Querys plädiere.
Und in meiner Vorstellung kann ein mit z. B. 128 GB RAM ausgestatter Host die auch nicht "mal eben" komplett für einen einzigen DB-Filezugriff zur Verfügung stellen, sondern muss seine Gunst verteilen. Und da gäbe es als Flaschenhals auch immer noch die maximale Datentransferrate zwischen HDD und RAM.
So funktioniert Caching auch nicht. Gecached wird, was häufig gebraucht wird. Auf einem dedizierten DB-Server ist das oft genug die vollständige Datenbank, wenn die allerdings nicht in den Speicher passt, dann sind das nur die Teile, die am häufigsten gebraucht werden. Caching funktioniert nicht so, dass bei einer einmaligen Anforderung alles in den RAM geladen wird.
Genau deshalb hatte ich ja darauf hingewiesen. Die Vorgehensweise muss das DBMS sehr wohl von den physischen Gegebenheiten abhängig machen, wenn es sinnvoll arbeiten will.
Wenn du aber weiterhin auf sequential read vs random read abziehst: dann hast du immer noch die falsche Prämisse im Kopf. Bei einer großen Tabelle (ich setzte hier deine theoretischen 128gb an) und einem kleinen Resultset (ich setze hier deine 10 Rows an) wird natürlich ein Index verwendet.
Die "10 Rows" bringst Du ins Spiel. Ich sprach von 10 Zugriffen innerhalb des Indexbaumes zur Auffindung eines Treffers, bzw. dann meinetwegen 10*10 für eine Treffermenge.
Plakatives Beispiel: wenn du aber von den 128gb bei einer Abfrage 100gb der Rows zurück bekommen würdest, wird kein sinnvolles DBMS der Welt den Index verwenden.
Wie stellt es fest, dass die Treffermenge so hoch sein wird (siehe auch oben)? Oder wird es mitten in der Ausführung der Abfrage die Strategie umstellen von Indexnutzung auf sequentiellen Scan, wenn z. B. jede zweite Row einen Treffer liefert?
Bei Index-Bäumen gibt es da ja auch immer noch das Problem der Nicht-Balanciertheit...
Oder, alternativ: deine Tabelle belegt gerade mal eine Page, von denen du 10 Rows haben willst, da wäre ein Index-Zugriff völlig bescheuert.
Das ist nachvollziehbar, weil das DBMS wissen sollte, wie groß seine Tabellen sind und ob sie auch on the Fly in den bereitgestellten Teil des RAM passen.
Nach meinem Verständnis hinkt das immer noch.
Das liegt daran, dass du die Kriterien, nach denen das entschieden wird, immer noch nicht verstanden zu haben scheinst.
Das siehst Du falsch.
Ich möchte ja gerade auf den Kriterien, nach denen das DBMS das entscheidet, bestehen. Und dazu gehören meiner Meinung nach auch die von mir geforderten Angaben.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo TS,
Ich möchte nur deinen Gedankengang verstehen und auch herausfinden, wieso die Bewertung der Frage scheinbar unabhängig von den Randbedingungen stattfinden kann.
Weil die Frage nicht war „warum wird bei dieser Query der Index nicht benutzt“ sondern „wie kommt das RDBMS zu der Entscheidung, einen Index nicht zu nutzen.“ Da die Entscheidung, ob ein Index benutzt wird oder nicht, auf einem Algorithmus basiert, kann auch ohne Kenntnis einer konkreten Query der Entscheidungsbaum, auf dem diese Entscheidung basiert, beschrieben werden.
Du selber schreibst doch nun hier einige Wenns und Abers. Die Reaktion des Optimizers hängt also augenscheinlich doch von Bedingungen ab.
Selbstverständlich hängt er von Bedingungen ab. Und die Frage war, welche Bedingungen das sind.
Soweit kann ich das nachvollziehen. Allerdings: woher soll das DBMS wissen, ob ein Ergebnis zu groß werden wird.
Statistik. Reine Statistik, basierend auf den Metadaten, die das RDBMS über die Daten sammelt.
Selbst bei einer so vagen Abfrage "... WHERE <SPALTE> LIKE 'Sch%'" muss das Ergebnis nicht groß werden und erfahrungsgemäß wird hier auch ein Index benutzt, falls er auf <SPALTE> existiert.
Das dürfte sehr stark vom DBMS und der Qualität der Statistiken sowie der abgeschätzten Größe des Resultsets abhängen. PostgreSQL etwa hat Statistiken über die Kardinalität eines Index, sowie Statistiken basierend auf Histogrammen, usw. Mal ein Beispiel auf Basis der Foren-Datenbank:
> explain select message_id from messages where message_id = 10; QUERY PLAN ----------------------------------------------------------------------------------- Index Only Scan using messages_pkey on messages (cost=0.43..2.65 rows=1 width=8) Index Cond: (message_id = 10) (2 Zeilen)Das
rows=1sagt dir, dass PostgreSQL hier eine Zeile vermutet. Kunststück bei einem primary key ;-) und dementsprechend wird auch der Index verwendet.> explain select message_id from messages where message_id > 10; QUERY PLAN ------------------------------------------------------------------- Seq Scan on messages (cost=0.00..206608.54 rows=1728194 width=8) Filter: (message_id > 10) (2 Zeilen)PostgreSQL sagt dir hier mit
rows=1728194, dass es 1.728.194 Zeilen erwartet und dementsprechend der Index keinen Sinn macht.cforum_development=# explain select message_id from messages where message_id > 1728060; QUERY PLAN ----------------------------------------------------------------------------------- Index Only Scan using messages_pkey on messages (cost=0.43..3.74 rows=2 width=8) Index Cond: (message_id > 1728060) (2 Zeilen)Hier sagt PostgreSQL dir, dass es 2 rows erwartet und dementsprechend der Index benutzt wird.
Das nur soweit, dass Du verstehst, warum ich auf Nennung des Querys plädiere.
Nur dass nicht nach der Optimierung einer Query gefragt wurde, sondern nach dem Entscheidungsbaum eines Algorithmus.
Plakatives Beispiel: wenn du aber von den 128gb bei einer Abfrage 100gb der Rows zurück bekommen würdest, wird kein sinnvolles DBMS der Welt den Index verwenden.
Wie stellt es fest, dass die Treffermenge so hoch sein wird (siehe auch oben)?
Siehe oben. Über Statistik.
Oder wird es mitten in der Ausführung der Abfrage die Strategie umstellen von Indexnutzung auf sequentiellen Scan, wenn z. B. jede zweite Row einen Treffer liefert?
Nein. Ich wüsste jetzt auch nicht, wie man das implementieren sollte.
Bei Index-Bäumen gibt es da ja auch immer noch das Problem der Nicht-Balanciertheit...
Das ist ein völlig anderes Themengebiet. tl;dr-Version: um das zu vermeiden, wird idR ein Reindex bzw. optimize in regelmäßigen Intervallen ausgeführt. Das allerdings nicht von dem DBMS selber.
LG,
CK-
Hello CK,
danke!
Schöne Query-Beispiele :-)Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
-
-
-
-
-
-
-
Um eine sehr große Sequenz einzulesen muss der Kopf i.d.R. auch sehr oft auf der Platte hin- und herspringen. Die Datei liegt normalerweise ja in Clustern auf der Platte, die in der Praxis selten direkt hintereinander liegen.
Diese Annahme ist im wesentlichen falsch, moderne Dateisysteme verhindern Fragmentierung durch geschickteres Ablegen von Dateien (und verschieben derselben, wenn der vorgeplante Erweiterungsplatz nicht mehr ausreicht; deswegen u.a. existiert der standardmäßige 5% für den root-User reservierte Speicherplatz auf einer Partition) und NTFS unter Windows wird standardmäßig regelmäßig defragmentiert (und fragmentiert auch weniger als früher und deutlich weniger als FAT davor).
Es ist auch kaum anzunehmen, dass sich die gesamte Datei bereits serialisiert im RAM befindet.
Auf einem dedizierten Datenbankserver wird ein Großteil des RAM genau dafür verwendet.
-
-
-
hi,
die Suche nach einer Antwort auf die Frage wie ein B-Tree Index funktioniert führt mich zu einem Fachbuch von Niklaus Wirth.
Soll ich da mal reingucken oder möchtest Du das selber tun?
MfG
-
Hallo pl,
vielen Dank für Deine Antwort!
die Suche nach einer Antwort auf die Frage wie ein B-Tree Index funktioniert führt mich zu einem Fachbuch von Niklaus Wirth.
Soll ich da mal reingucken oder möchtest Du das selber tun?
Das Buch besitze ich leider nicht.
Viele Grüße
Julia
-
-
Hello,
BTW:
zum diskutierten Thema möchte ich noch eine Fast-Anekdote aus meiner "Jugend" beisteuern.Mein erster PC war ein IBM XT mit zwei Diskettenlaufwerken 5,25".
Wir hatten damals die geniale Idee eines Musikprogramm-Planungsprogramms. Meine Kenntnisse erstreckten sich recht tief auf dBase, die meines Kopiloten waren hochgradig musisch orientiert. Eigentlich eine gute Kombination ;-)Also haben wir versucht, ein Datenmodell für die Aufgabenstellung zu erstellen. Das wäre heutzutage jedem einsichtig und würde auch die Indexe erklären, die wir angelegt haben. Nun begab es sich aber, dass auch neue Datensätze eingetragen werden sollten - irgendwie logisch, wenn man sein ganzes Repertoire abarbeiten will. Irgendwie konnten wir das Projekt dann aber nicht umsetzen, weil jeder Eintrag eines neuen Datesatzes das Updaten von mindestens vier Indexen erforderlich machte, was dann zu mehreren Minuten Wartezeit führen konnte pro Datensatz.
5,25"-Disklaufwerke waren eben bei 640KB Arbeitspeicher nicht so unbedingt der Knaller.
Als wir uns dann nach einem Jahr eine HDD, 20MB, Hersteller Seagate, Zugriffszeit 80ms, Preis 700DM plus MwSt leisten konnten, wurde das Programm plötzlich benutzbar. Nur da hatten wir dann keine Lust mehr, es fertigzustellen und die Papierformulare für jede Single neu einzugeben. Der Rundfunk hatte schon etwas ähnliches aus USA gekauft und für uns alleine war es zu teuer.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo zusammen,
ich habe heute meine mündliche Prüfung in relationalen Datenbanken abgelegt (und zwar mit 1,0! ☺) und möchte mich noch mal für Eure Unterstützung bedanken!
Viele Grüße
Julia