Yevgen Reznichenko wrote:
Am 06/12/2003 11:17 AM schrieb Roland Kruggel: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, 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.
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.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).
Ob sich da Gegensätz zwischen OO und DB auftuen weis ich nicht.
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).
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.
MfG Michael
cu
Yevgenij.
--
/* Fuck. The f-word is here so you can grep for it :-) */
2.4.3 linux/include/asm-mips/mmu_context.h-- 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)
