Roland Kruggel wrote:
Du meinst ein Feld, dessen Name und Inhalt frei gewählt werden kann?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.
PLZLand fehlt.
Ort
> email AdressenTelefonnummern Mobilfunkummern
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.
Ich bin schon der Meinung, dass man dem Kunden die Möglichkeit geben sollte zusätliche
Sonstige
Ist meiner Auffassung nach überflüssig, sollte die vom Unternehmen benötigt werden so kann sie dynamisch angelegt werden.
Ja, da war ich wohl ein wenig zu voreilig ;-) .
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.
Ich stelle mir das als eine Art Klassendiagramm vor, das zeigt, welche "Entität" welche
Wie soll soetwas aussehen?
MfG Michael
cu
-- 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)
