Ref.Integrität,SQL,Tabellen richtig verknüpfen

[Klaus D.]

Hallo
Im Beitrag 'SQL(SUMME)' habt ihr mir sehr geholfen,den Report habe ich erstellt, und alles klappt.
Die Datenbank ist aber für'n Ar...entspricht in keiner Weise irgend eine Normalform.
Ich möchte jetzt die Datenbank neu erstellen(normalisiert) mit ADS.
Die Möglichkeit die Datenbank später im Netz zu betreiben möchte ich offen lasse!!!.
Meine Frage: wie würdet ihr die unten gezeigten Daten(Tabellen) verknüpfen.
Die Tabellen Statisch verknüpfen oder zur Laufzeit.
Datensensitieve Komponenten benutzen oder nicht(in irgend einem Beitrag habe ich mal gelesen,wenn die Datenbank später mal im Netz läuft, ist es besser auf Datenbanksensitieve Komponenten zu verzichten(Netzwerklast)ich brächte die zu editierende Tabelle dann nur zu öffnen, wenn wirklich Daten gespeichert werden.
Soll ich von Anfang an auf die TTables verzichten und gleich mit SQL arbeiten.
Die Tabellen Statisch verknüpfen oder zur Laufzeit.
Es handelt sich um eine kleine Kunden/Rechnungsverwaltung mit die Fürung eines Kassenbuches.
...........

• Tabelle.Kundenstamm
• ID
• Kundendaten,Name,VName...

• Tabelle Rechnungsnummer
• ID
• SID_Kundenstamm(Schüssel=>ID(Kundenstamm))
• Nummer

• Tabelle Rechnung
• ID
• SID_Rechnungsnummer(Schüssel=>ID(Rechnungsnummer))
• Rechnungsdaten,Text,Kosten....

• Tabelle Kassenbuch
• ID
• Text,Einnahmen,Ausgaben....

---------------
Es müssen monatliche Abrechnungen(Kassenbuch)erfolgen, wo alle Einlagen und Ausgaben des abzurechnenden Monats auftauchen,aber zusätzlich müssen die Rechnungen welche BAAAR bezahlt wurde und in der Tabelle Rechnungsnummer steht auch noch berücksichtigt werden.Am Ende habe ich im Kassenbuch ein negatives oder positives Guthaben,welches ich nächsten Monat wieder berücksichtigen muß.
Es soll dann als kleines preiswertes und auf ein minimum beschränkte Kunden,und Rechnungsverwaltungsprogramm+Kassenbuch werden.
Die Tabellenarchitektur ist nur eine Idee von mir, bin noch dabei einen Plan zu erstellen, was ja bekanntlich länger dauert als die eigentliche Programmierarbeit.
Ich hoffe mich verständich ausgedrückt zu haben und freue mich auf eure Beiträge.
MfG...Klaus

[Albi]

Hallo,

also wie die DB-Struktur aussehen soll kann und will ich dir nicht vorschreiben.

Zitat:

Datensensitieve Komponenten benutzen oder nicht

Ich würde auf Datensensitive Kompo so weit wie möglich verzichten. Es ist zwar ein wenig mehr Arbeit, Du bist so aber wesentlich flexibler was die arbeit damit angeht.

Zitat:

Soll ich von Anfang an auf die TTables verzichten und gleich mit SQL arbeiten

Mach es am besten gleich alles mit SQL und lasse die Table-Kompos weg

Um die Datenintigrität zu gewährleisten sollten nach Möglichkeit jeder Bezug (z.B. PLz, Namen usw.) nur einmal in der DB vorkommen und über Fremdschlüssel verknüpft werden.

Ich kenne mich mit ADS zwar nicht aus aber ich versuche immer soviel wie möglich die selber machen zu lassen, da dann Fehler weitesgehend ausgeschlossen sind und das Prog o. Netzwerk nicht unnötig belastet wird. Verknüpfung der Tabellen würde ich zu Laufzeit übernehmen, da die DB ja nicht wissen kann wo was wann und wie rein soll.

[urs.liska]

Wofür ist die Tabelle Rechnungsnummer?
Wenn ich Dein Modell richtig verstehe, ist die Rechnungsnummer Bestandteil der Rechnung. D.h. es gibt für jede Rechnung genau eine Rechnungsnummer (?). Dann sollte die Rechnungsnummer in die Tabelle Rechnung rein. Je nachdem ob Du bestimmte Anforderungen an die Rechnungsnummer hast (fortlaufend, Kombination aus Buchstaben und Zahlen ...) brauchst Du dafür ein extra Feld, ansonsten kannst Du auch gleich die ID der Tabelle dafür benutzen.

Geht es darum, Rechnungen zu erstellen? oder willst Du alle Rechnungen, die Du bezahlt hast, archivieren?

Üblicherweise hat man eine zusätzliche Tabelle Rechnungsdetails, die in der Art

SID_Rechnung(Schüssel=>ID(Rechnung))

verknüpft ist.

Im übrigen sind Deine Schlüssel als Verknüpfung schon richtig (was für eine DB übrigens?)

Wenn der Zweck des ganzen ist, Deine Ausgaben zu verwalten, bräuchtest Du evtl. gar keine Tabelle Kassenbuch, sondern könntest alle erforderlichen Infos aus den Rechnungen bzw. Rechnungsdetails ermitteln.

Viel Erfolg
Urs

[Hasse]

Moin

bei Kundenstamm, gehört eine Kundennummer rein, welche auch eindeutig seien sollte.

[urs.liska]

Zitat von Hasse:

Moin

bei Kundenstamm, gehört eine Kundennummer rein, welche auch eindeutig seien sollte.

Das kann doch die ID sein