Re: Stammdaten
- From: Roland Kruggel <rkruggel@xxxxxxx>
- To: idefix@xxxxxxxxxxxxx
- Date: Thu, 12 Jun 2003 16:39:09 +0200
Am Donnerstag Juni 12 2003 15:49 schrieb Michael Gruetzner:
> Yevgen Reznichenko wrote:
> > Am 06/12/2003 11:17 AM schrieb Roland Kruggel:
> >> Ja, das ist richtig. Momentan haben einige so ein paar
> >> Probleme des generellen Verständnisses der
> >> Datenbanken/Tabellen. Aber das kriegen wir auch hin.
> >
> > Weder ich, noch glaube ich Michael, haben Problemen mit den
> > Datenbanken und mit Verständnis von Tabellen. Du siehst die
> > Tabellen in einer DB als das Zentrum der WWS, ich sehe
> > dagegen die DB als eine sehr perfomante und kluge
> > Festplatte. Aber eben nur eine Festplatte! Im Mittelpunkt
> > steht das Programm und dieses Programm speichert ihre Daten
> > in der DB und das ist alles! Du denkst dagegen das man
> > zuerst den DB-Entwurf macht und dann an diesen das Programm
> > anpasst. Auf dieser Weise werden nur die Eingabemasken für
> > die DB erstellt und sich nur darauf zu beschränken habe ich
> > absolut keine Interesse.
>
> Ich finde, wir dürfen das DB auch in dieser frühen
> Planungsphase nicht vernachlässigen. Wenn wir das tun, kann es
> passieren, das wir zwar ein gutes OO Model haben, es sich aber
> schwer auf der DB abbilden lässt. Das könnte wiederum zu
> unnötigen Redundanzen auf der DB führen und damit eine
> Normalisierung erschweren. Wir müssen versuchen, einen
> mittelweg zwischen OO Design und DB Model zu finden.
Ja, Michael. So auch meine Meinung.
Das erste was ja vorliegt sind ja die Daten die irgendwo
verwaltet werden müssen. (datenbank) Das Wie (Programm) kommt
eigentlich doch danach. Natürlich muß das Wo und Wie aufeinander
abgestimmt werden.
Ich kann doch nicht sagen: Ich schreibe jetzt mal ein Programm
und wenn Daten dabei anfallen speicher ist sie mal ab. Ist doch
der falsche Weg. Oder liege ich da so daneben?
>
> > Tabellen sind *plattgemachte* Objekte! D.h. die semantische
> > Information geht verloren, wenn wir nach Tabellen Objekte
> > erzeugen, das muss meiner Meinung nach umgekehrt sein, die
> > Objekte speichern ihre Daten wie es ihnen am besten passt in
> > die Tabelle.
> >
> >> Ob sich da Gegensätz zwischen OO und DB auftuen weis ich
> >> nicht.
>
> Die Erfahrung hat mir gezeigt, dass sehr wohl Konflikte
> zwischen OO und DB entstehen können. Dem kann man aber durch
> umsichtiges Modelieren weitestgehend entgegenwirken(siehe
> oben).
ja.
> > Wir haben hier nicht einfach eine DB sondern eine
> > relationale und keine objektrelationale! D.h. bei Abbildung
> > der Objekten auf die DB gehen hierarchische Beziehungen
> > verloren.
> >
> >> Sehe ich allerdings auch nicht. Es sind halt 'nur' daten
> >> die irgenwie und irgendwo auf einem Datenträger landen
> >> müssen und dort verwaltet werden müssen. Dem Programm
> >> müssen diese Daten ja nur zur Verfügung stehen, wie dieses
> >> Programm dann die daten weiterverarbeitet hat ja direkt
> >> nicht mehr mir der DB zu tun.
> >
> > Ganz genau! Das Programm bringt die Daten in die DB und
> > verarbeite diese intern! D.h. nicht an die DB soll das
> > Programm angepasst werden sondern DB an das Programm.
> >
> >> Meine Premisse ist es jetzt die Datenstrukturen so zu
> >> definieren das keine Felder fehlen, kein doppelte
> >> Datenhaltung vorkommt und die Datenintegrität gewart
> >> bleibt.
> >
> > Und wie möchtest die Beziehungen zwischen den Daten erhalten
> > bleiben?
> >
> >> Ich glaube wenn die Datenbankstruktur mal steht, hat man
> >> 'was in der Hand' worüber man reden/schreiben kann und
> >> worauf man das Programm konkret aufbauen kann.
> >
> > Genau dies ist der Streitpunkt. Wenn man ein Programm
> > schreibt, so entwickelt man nicht zuerst die
> > Konfigurationsdateien, Datendateien usw. und passt dann das
> > Programm an diese an, sondern man entwickelt das Program und
> > sobald man merkt das etwas gespeichert werden muss legt man
> > eine etnsprechende Datei an.
> >
> > Ich möchte aber erneut wiederhollen wir sind noch nicht
> > einmal bei dem Programmentwurf, sondern noch in der
> > *Anforderungsermittlungsphase*! D.h. auch die Diskussion von
> > Implementationsdetails ist jetzt noch überfrüht.
>
> Ich finde, es kann nicht schaden, schon mel einen Blick in
> Richtung Implementetion zu werfen. Nur sollte man es halt
> nicht übertreiben(ich hoffe, ihr versteht was ich meine).
Ja. Verstehe ich. Ist ja auch mein Tenor.
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:
