Datenbanken Grundsatzfrage

Guten morgen liebe Leute,

hat wer von Euch Erfahrungen mit Datenbanken (Access) - und zwar mit den Grundlagen wie eine DB aufgesetzt wird. ??

Ich hab mir Access selbst beigebracht (Bücher) und hab mir so meine eigenen Gedanken dazu gemacht - und jetzt hab ich von meiner Firma eine Schulung bekommen und bin bezgl. der Grundlagen etwas verwirrt. (Die Vortragende lehrt zwar Access erstellt aber keine echten DBs daher meine Hoffnung, daß mein "Weltbild " doch nicht so falsch ist.)

Folgende Ausgangssituation: Eine Tabelle mit Personen (Vorname, Zuname, Adresse, etc.). Diese Tabelle wird dann halt weiter verwendet...

Und jetzt meine Frage: Die Tabelle soll einen Primärschlüssel (PS)erhalten.

ICH hätte den PS über so viele Felder gelegt wie möglich/sinvoll um die Person eindeutig zu erfassen also Name, Adr, Geb. Datum. - somit kann eine Person nur einmal in der DB vorkommen.

Die Vortragende sagt: Die Tabelle um einen AutoWert ergänzen und der (nur der) ist der PS. Somit kann keine Situation entstehen in der eine Eingabe nicht mehr möglich ist weil halt doch zwei gleiche Personen wirklich existieren (Senior, junior an gl. Adr.)

Meine Antwort : Diese Situation wird abgefangen über Geb. Datum.

Ihre Schlußargument; Die DB muß flexibel bleiben um immer eine Eingabe annehmen zu können und der User muß die Disziplin haben Personen nur einmal anzulegen.

Mein SChlußargument: mit allen "Maßnahmen" verhindern, daß doppelte Einträge passieren können.

WER weiß Rat.

? Hat wer eine guten Seite im Netz wo solche DB Grundlagen erörtert werden ?

danke und schönen Tag noch

Michael

Du vermischt!

Eine DB ist eine DB und braucht einen PS. Die Dublettenproblematik hat nix mit dem PS zu tun.

Eine DB ist eine DB und braucht einen PS. Die Dublettenproblematik hat nix mit dem PS zu tun.

Bist sicher?

Sehr vereinfacht ausgedrückt:

Der "Wert" eines Primärschlüssel darf in einer Tabelle nicht 2x vorkommen. Also wenns 2 Max Mustermann 1.1.1954 gibt, dann hast ein Problem.

Man könnte eine ID einführen, so wie es der Vortragende gemeint hat, wird aber von manchen Leuten als unschön betrachtet.

Oder man findet eine "Spalte", die eindeutig ist, bspw. Sozialversicherungsnummer.

Mehr dazu (und auch ein hilfreiches Bsp für dich) gibts auf Wikipedia. -> http://de.wikipedia.org/wiki/Primärschlüssel (ist aber etwas formal "akademisch" angehaucht.

Es ist häufig empfehlenswert einen Primary Key, der ein Autoincrement-Wert ist, zu verwenden, da:

- Abfragen dadurch einfacher werden (z.B. tab1.ID = tab2.fID)

- Abfragen dadurch schneller werden (nur Integer vergleich).

@Austrianbiker: Du als Informatikstudent gehst halt von einer perfekten Welt aus.

Ich sage dir aber (als reiner Praxistyp) in JEDER DB gibt es hundert und ein, was sag ich tausend und ein, Dubletten. Sogar in den ganz superguten! Und da brauchst du eine ID.

Dass nebenbei Dubletten bereinigt werden müssen ist ein ganz anderes Problem. Aber beim Eingang der Daten schon zu prüfen ist oft ein mühseliges Unterfangen, weil die Daten oft schnell rein müssen. Also eine ID anlegen und die Welt passt wieder.

Zumindest so lange, bis einem die Dubletten über den Kopf wachsen. Aber das ist eine andere Geschichte.

:devil:

also was jetzt ??

Dubletten zulassen und nachher / im Hintergrund bereinigen oder gleich vom Anfang weg erkennen und verweigern ???

Michael

Ich sags ja.

Es ist eine philosphische Frage, was besser ist. Kommt darauf an, wie die Workflows sonst laufen:

Workflow: Datenbanken die "jeder" bedienen können muß - also schlampige User....

Michael

Deine Vortragende hat Recht

Wenn der Key nicht "von sich aus" wirklich eindeutig ist auf alle Fälle einen künstlichen (z.B. Autoincrement) Key verwenden.

Ich hab schon genug Fälle erlebt, wo sich eine als "ganz sicher eindeutige" Kombination von Felder auf einmal als doch nicht so ganz eindeutig herausgestellt hat....