Hi,

ich überlege gerade welche Felder in eine Adressen Tabelle rein gehören und welche nicht.

Mein Überlegung war:
ID
Name
Vorname
Geburtstag
Strasse
Haus Nr
PLZ
Ort
eMail (nur vielleicht)
www (nur vielleicht)

Alles andere sollte woanders stehen

Anreden
Titel
weil, später nicht immer das gleiche geschrieben werden soll, und es sollen Rechtschreibfehler verhindert werden.

Weitere Daten wie
Tefon Nr
Fax Nr
Mobil Nr
eMail
www
sollten auch woanders stehen, weil diese mehrfach vorkommen können.

Gibt es das irgendwelche Richtlinien, Erfahrungen, Ideen ?
Ist meine Denkensweise eher Falsch oder eher Richtig ?

Ich möchte jetzt noch keine DatenBank aufbauen. Ich bin noch in der Lehrn- bzw. Planungsphase.
Erst wenn ich glaube genug zu wissen starte ich mit meinem Projekt.

Währe schön wenn ich einiges an Tips bekommen könnte.

lieben dank
Bernd

Name
Vorname
Strasse
Haus Nr
PLZ
Ort
eMail (nur vielleicht)

Die sind meiner meinung nach am Wichtigsten. Ob ID in einer MySQL Datenbank zwingend ist weiss ich jetzt nicht genau

Bernd schrieb:

Hi,

ich überlege gerade welche Felder in eine Adressen Tabelle rein gehören und welche nicht.

Mein Überlegung war:
ID
Name
Vorname
Geburtstag
Strasse
Haus Nr
PLZ
Ort
eMail (nur vielleicht)
www (nur vielleicht)

Alles andere sollte woanders stehen

Anreden
Titel
weil, später nicht immer das gleiche geschrieben werden soll, und es sollen Rechtschreibfehler verhindert werden.

Weitere Daten wie
Tefon Nr
Fax Nr
Mobil Nr
eMail
www
sollten auch woanders stehen, weil diese mehrfach vorkommen können.

Gibt es das irgendwelche Richtlinien, Erfahrungen, Ideen ?
Ist meine Denkensweise eher Falsch oder eher Richtig ?

Ich möchte jetzt noch keine DatenBank aufbauen. Ich bin noch in der Lehrn- bzw. Planungsphase.
Erst wenn ich glaube genug zu wissen starte ich mit meinem Projekt.

Währe schön wenn ich einiges an Tips bekommen könnte.

lieben dank
Bernd

findich gute, datenbänkerische Denkweise.

Anreden und Titel sind übergeordnete Tabellen, auf die aus der AddressTabelle verwiesen werden muß

TelefonNummer ist eine untergeordnete Tabelle - wie du sagst: eine Person kann mehrere haben.

U.U. ist TelefonNummer auch nicht untergeordnet, sondern im Person-Datensatz wird gleich unterschieden zw. privat, geschäftlich, Handy.
Ist deine Entscheidung - mit der untergeordneten Tabelle ists aufwändiger, aber dafür kannste damit auch "Telefon-WennBeiFreundin übernachtet", zweites und drittes Handy (hatmanjaheutzutage ;)) und sowas aufnehmen, wenn dir das erforderlich erscheint.

Aber meinst du wirklich, einer hat mehrere WebSites, mehrere Faxnummern, mehrere Emails (gibts schon, aber brauchst du die alle, und willst du wirklich die Leuts so umfassend ausfragen?)

Wassichnoch empfehle: Entwickel erstmal ohne DB, nur mit Dataset. Damit kannst du bereits ein komplettes Datenmodell modellieren, und wenn die Anwendung mittm Dataset testmäßig hinhaut - also dein Datenmodell steht - dann erst die DB aufsetzen und hinterlegen. Gugge DB-Programmierung ohne Datenbank

Dassis einfacher, als bei jeder Änderung am Datenmodell immer gleich DB, Dataset und anwendung überarbeiten zu müssen.

Annere Überlegungen wären: Strasse + Hausnummer in ein Feld,
vlt. PLZ und Ort als übergeordnete Tabelle, wenn mehr oder weniger viele Personen aus derselben Ecke kommen.

Hi,

Ein paar Gedanken:

- wenn Anreden und Titel in einer Extra Tabelle sind, muss aber aus dem Adressdatensatz selbst, ein Verweis daruf zeigen.
- prinzipiell ist die Variante, die Kommuniktionsdaten (Tel, EMail, etc.) in eine andere Tabelle auszulagern deutlich flexibler, als starre Vorgaben zu machen wie Handy, Handy privat, usw.
- je nachdem was für Adressen erfasst werden sollen, empfiehlt es sich mehrere Namesfelder anzulegen (zB. bei Firmenamschriften braucht, man schon mal mehrere Zeilen für den Namen)


bye ...

LaMa5.

ErfinderDesRades schrieb:

Wassichnoch empfehle: Entwickel erstmal ohne DB, nur mit Dataset. Damit kannst du bereits ein komplettes Datenmodell modellieren, und wenn die Anwendung mittm Dataset testmäßig hinhaut - also dein Datenmodell steht - dann erst die DB aufsetzen und hinterlegen. Gugge DB-Programmierung ohne Datenbank

Wieder was neues.
Wenn ich dir folgen kann,
erst das DataSet und später kann ich die MySql Tabellen anbinden ?
Cool.

Danke auch den anderen.Ich werde all eure Hinweise war nehmen.

Ich freue mich selbstverständlich über weitere Tips.
lieben dank
Bernd

Ich gehe davon aus, dass kein Konzern abgebildet werden soll, wo Standortdaten, Abteilungsdaten und Hierarchiedaten ebenfalls mit abgebildet werden sollen.
In dem Fall müsstest du die Adressdaten ebenfalls in eine eigene Tabelle auslagern, damit bei einem Standortwechsel nur ein Key gewechselt werden muss.

Noch nicht genannt wurden Regionaldaten (Land, Bundesland, Landkreis)
Wenn du international unterwegs bist, musst du diese Bezeichnungen ggf. noch variabel gestalten.
Die Landesvorwahl/Ortsvorwahl kann aus der Regionalbezeichnung gewonnen werden und hat ggf. Einfluss auf die Telefonnummer.
Ob du wirklich so granular designen willst, musst du selber wissen.

Kommunikationsdaten in eine eigene Tabelle wurde schon erwähnt.
Hier bietet sich eine N:M-Zuordnung an.
PersID (Fremdschlüssel aus Personen-DB)
ComGroupID (Fremdschlüssel aus Tabelle Kommunikationsgruppe) - Phone, Mail, WebSite...
ComTyp (String) "eMail privat", "eMAil Firma", "Handy privat"... (hier kann sich der Benutzer austoben mit freien Bezeichnungen)
ComData (String) die Nummer oder Adresse

Ansonsten gibt's noch ein paar Daten, die von der Verwendung deiner DB abhängen
Beruf, Dienstgrad (ggf. als Fremdschlüssel)
Beziehungen stellst du mit Fremdschlüssel auf andere Personen dar (Stellvertreter, Chef, Bruder, Schwester, Freund) am Besten auch in einer getrennten N:M-Tabelle.

Je nachdem, was bei dir alles vorkommen kann, kannst du dich hier bis zum Orgasmus ausleben.
Alles, was standardisiert dargestellt werden soll, in eine eigene Typtabelle und nur den Fremdschlüssel dazu in die Haupt-Tabelle.
Alles was mehrfach vorkommen kann, in eine N:M-Tabelle.

Spezifische Felder hängen von der Anwendung ab.
Bei einem Verein vielleicht noch ein Fremdschlüssel auf die Beitragsgruppe (Ehrenmitglied, ordentliches Mitglied, aktives Mitglied, stilles Mitglied...)
Wenn du eine Musikverein-DB machst, benötigst du vielleicht die Instrumente, beim Sportverein die Sportarten.

Gerne vergessen wird Start- und Ende-Datum (Eintritt, Austritt/Beitrag bezahlt bis)
Kündigungsgrund (oder Austrittsgrund) fällt mir noch ein.

Generell:
Ein Invalid-Flag, mit dem du den Datensatz als gelöscht markieren kannst (weil er z.B. durch einen anderen Datensatz ersetzt wurde).
Ein echtes Löschen des Records ist in einer Datenbank fast immer ein absolutes Tabu.

Und noch ein paar Daten zum Record selbst:
CreatedDate
CreatedBy
ModifiedDate
ModifiedBy

Wenn ich noch eine Weile nachdenke, fallen mir bestimmt noch mehr Dinge ein.
Wichtig ist, dass du dir selbst Gedanken machst, was alles vorkommen kann.

Super,

ja so einige Dinger die du genannt hast habe ich auch im Kopf.
Wer hat die Daten geändert oder angelegt und wann.
Über das Thema rattert meine Birne seit Tage.
Nur habe ich noch keine Ahnung wie ich das in Verbindung bringen soll.
Dann müsste ich eine Art Anmelde System schreiben.
Wer darf sich anmelden.
Wer darf welche Daten sehen
Wer darf Daten ändern
Wer darf Daten löschen (wenn überhaupt, ist nicht so klever)

Aber ich arbeite dran.

Weitere Tabellen die ich noch im Kopf habe,
Verein(e)
Berechtigungen

Typische Mitglieder Daten
Eintritt
Austritt
Position im Verein, Übungsleiter, Vorstand, Kassenwart ...
Mitglieder Beiträge
Gruppen (Sportangebote)
Kurse(Prävention, Rehabilitation, Fun, Motorisches Ungleichgewicht ...
...

Mein Güte da habe ich mir was vorgenommen.

auch dir lieben dank für deine Unterstützung

ModifiedBy muss nicht unbedingt einen Benutzernamen beinhalten.
Das kann auch der Name eines Programmmoduls sein, das die Daten verändert hat.
Wenn die Datenbank lange genug lebt, kannst du in diesem Feld nachvollziehen, wie dieser Datensatz entstanden ist.
Alternativ kannst du auch ein Feld Herkunft verwenden.

Dann wirst du das Ganze vielleicht verbinden wollen mit einem Modul Zahlungsverkehr, wo du dir die Kontoauszüge vom Internetbanking reinlädst und eine automatisches Beitragsmahnverfahren damit lostrittst.

Sponsorenverwaltung ist auch noch ein interessanter Ansatzpunkt.
Und wenn dann ein Sponsor gleichzeitig auch Mitglied ist, kommst du in den Gewissenskonflikt, ob du die Katze sich in den Schwanz beißen lässt oder ob du die Daten doppelt hältst.

Ansatzpunkte für Erweiterungen wirst du auch nächstes Jahr noch haben.

Auf jeden Fall ist so ein Projekt eine gute Methode, um etwas über Datenbanken zu lernen.
Viel Spaß und viel Erfolg damit!