Re: Stammdaten

  • From: Yevgen Reznichenko <yevgen.r@xxxxxx>
  • To: idefix@xxxxxxxxxxxxx
  • Date: Thu, 12 Jun 2003 03:04:57 +0200

Am 06/11/2003 06:07 PM schrieb Roland Kruggel: 

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.

Es ist zwar etwas schwieriger GUI an dynamische Verhältnisse anzupassen als an die statischen und mag sein es scheint momentan das dynamische Anlegen von Feldern nicht nötig zu sein. Aber momentan entwickeln wir die Businesslogik und die DB und hier ist diese Erweiterung absolut simpel und später schwer änderbar, das hat absolut nicht mit GUI zu tun. Dagegen als GUI möchte man unterschiedliche Clients anbieten und diese können selber entscheiden ob sie die Möglichkeit der dynamischen Erweiterung bitten oder nicht.

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.

Und was ist wenn er zusätzlich zu Religion noch die Wohnungsnummer für die Anschrift braucht (wie in Russland es der Fall ist)? Oder z.B. in Russland besteht das offizielle Name aus drei Teilen (Name, Vorname, Name des Vaters) aus wievielen sie in Irak weiss ich nicht einmal aber bestimmt noch mehr.

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.

MS-Access ist aber eine DB, ich möchte aber keine DB bauen. Und wenn es M$ nicht gelungen ist, warum muss uns der gleiche Schicksal treffen? Wie gesagt, ich betrachte es jetzt von GUI losgelöst. Die Basis muss es unterstützen und wenn GUI es nicht möchte dann braucht sie das auch nicht.

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.

In dieser Form der Beschreibung gehen aber Informationen (symantische Zusammenhänge) verloren, die in dem Programm doch noch abgebildet werden können. Die von uns gewählte DBMS ist eine RDBMS (Relationale DBMS), d.h. sie unterstütz keine OO-Ansätze. Wenn du so modellierst dann hast z.B. zwei Relationen Kundenstamm und Lieferantenstamm, die Information das es sich dabei um zwei Stammdaten handelt die viele gleiche Eigenschaften und Funktionen haben geht verloren. Alle Informationen über Funktionen einzelner Relationen gehen verloren. Daher auch mein Aufruf weder aus der Sicht der DB noch aus der Sicht des Programms modellieren. Zuerst alles umgangsprachlich und verständlich definieren und daraus kann man dann einzelne Relationen und Objekte ableiten.

cu

Yevgenij.

--
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:

  1. Home
  2. idefix
  3. Archive
  4. 06-2003