Yevgen Reznichenko wrote:
Am 06/12/2003 03:49 PM schrieb Michael Gruetzner:Da hast du zwar recht, doch es ist noch etwas mehr als nur Objekte plattmachen. Das worauf es bei der DB ankommt ist die Beziehung zwischen den Tupeln. Da kann man viel Mist machen. Wir müssen darauf acht geben, dass das DB Model nicht unnötig Komplex zu halten - das bringt auch riesen Probleme bei der Normalisierung.
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.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.
Zum Beispiel? (Es ist nicht so das ich sage das als aller erstes das OO-Model entstehen muss, jedoch Objekte plattzumachen ist meinen Augen nicht schwer)
Ein schlechtes Design kann eine Normalisierung aber unter Umstänen unmöglich machen(ich hab das schon erlebt). Andererseits ist es auch nicht immer klug sämtliche Redundanzen zu vernichten. Es kann durchaus Sinn machen, ein stück zu "denormalisieren" und einige Redundanzen zuzulassen(macht aber nur bei sehr grossen DB's Sinn).Das könnte wiederum zu unnötigen Redundanzen auf der DB führen und
damit eine Normalisierung erschweren.
Durch Normalisierung werden eben Redundanzen beseitigt. Zuerst erstellt man die benötigten Tabellen und dann normalisiert man diese.
Ganz genau! Sobald ich das mit dem Umbrello hingekriegt habe werde ich mich mal um das Glossar kümmern. Wenn das steht(sollte auf der closed area der HP sein) haben wir schon mal einen grossen Schritt geschafft...Wir müssen versuchen, einen mittelweg zwischen OO Design und DB Model zu finden.
Mein Vorschlag kennt ihr. Hier ist die zeitliche Folge, die in meinen Augen sinnvoll ist:
---> ER-Diagramme ---------> norm. Tabellen / | Glossar -> Aktivitätenmodel | \ | ---> Klassendiagramme---
MfG Michael
Und erst dann die Implementierung.
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).
Natürlich sollte man nicht aus dem Auge verlieren dass es irgendwann implementiert werden soll.
MfG Michael
Yevgenij.
--
#define BB_STAT2_TMP_INTR 0x10 /* My Penguins are burning.
Are you able to smell it? */
2.2.16 /usr/src/linux/include/asm-sparc/obio.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)
