"Indiziert" für Fremdschlüssel aktivieren?
Torsten Kunze
macht es Sinn, für ein Tabellenfeld, dass in Beziehung zu einem
Primärschlüssel in einer Detailtabelle steht, die Eigenschaft "Indiziert"
auf "Ja" zu stellen oder kann man sich das sparen?
--
Torsten Kunze
Janine Mauer
"Torsten Kunze" <martin...@t-online.de> schrieb:
> macht es Sinn, für ein Tabellenfeld, dass in Beziehung zu einem
> Primärschlüssel in einer Detailtabelle steht, die Eigenschaft
> "Indiziert" auf "Ja" zu stellen oder kann man sich das sparen?
Durch indizieren eines Tabellenfeldes kann die Suche in dessen Inhalt
beschleunigt werden. Ob es Sinn macht hängt von der Tabellengröße ab. Wenn
die Tabelle und die Detailtabelle sehr groß sind (schätzungsweise ab 10.000
DS evtl. auch früher), solltest du den Fremd- und den Primärschlüssel
indizieren. Aber in diesem Falle würde ich Dir zur Nutzung des SQL-Servers
raten.
Gruß Janine
Philipp Stiefel
> "Torsten Kunze" <martin...@t-online.de> schrieb:
>
>> macht es Sinn, für ein Tabellenfeld, dass in Beziehung zu einem
>> Primärschlüssel in einer Detailtabelle steht, die Eigenschaft
>> "Indiziert" auf "Ja" zu stellen oder kann man sich das sparen?
>
> Durch indizieren eines Tabellenfeldes kann die Suche in dessen Inhalt
> beschleunigt werden.
Was oft vergessen wird: Nicht nur die Suche in Tabellenfeldern
wird durch Indizes beschleunigt, sondern auch die sortierte Ausgabe
von Daten, wenn das Feld, über das sortiert wird, indiziert ist.
> Ob es Sinn macht hängt von der Tabellengröße ab. Wenn
> die Tabelle und die Detailtabelle sehr groß sind (schätzungsweise ab 10.000
> DS evtl. auch früher), solltest du den Fremd- und den Primärschlüssel
> indizieren.
Wichtiger als die Tabellengröße ist eigentlich die Selektivität
der Daten in den fraglichen Spalten. D.h. ein Index auf einer
Spalte mit vielen gleichen Daten bringt deutlich weniger (oder
evtl. ger nichts), als ein Index auf einer Spalte mit sehr vielen
verschiedenen Werten.
> Aber in diesem Falle würde ich Dir zur Nutzung des SQL-Servers
> raten.
Naja, mit 10.000 Datensätzen kommt Access aber noch absolut problem-
los klar. Auch das 10fache Datenvolumen kann oft durchaus noch von
Access verwaltet werden.
Gruß
Phil
Janine Mauer
"Philipp Stiefel" <ph...@codekabinett.de> schrieb:
> Janine Mauer <engels...@yahoo.de> wrote:
> > Aber in diesem Falle würde ich Dir zur Nutzung des SQL-Servers
> > raten.
>
> Naja, mit 10.000 Datensätzen kommt Access aber noch absolut problem-
> los klar. Auch das 10fache Datenvolumen kann oft durchaus noch von
> Access verwaltet werden.
Du hast recht, dass Access mit 10.000 DS klar kommt. Auch mit mehr, das
bestreite ich gar nicht. Aber meiner Ansicht nach sind 3 Min Wartezeit bei
einem "Select *" auf eine einzelne Tabelle mit einer Datensatzgröße von
25.000 DS mit 10 Feldern nicht akzeptabel. Klar ist das Ergebnis korrekt,
aber mir nur etwas zu lahm. Ausserdem gefällt mir die Art der Abfrage von
Access nicht. Access hat die Eigenart, das es immer schrittweise die
Datensätze abfragt. Sieht man auch wenn man eine Tabelle mit größerer
Datenmenge öffnet. Es holt nur ungefährt 100 DS in einem Zug. Ich habe bei
der selben Abfrage auf eine Oracle Datenbank von Access aus ein schlechteres
zeitliches Ergebnis erzielt als von VB oder Delphi aus.
Access ist hervorragend geeignet für kleine private Anwendungen, aber Firmen
sollten darauf verzichten und lieber eine unternehmensweite DB mit
SQL-Server oder Oracle aufbauen. Leider ist das Gegenteil oft der Fall.
Janine
Philipp Stiefel
> "Philipp Stiefel" <ph...@codekabinett.de> schrieb:
>> Janine Mauer <engels...@yahoo.de> wrote:
>
>> > Aber in diesem Falle würde ich Dir zur Nutzung des SQL-Servers
>> > raten.
>>
>> Naja, mit 10.000 Datensätzen kommt Access aber noch absolut problem-
>> los klar. Auch das 10fache Datenvolumen kann oft durchaus noch von
>> Access verwaltet werden.
>
> Du hast recht, dass Access mit 10.000 DS klar kommt. Auch mit mehr, das
> bestreite ich gar nicht. Aber meiner Ansicht nach sind 3 Min Wartezeit bei
> einem "Select *" auf eine einzelne Tabelle mit einer Datensatzgröße von
> 25.000 DS mit 10 Feldern nicht akzeptabel.
Eine solche Wartezeit ist sicherlich nicht aktzeptabel. Aber wenn du
bei einer einfachen Abfrage auf 25.000 Datensätze tatsächlich so lange
warten musst, dann läuft da irgendwas falsch. Ein "Select *" ohne
Kriterien ist zwar grundsätzlich keine sinnvolle Abfrage auf 25.000
Datensätze, aber dennoch sollte das schneller gehen. Wenn du die
Datensätze noch sinnvoll eingrenzt sollte die Abfrage nur wenige
Sekunden dauern.
> Ausserdem gefällt mir die Art der Abfrage von
> Access nicht. Access hat die Eigenart, das es immer schrittweise die
> Datensätze abfragt. Sieht man auch wenn man eine Tabelle mit größerer
> Datenmenge öffnet. Es holt nur ungefährt 100 DS in einem Zug.
Das ist richtig, aber eher ein Vorteil als ein Nachteil. Was willst
du mit so vielen Datensätzen gleichzeitig? - Wenn man Abfragen über
VBA ausführt, läßt sich dieses Verhalten auch umgehen.
> Ich habe bei
> der selben Abfrage auf eine Oracle Datenbank von Access aus ein schlechteres
> zeitliches Ergebnis erzielt als von VB oder Delphi aus.
Dafür kann es zahlreiche Gründe geben. Die gravierendsten Auswirkungen
hat oft die ungünstige Übersetzung einer Abfrage für den ODBC-Treiber.
Falls es dich interessiert, dazu habe ich unlängst einen längeren Text
geschrieben, der diese Problematik ausführlicher beschreibt.
-> http://www.codekabinett.com/rdumps.php?targetDoc=LinkedTablePerf
> Access ist hervorragend geeignet für kleine private Anwendungen, aber Firmen
> sollten darauf verzichten und lieber eine unternehmensweite DB mit
> SQL-Server oder Oracle aufbauen. Leider ist das Gegenteil oft der Fall.
Das kommt sehr auf die Firmengröße und den Zweck der Datenbank an.
In vielen Fällen kann ich dir absolut zustimmen, aber so pauschal,
wie du es oben formuliert hast, kann man es grundsätzlich nicht
sehen.
Viele Grüße
Phil