Warum noch ein Access-Buch?
Für wen ist das Buch?
Jetzt bestellen
+ direkter Download des eBooks!
Nur EUR 59,95!
Fehler gefunden?
Bitte melden!
Wünsche an das Buch?
Her damit!
Was denken die Leser über dieses Buch?
Lesen Sie aktuelle Rezensionen!
Kapitel des noch nicht veröffentlichten Buchs zum Downloaden, Probelesen und Kommentieren
Beispieldatenbanken
Zusätzliches Material

Das Buch im HTML-Format

Für unbestimmte Zeit bieten Addison-Wesley und André Minhorst den kompletten Inhalt des Buchs als Download an. Schauen Sie rein und informieren Sie sich über den Inhalt! Und wenn Ihnen das Buch nützlich erscheint und Sie glauben, dass Sie etwas gelernt haben oder durch das Gelesene sogar etwas Zeit und somit Geld bei Ihrer Arbeit einsparen konnten, können Sie sich ja beim Autor und beim Verlag revanchieren - beispielsweise durch den Kauf dieses Buchs.

Am schönsten wäre es natürlich, wenn Sie das Buch direkt hier bestellen - Sie erhalten das Buch dann direkt vom Verlag, und der Autor und Verlag haben dann noch mehr davon, als wenn Sie es anderswo kaufen.

Danke für Ihr Interesse!

3.5.1 UNION-Abfragen zur Optimierung von Kombinationsfeldern

3.5.2 Eindeutige Schlüssel mit UNION-Abfragen

Einen gravierenden Nachteil haben UNION-Abfragen: Wenn die zumeist aus mehreren Tabellen zusammengeführten Daten eindeutig identifiziert werden sollen, um etwa einen ausgewählten Datensatz zu löschen, ist »Hängen im Schacht«. Das Problem ist, dass auch die Primärschlüssel aus mehreren Tabellen zusammengeführt werden und diese daher nicht zwangsläufig eindeutig sind, denn es können durchaus mehrere Tabellen etwa den Schlüsselwert 1 besitzen.

Die einfachste Lösung ist die Verwendung von GUIDs als Primärschlüssel. Diese Werte sind nicht nur über mehrere Tabellen, sondern sogar weltweit eindeutig - sofern sie mit der entsprechenden Systemfunktion erzeugt wurden (weitere Informationen finden Sie in Kapitel 2, Abschnitt 2.6, »Autowerte als Long oder GUID?«).

Selbst das Löschen eines Datensatzes, der aus einer UNION-Abfrage ausgewählt wurde, ist bei Vorhandensein einer GUID einfach: Löschen Sie einfach aus allen beteiligten Tabellen den Datensatz mit der betroffenen GUID - irgendwo werden Sie schon den richtigen treffen und falsche Datensätze löschen Sie damit auch nicht.

Ohne GUID ist die eindeutige Identifikation von Daten aus UNION-Abfragen noch schwieriger. Als Beispiel dient die folgende Abfrage:

SELECT KundeID, Vorname, Nachname FROM tblKunden
UNION
SELECT MitarbeiterID, Vorname, Nachname FROM tblMitarbeiter;

Abbildung 3.17 zeigt auf, was passieren kann: Der Wert 3 kommt in je einem Datensatz der beteiligten Tabellen vor.

Abbildung 3.17: UNION-Abfragen garantieren keinen eindeutigen Index

Um dies zu verhindern, verwenden Sie einen kombinierten Wert aus KundeID beziehungsweise MitarbeiterID und dem jeweiligen Tabellennamen. Die UNION-Abfrage sieht nun so aus:

SELECT 'Kunde' & KundeID AS PersonID, Vorname, Nachname FROM tblKunden
UNION
SELECT 'Mitarbeiter' & MitarbeiterID AS PersonID, Vorname, Nachname FROM tblMitarbeiter;

Das Ergebnis überzeugt ebenfalls, die Datensätze verfügen nun über ein eindeutiges Feld (siehe Abbildung 3.18).

Abbildung 3.18: Eine UNION-Abfrage mit eindeutigem Feld

Gegenüber der Variante mit dem GUID-Wert als Primärschlüssel fällt diese Variante jedoch deutlich ab. Allein das Handling ist wesentlich aufwändiger: Wenn Sie etwa einen mit dieser UNION-Abfrage ausgewählten Datensatz löschen möchten, müssten Sie zunächst über den zusammengesetzten Schlüssel ermitteln, aus welcher Tabelle der Datensatz stammt, und diesen dann dort löschen.

Daraus resultiert letzten Endes die Empfehlung, Daten, die gleich aufgebaut sind, auch in einer einzigen Tabelle zu speichern. Wenn die Daten gelegentlich unterschiedliche Eigenschaften aufweisen und daher unterschiedliche Felder benötigen, lässt sich dies über 1:1-Beziehungen vermutlich leichter realisieren.

Nächster Abschnitt:

3.5.3 INSERT INTO mit UNION-Abfragen

© 2006-2008 André Minhorst Alle Rechte vorbehalten.