Extreme Veteran
Beiträge: 566
| Hallo,
jojogar - 21.02.13 00:44 PeterDoering - 20.02.13 16:04 jojogar - 19.02.13 19:47
Bringt es einen Vorteil, wenn ich für das Fremschlüsselfeld in einer 1:n - Beziehung ohne referenzielle Integrität einen Index erstelle? Oder macht das die Jet/ACE -Engine dann automatisch ? Das macht nicht Jet/ACE, sondern Access, also das UI, für Felder mit entsprechenden Namen, siehe Options - Object Designers - AutoIndex ... Das wäre neu, Tabellen, Primär- und Fremdschlüssel, Beziehungen usw. verwaltet in jedem Fall die Engine.
Was in Access in den Optionen steht, gilt für den Datenimport, um bei bestimmten Feldnamen automstisch einen Schlüssel anzulegen (was dann die Engine erledigt )
Negativ (kommt natürlich auch ein bisserl darauf an, was du unter "verwalten" verstehst. ;-) Die Engine führt und wertet nur aus, was an Statements geliefert wird. Die Tabellen-/Abfrage-Definitionen stehen in der mdb/accdb und werden vom UI=Access verwaltet. Die Access-Optionen gelten sowohl fuer den Import, als auch die manuelle Pflege von Tabellen. Das erkennst du daran, wenn du im Tabellen-Designer ein Feld namens ID anlegst, die Eigenschaft Index wird automatisch auf Ja gestellt.
Mir geht es ja hier nur um die Frage, ob es bei einer 'einfachen' Beziehung sinnvoll ist, selbt einen Index für den Fremdschlüssel zu erstellen. Natürlich spielen für die Performance einer Abfrage noch weitere Faktoren eine Rolle.
Wenn du RI über den Assistenten anlegst, erstellt Access automatisch einen Index für den Join. Per SQL müsstest du das selbst machen. Im Zweifelsfall wuerde ich immer einen Index auf FK anlegen. Wenn die Lookup-Tabelle nur aus z.B. 2-3 Werten besteht (Linke/Mitte/Rechts, Ja/Nein/Vielleicht...), kann es durchaus sein, dass der Index keinen Vorteil bringt. Das wäre zu testen.
Habe mir inzwischen mal den Ausführungsplan einer Abfrage über beide Tabellen (Kunden-Buchungen) angesehen.
Sieht gut aus.
Offenbar kann ACE auch ohne RI und Fremdschlüsselindex mit rushmore arbeiten, ohne und mit FK-Index, von table-scan ist nichts zu lesen.
Wenn in Joins mit numerischen Feldern gearbeitet wird, versucht Jet/ACE immer, Rushmore einzusetzen. Bei Textfeldern gibt es das generell nicht.
Bleibt immer noch die Frage, wie sich das in der Praxis bei großen Datenmengen auswirkt und was ein manuell erstellter FK-Index ohne RI bringt ? Den Ausführungsplan hängt als Textdatei an.
Du wirst um eigene Tests nicht herum kommen, auch später, denn das Verhalten kann sich mit zunehmenden Datenmengen ändern.
----- Gruss - Peter |