Datenbankstruktur und Programmstruktur

[Vitali]

Hallo,

wenn ihr ein grosses Projekt plant mir welchen Programmen arbeitet ihr. Mit welchen Programm macht ihr die Datenbankstruktur oder den Programmablauf (Strukturgramm).
Ich habe bis jetzt nur kleine programme geschrieben und habe auf plannung fast verzichtet. Nun habe ich ein grösseres Projekt mit verschieden Datenbanken und um die 20 Tabellen ich muß mir erstmal eine übersicht schaffen.

Wie macht ihr das?

Gruß Vitali

[Frank aus Ulm]

Hi, hallo

wenn ihr ein grosses Projekt plant mir welchen Programmen arbeitet ihr.

Ist das eine Frage? Mit den Programmen, die ich zur Umsetzung des Projektes brauch. Entwicklungsstudio (auch das Notepad) und den Administrationstools für das entsprechende DBMS. Und zum Vorskizzieren/Konzipieren !_Papier und Stift_! Whiteboards, MS Word.

Mit welchen Programm macht ihr die Datenbankstruktur oder den Programmablauf (Strukturgramm).

Fragen werden durch sogenannte Fragezeichen abgeschlossen - nur so zur Info.
Whiteboard, Papier, DBMS-tools, MS Word und Flowchart-Programm (z.b. von Corel) zur Dokumentation.

Ich habe bis jetzt nur kleine programme geschrieben und habe auf plannung fast verzichtet.

Das geht? Hinter allen Tätigkeiten rund um's Programme schreiben steckt eine Planung.

Nun habe ich ein grösseres Projekt mit verschieden Datenbanken und um die 20 Tabellen ich muß mir erstmal eine übersicht schaffen.

Wie, verschiedene Datenbanken? Der Begriff "Datenbank" ist dehnbar wie Kaugummi. Meinst du Datenbanksysteme, Datenbankserver, Datenbankserverinstanzen, Datenbankschemata, ... ? 20 Tabellen nicht nicht wirklich groß.

Eine Übersicht über _was_ verschaffen? Das Projekt ansich? Sicherlich! Am besten große A2 oder A1 Papierblätter nehmen oder n Whiteboard mit bunten Stiften und eine Digitalkamera (zum Abfotografieren).

HTH, Ciao, Frank

[Michael Schröpl]

Hi Vitali,

wenn ihr ein grosses Projekt plant mir welchen Programmen arbeitet ihr. Mit welchen Programm macht ihr die Datenbankstruktur oder den Programmablauf (Strukturgramm).

mit meinem Kopf.

Nun habe ich ein grösseres Projekt mit verschieden Datenbanken und um die 20 Tabellen ich muß mir erstmal eine übersicht schaffen.

20 Tabellen ist in der Tat etwa die Grenze, wo es sich lohnt, ein systematisches Ordnungsschema zu erfinden.

Ich baue gerade etwas, was in Deiner Größenordnung liegt; ich lasse es aber "organisch wachsen", wobei ich mir als Vorgabe ein paar Regeln gegeben habe:
1. Jede Information ist genau einem einzigen Besitzer (Modul) zugeordnet.
2. Jede Datenbanktabelle wird also von einem "Treiber-Modul" eingeschalt; andere Instanzen als dieses Modul wissen nichts von der Existenz der Tabelle. (Das ist natürlich nicht durchhaltbar, wenn Du Tabellen JOINen mußt; ich muß das bisher nicht, ich muß keine großen Informationsmengen extrahieren, sondern im Wesentlichen Operationen innerhalb von Graphen bzw. Bäumen durchführen; ein Teil dieser Tabellen ist vorgegeben, ein anderer Teil von mir hinzugefügt).
3. Code-Duplizierung ist unter allen Umständen zu vermeiden; wenn zwei Anwendungen identischen Code benötigen, dann ist dieser selbst wiederum in ein Modul auszulagern. ("Sehr ähnlicher" Code wird, wo immer möglich, ebenfalls in parametrisierte Modul-Funktionen ausgelagert - das ist eine Frage des Preis/Leistungs-Verhältnisses.)

Ich baue also ein Beziehungsnetz von Objekten, welche Modulen meiner 3GL entsprechen. Die 4GL-Schnittstelle zur Datenbank ist auf der Ebene des jeweiligen Besitzer-Moduls eingeschalt - oberhalb ist nicht mehr sichtbar, daß überhaupt eine Datenbank verwendet wird.
In diesem Universum ist es mir ziemlich egal, ob ich 10 Tabellen habe oder 100 - wichtig ist nur, daß jedes Modul mit der minimalen Information aus anderen Modulen arbeiten kann. Diese "dünnen Kanten" zu erzwingen ist die meiste Arbeit - aber auch die wichtigste Voraussetzung dafür, bei späteren Änderungen des Designs nur sehr lokale Änderungen (ein Modul, oftmals nur eine Zeile!) durchführen zu müssen, wenn sich beispielsweise Formate von Datenbanktabellen ändern müssen.

Der Entwurfsstil bei diesem Projekt ist aber stark von der Natur meiner Tabellen abhängig - das Wissen darum, keine JOINs zu benötigen, hat die Entscheidung zu diesem objektorientierten Ansatz sehr erleichtert.
Es ist nicht die Zahl der Tabellen, welche eine solche Architektur vorgibt - es ist die Struktur der darzustellenden Informationen an sich. Und diese zu verstehen, kann kein Tool der Welt mir abnehmen.

Du suchst nach einem Weg, das optimale Design zu finden - ich beschreibe Dir eine Methode, mir der ich die Folgeschäden eines Designfehlers in Grenzen halten kann, weil der Preis für die Nachbesserung minimal wird. Hilft mein Posting Dir trotzdem?

Viele Grüße
      Michael