Re: Stammdaten

Hallo Michael,

Am 06/11/2003 03:36 PM schrieb Michael Gruetzner:
ich habe dazu folgende Idee: man bräuchte für jede der speziefischen Eigenschaften einer Adresse(Kunde, Liferant, etc.) eine Art Container(klasse). Damit kann man die Adressen auf einfache weise klassifizieren und die Adresse somit zum Kundern- oder Lieferantenstamm zuordnen. So liesse sich das auch auf der DB relativ einfach abbilden.

Ich finde es nicht ganz richtig die Implementationdetails jetzt zu besprechen. Ich finde es einfach nicht korrekt die Daten zuerst im Programm zu implementieren und dann einen Äquivalent für die DB zu suchen und vice versa. Wesentlich einfacher wäre zuerst auf einer abstrakten Ebene darüber zu diskutieren was eine Adresse ist und aus welchen Teilen sie besteht. Wenn wir anschliessend zur Implementierung übergehen so leiten wir aus dieser Definition wie diese Adresse implementiert werden soll. (Natürlich werden später alle Adressen durch eine entsprechende Klasse modelliert). Jetzt sollten nur Implementationsdetails insofern besprochen werden in wieweit es unabhängig von der Implementation im Programm und der Abb. auf der DB-Ebene ist. So ungefähr wie du das weiter unten machst.

Des weiteren könnte man noch einen generischen Container Implementieren, damit der Nutzer sich so seine Eigenen Eigenschaften erstellen kann und beliebige Adressen damit verküpfen kann. Eine Adresse gehört dann entweder zu Kunden, Lieferanten oder "Benutzerdefiniert". Ich würde eine Adresse durch folgende Attribute definieren:

    Name
    Vorname

Diese beide Attributen finde ich gehören nicht wirklich zu einer Adresse, sondern zu einer Person. Das Problem sehe ich insbesondere bei nat. und jur. Person, die letzteren haben keinen Vornamen und die ersten *müssen* ein Vornamen haben.

    PLZ
    Ort

Land fehlt.

    Telefonnummern
    Mobilfunkummern
> email Adressen

Ich weiss nicht ob das wirklich zu einer Adresse gehört, was meinen die anderen?

Sonstige

Ist meiner Auffassung nach überflüssig, sollte die vom Unternehmen benötigt werden so kann sie dynamisch angelegt werden.

Beschreibung

Alle Atribute, die mehrfach auftauchen können(z.B. Telefonnummern) werden in eoinem Array/Vector gehalten. Damit kann man praktisch unendlich viele davon einer Adresse zuordnen.

Das sind wieder Implementationsdetails. Was aber fehlt welche Attribute müssen belegt werden und welche können belegt werden. Siehe mein anderes Posting.

Ich hoffe, ihr könnt mir folgen und ich bin nicht völlig auf dem Holzweg.

Ich dir sehr gut folgen und du bist auf gar keinem Fall auf dem Holzweg. Nur ich sehe dass in Java denkst und deine Finger warten auf den Startschuss um das alles reinzuhacken. Das Problem dabei aber ist, dass wenn wir zu Implementationsspezifisch denken so übersehen wir etwas auf einer (Program) oder anderen (DB) Seite. Aus diesem Grund sollen wir ein ein implementationsunabhängige Glossar erstellen, aus dem dann später auch die Implementation abgeleitet werden kann.

MfG
Michael

Yevgen.

Es ging darum dass es muss möglich sein jede beliebige neue Eigenschaft an einen beliebigen vorhandene Stammdatum zu knüpfen. Z.B. "Mobilfunknummer an Kunde" oder "Mobilfunknummer an Adresse" oder "Religion an Lieferant" oder "Bezirk an Adresse" oder "Bundesland an Kunde". Wir können nicht von vorne rein sehen was alles ein Unternehmen an einen Kunden, Liefernten, Adresse oder jedes beliebiges andere Stammdatum knüpfen möchte. Daher müssen wir hier flexiblität und Erweiterbarkeit bitten.

cu



Yevgen.




--
Projekt: Warenwirtschaft. Projektname: Jana
Infos: http://jana.bbf7.de

--------------------------------------------------------------------
Zum AUSTRAGEN schicken Sie eine Mail an idefix-request@xxxxxxxxxxxxx
mit dem Subject "unsubscribe". 
mailto:idefix-request@xxxxxxxxxxxxx?subject=unsubscribe

Mailarchive: http://www.freelists.org/archives/idefix
Probleme? Mail an mailto:rkruggel@xxxxxxx (deutsch)

Other related posts: