OpenOffice.info

Hallo,

danke für Eure Antworten.

Die meisten Daten, die ich zu den Personen erfasse sind eindeutig, zumindest so wie ich das verstehe. Eine Person A kann nur einmal an einem bestimmten Anfänger-Training teilnehmen.

Trotzdem, ich habe Respekt vor Option B), vermute aber, dass sich spätere Anpassungen eventuell leichter machen liessen, zum Beispiel, falls sich doch etwas an den Trainings ändert oder falls ich die Datenbank für andere Abteilungen weitergeben würde.
Muss ich mal sehen, wie ich das alles hinbekomme,
Danke erstmal
Hein

Hallo hein & AhQ,
irgendwann kommt einer und sagt, dies und jenes könnte doch auch noch von der Datenbank erledigt werden z.Bspl. Serienbriefe, Ranglisten,
Beitragslisten, Veranstaltungslisten usw erstellen.
Und schon kommen die Probleme, nämlich Tabellen aufsplitten, neue Tabellen einrichten, mit anderen verknüpfen usw.
Einige Daten sind ins Nirwana entschwunden, da man vergessen hatte mit der DB_Kopie zu arbeiten, der Frust gewinnt
die Oberhand.
Deshalb von Anfang an eine Planung, die es ohne große Veränderungen ermöglicht, die o.g. Beispiele einzufügen. Das geht nur,
mit kleinen Tabellen (wenig Felder) und Verküpfungen.
Da werden viele kleine Tabellen benötigt. Denn evtl vergrößert sich der Verein und es entstehen neue Abteilungen.
[b]Der Vorteil ist, das die Verknüpfungen der Dateien im Fenster ersichtlich sind und Fehler schneller gefunden werden.[/b]
Ein Formular das in die einzelnen Module verzweigt sollte eingeplant werden.

[b]Deshalb halte ich den Plan B für die richtige Entscheidung.[/b]

mfg
Gert

Hallo Hein,

ich würde mir vorher einfach mal überlegen, wieviele unterschiedliche Informationen pro Datensatz und Kategorie es wohl geben wird. Alles, was nur in einer 1:1-Beziehung steht, würde ich in eine große Tabelle werfen (z.B. Adresse, Telefonnummer etc). Alles, wo Du vorher nicht weißt, wieviele Eingaben sich mit der Zeit pro Datensatz ansammeln werden (also 1:n, m:n etc., z.B. wer war auf welchen Veranstaltungen) ist dann besser in einer eigenen Tabelle aufgehoben. Insgesamt bin ich Freund von eher wenigen Tabellen, da ich das insgesamt übersichtlicher finde, es hängt aber letztlich von der Anzahl der Spalten ab, die meine Tabelle absolut hat.

Bei so "kleinen" Geschichten wie einer Kontaktdatenbank o.ä. denke ich, reicht dieses vorgehen, großartige relationale Entwürfe sind da in meinen Augen mehr programmiertechnische Spielerei als wirklich sinnvoll. Wenn das jemand anders sieht, darf er mich aber in diesem Punkt gerne belehren!

Viele Grüße
AhQ

Hallo allerseits,

ich möchte eine Tabelle zur Verwaltung der Mitglieder unserer Kletterergruppe aufbauen.
Ziel ist,
- eine Übersicht über die Qualifikationen der Kletterer
- ein schneller Zugriff auf Kletterer in entsprechenden Kategorien
- evtl die Organisation von Veranstaltungen und die Kontrolle, wer welche Veranstaltungen mitgemacht hat usw.

Mein erster Prototype läuft, obwohl es noch nicht besonders schön ist.

Ich sammel in dieser Datenbank ja sehr viel Infos direkt zu einzelnen Personen, wie z.B.
- ID, Name, Vorname, etc
- Herkunft, Kontakt
- Qualifikationen
- alle Infos zu 3 basistrainings (angemeldet, teilgenommen, Kandidat, Trainer etc)

Frage:
A) Sollte ich diese Informationen alle in einer Tabelle halten?
B) oder Sollte ich diese Informationen lieber auf mehrere verknüpfte Tabellen verteilen?
Option A scheint bisher möglich - aber vielleicht hat Option B) ja irgendwelche Vorteile, die ich noch nicht verstanden habe?

Bedanke mich schon mal für Eure Antworten,
Danke

Hein