Anregung

[Sven Rautenberg]

Moin!

Also es ist besser viele Tabellen anzulegen um Redundanzen zu verhindern. Das erscheint mir auch sinnvoll.

Nicht "viele", sondern nur "mehrere". Das ist durchaus ein Unterschied.

Grundlage ist, dass du zunächst die Art deiner Daten beschreibst. Welche Information ist einmalig im Verhältnis zu anderen Informationen.

Wie ich schon erwähnte: Eine Firma ist eher einmalig, hat aber möglicherweise mehrere Kontaktpersonen. Also bietet es sich an, eine Tabelle für die verschiedenen Firmendaten anzulegen (Name, Adresse, Tel-Durchwahl zur Zentrale), und zusätzlich eine Tabelle mit Kontaktpersonen (Name, Telefon, Fax, Mail, Zuständigkeitsbereich etc.).

Und dann kommt die spannende Frage: Kann eine Person zu einem Zeitpunkt eigentlich für mehrere Firmen die Kontaktperson sein? Theoretisch ja, siehe das Beispiel der Geschäftsführer. Aber kommt das auch praktisch vor? Und wenn es tatsächlich vorkommt: Ist das relevant? Muß es berücksichtigt werden? In welcher Form? Da ist dann die Anforderung der Benutzer gefragt.

Wie gehe ich dann bei der Suche vor. Du sagst die Datenbank findet schon was du suchst.

Die Frage ist dann, was genau du suchst. Wenn du alle Kontaktpersonen mit "Müller" suchst, fragst du logischerweise nur die Personentabelle ab. Das Suchen erledigt hierbei die Datenbank:
SELECT * FROM personentabelle WHERE nachname="Müller"

Das liefert dir nur die Datensätze, die den Nachnamen "Müller" haben.

Wenn du Firmen in Bochum suchst, fragst du logischerweise die Firmentabelle:
SELECT * FROM firmentabelle WHERE ort="Bochum"

Wenn du jetzt aber alle Müllers suchst, deren Firma in Bochum liegt, mußt du die zwei Tabellen verknüpfen - genauer gesagt: Verknüpfen lassen, denn sowas kann die Datenbank selbst am besten und schnellsten.

Dummerweise kenn' ich mich mit MSSQL-Abfragen nun absolut nicht aus, aber das grundlegende Konzept ist bei allen relationalen Datenbanken gleich: Die Firmen haben alle eine eindeutige ID in der Tabelle gespeichert, welche bei den Kontaktpersonen wieder auftaucht. Auf diese Weise kann man feststellen, zu welcher Firma eine Kontaktperson gehört. Und die Verknüpfung beider Tabellen nennt sich "JOIN". Schau in die Doku zu MSSQL, wie man JOINt.

Ergebnis eines JOINs ist jedenfalls eine Gesamttabelle, in der alle oder viele Zeilen der ersten Tabelle mit allen oder vielen Zeilen der zweiten Tabelle verbunden sind. Wenn du eine Firma und drei Kontaktpersonen hast, sieht das z.B. so aus:
Firma1 - Kontakt1
Firma1 - Kontakt2
Firma1 - Kontakt3

In solch einer Tabelle kannst du dann abfragen, welchen Ort die Firma hat, und welchen Namen die Kontaktperson - und kannst auch entsprechend danach suchen - über dieselbe Grundform des SELECT, wie oben auch schon erwähnt.

Wenn ich jetzt die Daten suche muss ich bei vielen Tabellen mich durch jede Spalte ducharbeiten. Also das mit ASP Skripte zu lösen erscheint mir nicht ganz so einfach, oder denke ich da nur zu kompliziert.

Wenn du die Datenbank für dich arbeiten läßt, mußt du dich im Prinzip nur darum kümmern, dass die einmal zu Beginn festgelegten Verknüpfungen genutzt werden. Das ist aber im Prinzip der statische Teil. Variabel ist die Abfrage, welche Datensätze nun eigentlich gemeint sind - also der Teil nach dem WHERE.

MSSQL bietet nach meinen Informationen auch die Möglichkeit, sogenannte VIEWs anzulegen. Das sind fest vorgefertigte Ansichten auf die Datenbank, in denen die Verknüpfungen schon eingebaut sind - aber ohne die Daten dafür noch einmal zu kopieren. Damit kannst du die Angabe der JOINs im Prinzip komplett weglassen und direkt die VIEW-Tabelle abfragen.

Aber wie gesagt: Lies die Dokumentation zur MSSQL-Datenbank.

- Sven Rautenberg