Re: Stammdaten
- From: Roland Kruggel <rkruggel@xxxxxxx>
- To: idefix@xxxxxxxxxxxxx
- Date: Wed, 11 Jun 2003 17:13:45 +0200
> > 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?
Der User soll bezgl. der Telnummer, fax, email etc. selbst
definieren was er haben möchte. Wenn er will kann er auch das
Feld Mobilfunk nennen und dan die Mobilfunknummer eintragen.
Kunden kommen manchmal (eigentlich oft) auf die unmöglichsten
Gedanken.
>
> Sonstige
>
> Ist meiner Auffassung nach überflüssig, sollte die vom
> Unternehmen benötigt werden so kann sie dynamisch angelegt
> werden.
Das wäre einen eigenen Thread wert.
Dynamisches anlegen von Kundenspezifischen Feldern. Viel
kompliziert. Ich bin der meinung das wir uns zu anfang auf ein
statisches Datenbankdesign einigen sollten. Dynamische
Erweiterungen können später problemlos eingefügt werden. Aus
sicht der Datenbank gesehen.
>
> > 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.
Wie soll soetwas aussehen?
cu
--
Roland Kruggel mailto: rkruggel@xxxxxxx
System: AMD 1200Mhz, Debian woody, 2.4.20, KDE 3.1
--
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: //www.freelists.org/archives/idefix
Probleme? Mail an mailto:rkruggel@xxxxxxx (deutsch)
Other related posts:
