Re: Stammdaten
- From: Roland Kruggel <rkruggel@xxxxxxx>
- To: idefix@xxxxxxxxxxxxx
- Date: Wed, 11 Jun 2003 18:07:48 +0200
> >>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.
>
> Was ist daran kompliziert? Wo siehst du Schierigkeiten?
Das Anlegen einer dynamischen Datenbank ist nicht das Problem.
Aber logische Verknüpfung mir den Restlichen Tabellen und das
Userinterface. Wei das neue Feld der Tabelle muß ja auch
irgenwie auf dem Bildschirm erscheinen.
>
> > Ich bin der meinung das wir uns zu anfang auf ein
> > statisches Datenbankdesign einigen sollten.
>
> Das finde ich aber nicht so. Wenn ein User in Irak bei dem
> Kunden noch das Feld Religion haben möchte und braucht für
> seine Geschäftstätigkeit, dann soll er das Anlegen können,
> denn sonst kann er mit dem WWS nichts anfangen.
Dieses kann man damit erschlagen indem man ein feld definiert in
dem sowoh der Feldname als auch der Feldinhalt frei definierbar
ist. Feldname und Felduinhalt aus Sicht des GUI. Da kann der
Iraker Dieses Feld nenne ich jetzt 'Religion' und der wert des
Feldes ist 'Moslem'. Das Feld wäre z.b. eine ComboBox deren
Werte aus einer Tabelle kommen, der 'Moslem' kommt in ein ganz
normales Inputfeld.
>
> > Dynamische
> > Erweiterungen können später problemlos eingefügt werden.
>
> Umgekehrt, die Umstellung von einer statischen Struktur auf
> einen dynamische ist sehr sehr schwer und ist sehr schwierigen
> Refactoring verbunden. Das muss von Anfang an bereitgestellt
> werden.
Die Basis der ganzen Datenbank ist aber statisch.
Um das insgesamt dynamisch zu gestalten mußt du aber auch das GUI
dynamisch halten. Das wird aber haarig. Dann kommt da so etwas
wie MS-Access raus. Das ist dynamisch.
> > Aus
> > sicht der Datenbank gesehen.
>
> Weder von dieser noch aus der Sicht des Programms ist es eine
> einfache Umstellung.
Vielleicht reden wir auch aneinander vorbei?
[...]
> >>sollen wir ein ein implementationsunabhängige Glossar
> >>erstellen, aus dem dann später auch die Implementation
> >>abgeleitet werden kann.
> >
> > Wie soll soetwas aussehen?
>
> Z.B.
>
> Def.: Eine Adresse spezifiziert eindeutig eine Lokation auf
> der Erde.
>
> Beschreibung: Jede Adresse gehört zu einer oder mehreren
> Person, die einen Kunden, Lieferanten oder Finanzamt :-)
> repräsintieren könnte.
>
> Bestandteile einer Adresse:
>
> Pflichtfelder:
>
> - Strasse, Hausnummer
> - PLZ
> - Ort
> - Land
>
> "Freiwilige" Felder:
> - Beschreibung
>
> so ähnlich sollte es definiert sein.
Das ist das was ich gerade machen.
Nur schreibe ich das in Form der Datenbankbeschreibung auf. Die
ist jedoch erstmal völlig losgelöst von jedweder
Implementierung. Die sagt lediglich:
- welche Felder werden gebraucht.
- wie sehen diese Daten aus, die da gespeichert werden.
- in welcher relation stehen sie zu anderen Daten.
- was für Mehrfachbeziehungen gibt es unter den Daten. (Eine
Addresse hat mehrere Anschriften)
Wenn die Datenbankstruktur steht, ist der Rest ein Kinderspiel.
Nein Quatsch. :) Aber dann haber wir was womit wir Arbeiten
können, vor allen Dingen kennen wir die Abhängigkeiten der Daten
untereinander
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:
