Ertellen und Beziehungen zwischen Tabellen

[zinar Sozdar]

Hallo Luete,

ich möchte unter VB6 ein Kassenbuch Programm erstellen.Um die
Kundeninformationen zu speichern, habe Tabelle 1 und für die Einnahmen
und Ausgaben habe Tabelle 2

Tabelle 1

ID | Kunde | Adresse | Tel | Fax | Datum | Anf.Bestand
----------------------------------------------------------------------------------


Tabelle 2

ID | Datum | Einnahmen | Ausgaben | Text | Bestand
----------------------------------------------------------------------------------


In Tabelle 1 werden Kunden-Daten gespeichert.(Adresse Tel. usw.)
in Tabelle 2 werden Einnahmen und Ausgaben für z.B Januar gespeichert.
Ich mochte aber so Programieren dass die z.B
Daten von 2007-->Januar, 2007-->Febr......usw
Daten von 2008-->Januar, 2008-->Febr..... usw.
.
.
Kann einer mir schreiben wie ich das realisieren kann? Brauche ich
vielleicht noch zwei Tabellen
z.b Jahr und Monat und die verknüpfen?
Für jede Hinweiss wäre ich sehr dankbar

Vielen Dank.
Zinar

[Stefan Dase]

Hallo Zinar!

Post by zinar Sozdar
In Tabelle 1 werden Kunden-Daten gespeichert.(Adresse Tel. usw.)
in Tabelle 2 werden Einnahmen und Ausgaben für z.B Januar gespeichert.
Ich mochte aber so Programieren dass die z.B
Daten von 2007-->Januar, 2007-->Febr......usw
Daten von 2008-->Januar, 2008-->Febr..... usw.

Um Einnahmen und Ausgaben für einen bestimmten Monat zusammen zu fassen
reicht die Angabe des Datums in der Tabelle. Über Queries/Views kannst
du dann die gewünschten Datensätze erhalten, indem du den Monat als
Filterkriterium angibst. Also für Januar wäre das z.B. alles vom
01.01.2007 bis 31.01.2007. Allerdings solltest du evtl. existierende
Vorgaben durch gesetzliche Bestimmungen und Kundenanforderungen dabei
berücksichtigen!

Post by zinar Sozdar
Tabelle 2
ID | Datum | Einnahmen | Ausgaben | Text | Bestand

In deiner "Tabelle 2" fällt mir auf, dass du ein Feld "Bestand"
verwendest. Willst du hier einen Kontostand speichern? Diesen kannst du
auch jederzeit berechnen. Bei Änderungen müsstest du den entsprechenden
und alle folgenden Datensätze ändern. Daher empfehle ich dir, diesen
Wert nicht abzuspeichern, sondern jeweils zur Laufzeit zu ermitteln.
Ggf. kann man nach einer Jahresabrechnung den "Bestand" des Vorjahres
als Ausgangswert abspeichern und von da an berechnen.

Ansonsten schau dir mal Normalisierungsregeln für Datenbanken an. Eine
Möglichkeit findest du unter http://www.donkarl.com?FAQ1.31

HTH,
Stefan

[zinar Sozdar]

Hallo Stefan,
erstmal vielen dank für deine Hilfe und Empfehlung.

Um Einnahmen und Ausgaben für einen bestimmten Monat zusammen zu
fassen

Post by Stefan Dase
reicht die Angabe des Datums in der Tabelle. Über Queries/Views kannst
du dann die gewünschten Datensätze erhalten, indem du den Monat als
Filterkriterium angibst.

Du hast Recht, daran habe nicht gedacht.(Anfänger Fehler)

Eine Frage habe ich aber noch...
Meinnst Du dass zwei Tabellen reichen? dass ich die Daten von 2 oder 3
(können auch 10 sein) in Tabelle 2 abspeichern soll und mit SQL
abfrage?
Bei mir stehen die Tabellen mit der Beziehung Tabelle 1 1--->n
Tabelle 2
Wie ich mir gedacht habe könnte ich noch 3 Tabelle gebrauchen aber ich
weiss nicht wie sie miteinander verknüpft werden sollen?

[Stefan Dase]

Hallo Zinar,

Post by zinar Sozdar
Eine Frage habe ich aber noch...
Meinnst Du dass zwei Tabellen reichen? dass ich die Daten von 2 oder 3
(können auch 10 sein) in Tabelle 2 abspeichern soll und mit SQL
abfrage?
Bei mir stehen die Tabellen mit der Beziehung Tabelle 1 1--->n
Tabelle 2

Nach den vorliegenden Informationen würden zwei Tabellen reichen.
Allerdings weiß ich auch nicht, was du im Endeffekt erreichen willst
bzw. was die Anforderungen sind.

Viele Grüße aus Bremen,
Stefan

[Wolfgang Wolf]

Hallo Stefan, Hallo Zinar

Ggf. kann man nach einer Jahresabrechnung den "Bestand" des Vorjahres als Ausgangswert abspeichern und von da an berechnen.
Ansonsten schau dir mal Normalisierungsregeln für Datenbanken an. Eine Möglichkeit findest du unter http://www.donkarl.com?FAQ1.31

Bei den Größenverhältnissen die Zinar vermutlich
anstrebt, sind diese gespeicherten "Jahresabrechnungen"
nicht erforderlich, ja sogar schädlich weil sie eben
den Normalisierungsregeln widersprechen. Eine intelligent
aufgebaute Datenbank, die Indizes an der richtigen Stelle
verwendet, braucht so was nicht. Zinar wird wohl kaum
für die Buchhaltung eines Automobilherstellers die Anwendung
schreiben, insofern ist die Anzahl der anfallenden Buchungen
sicher überschaubar. Nehmen wir mal an er hat pro Tag 50
Buchungen. 50 * 250 Arbeitstage = 12.500 Buchungen / Jahr.
In 10 Jahren sind das 120.500 Buchungen. Bei dieser Anzahl
von Datensätzen benötigt Access gerade mal ein Augenzwinkern
für folgende Abfrage:
"SELECT Sum(Buchung) AS Summe FROM Buchungen"
Schon hat er den aktuellen Kontostand.

Nicht spürbar länger dauert die Abfrage:
"SELECT Jahr, Sum(Buchung) AS Summe FROM Buchungen
GROUP BY Jahr"
Das wäre dann die Jahresauswertung.

Eine Gruppierung nach Kundennummer sieht änlich aus.

Also Zinar, lese dich richtig in die Normalisierung ein.
Lege größten Wert auf die Einhaltung der Regeln. Bevor
Du Entscheidungen triffst die auf Annahmen basieren,
("ich brauche Zwischensummen, sonst werden die Abfragen
zu langsam") teste das Ganze lieber. Für den obigen Test
schreibst Du dir ein kleines Modul in Access:

Public Sub Main()
Dim db As DAO.Database
Dim rs As DAO.Recordset

Set db = CurrentDb
Set rs = db.OpenRecordset("Buchungen", dbOpenTable)

dim i As Long
dim b as double

For i = 0 To 120500
rs.AddNew
b = Rnd(CDbl(Now)) * 1000
rs!Buchung= b
rs!jahr = clng("200" & Left$(cstr(b),1))
rs!kdnr = clng(Right$(cstr(b),1))
rs.Update
Next i
End Sub

Nach einer Espresso-Pause hast Du Daten zum Testen.
Achte darauf dass in der Tabelle das Feld Jahr und
die Kundennummer einen Index haben und lasse die
o. g. Abfragen in VB laufen.

Gruß
W. Wolf

[Frank Müller]

Hallo Zinar,

Post by zinar Sozdar
Hallo Luete,
ich möchte unter VB6 ein Kassenbuch Programm erstellen.Um die
Kundeninformationen zu speichern, habe Tabelle 1 und für die Einnahmen
und Ausgaben habe Tabelle 2
Tabelle 1
ID | Kunde | Adresse | Tel | Fax | Datum | Anf.Bestand
--------------------------------------------------------------------------

--------

Was soll hier in den Feldern Datum und Anf.Bestand gespeichert werden?
Da würde ich eine eindeutige Kundennummer vergeben im Programm
und diese in der anderen Tabelle bei Bedarf verwenden.

Post by zinar Sozdar
Tabelle 2
ID | Datum | Einnahmen | Ausgaben | Text | Bestand
--------------------------------------------------------------------------

--------

Post by zinar Sozdar
In Tabelle 1 werden Kunden-Daten gespeichert.(Adresse Tel. usw.)
in Tabelle 2 werden Einnahmen und Ausgaben für z.B Januar gespeichert.

Das sind also die Bewegungsdaten der Kasse.
Hier ist es nicht unbedingt notwendig die Einnahmen / Ausgaben
in zwei Feldern zu speichern, denn worum es sich handelt ergibt
sich aus dem Vorzeichen des Betrags. (Ausgabe = negative Einnahme)

Das Feld Bestand (Kassenbestand?) ist hier nicht notwendig da sich
dieser mit jedem Datensatz ändert und jederzeit ermittelt werden kann.

Wenn du den Bezug zu den Kunden aus der anderen Tabelle bzw.
zu Gründen von Einnahmen und Ausgaben herstellen möchtest, fehlt
in dieser Tabelle noch ein Feld wo der Grund vermerkt werden kann.
(Beispielsweise die Kundennummer des Kunden)

Post by zinar Sozdar
Ich mochte aber so Programieren dass die z.B
Daten von 2007-->Januar, 2007-->Febr......usw
Daten von 2008-->Januar, 2008-->Febr..... usw.

Ds ist nicht sinnvoll da für jeden Monat bzw. jedes Jahr
eine eigene Tabelle anzulegen. Da das Datum ja erfasst wird,
kannst du jederzeit Salden über beliebige Zeiträume per Abfrage
ermitteln und in deinem Programm ausgeben lassen.

Post by zinar Sozdar
Kann einer mir schreiben wie ich das realisieren kann? Brauche ich
vielleicht noch zwei Tabellen
z.b Jahr und Monat und die verknüpfen?

Nein, was du bräuchtest ist eine oder mehrere weitere Tabellen
für die Daten die sich selten oder gar nicht ändern bzw. nicht
für jede Kassenbewegung in dieser Tabelle vollständig gespeichert
werden sollten.

Also z.b. eine Tabelle für die Kunden (mit eindeutiger Kundennummer)
Eine Tabelle für die "Gründe" der Einnahmen / Ausgaben. Eine Bewegung
in einer Kasse muß ja nicht unbedingt etwas mit Kunden zu tun haben das
kann alles mögliche sein.

Schildere doch mal etwas genauer was du überhaupt machen möchtest bzw.
was dein Kassenbuch überhaupt können soll. Nur dann kann man konkret
etwas dazu sagen. (Wenn das gewerblich genutzt werden soll, dann sind
da nämlich noch ein paar Sachen mehr zu beachten als nur Tabellenaufbau)

Gruß,
Frank

[Wolfgang Wolf]

Hallo Frank,

Post by Frank Müller
Das sind also die Bewegungsdaten der Kasse.
Hier ist es nicht unbedingt notwendig die Einnahmen / Ausgaben
in zwei Feldern zu speichern, denn worum es sich handelt ergibt
sich aus dem Vorzeichen des Betrags. (Ausgabe = negative Einnahme)

Definiere in diesem Zusammenhang die Gutschrift ;-)
Nein, zwei Tabellen für Ausgaben / Einnahmen braucht Zinar
wirklich nicht, aber der von Dir empfohlene Buchungsgrund
sollte es schon sein. Ausgabe / Einnahme nur über das
Vorzeichen zu definieren, wäre mir doch zu wenig. Daraus
ergibt sich, der Normalisierung folgend, die dritte Tabelle.
Da stimme ich dir zu 100% zu.

Von Kunden sprechen wir im allgemeinen im geschäftlichem
Umfeld. Also benötigen wir noch höchstwahrscheinlich die
Tabelle mit den Steuersätzen. Wer sich so weit vorwagt
bekommt dann auch zu spüren was es bedeutet wenn Entscheidungsträger
von der Datenbankmaterie keine Ahnung haben. Beispiel:

im Zuge der Umsatzsteuererhöhung wurden die Datev-Steuerschlüssel
neu zugeordnet:
Umsatzsteuer alt: 3=16% neu: 3=19%
Umsatzsteuer alt: 5=15% neu: 5=16%
Vorsteuer alt: 7=15% neu: 7=16%
Vorsteuer alt: 9=16% neu: 9=19%

Wer seine Steuersätze in einer Tabelle schön sauber gepflegt
hat, gem. der Normalisierung im Kassenbuch also lediglich
den Netto-Wert mit Steuerschlüssel hinterlegt hat,
schaut nun in die Röhre. :-)


Gruß
W. Wolf

[Stefan Dase]

Hallo Wolfgang,

Post by Wolfgang Wolf
(...)
Wer seine Steuersätze in einer Tabelle schön sauber gepflegt
hat, gem. der Normalisierung im Kassenbuch also lediglich
den Netto-Wert mit Steuerschlüssel hinterlegt hat,
schaut nun in die Röhre. :-)

Nicht, wenn man korrekterweise die Gültigkeit mit angegeben hat oder die
Steuer nur als Referenz pflegt. :-)

Viele Grüße aus Bremen,
Stefan

[Wolfgang Wolf]

Hallo Stefan

Post by Wolfgang Wolf
(...)
Wer seine Steuersätze in einer Tabelle schön sauber gepflegt
hat, gem. der Normalisierung im Kassenbuch also lediglich
den Netto-Wert mit Steuerschlüssel hinterlegt hat,
schaut nun in die Röhre. :-)

Nicht, wenn man korrekterweise die Gültigkeit mit angegeben hat oder die Steuer nur als Referenz pflegt. :-)

bitte noch mal meinen Text genau lesen! Das Problem
hat man eben dann wenn man mit Referenzen
arbeitet. Die Steuerschlüssel sind nun mal vorgegeben.
Wer den Steuersatz unsauber als Wert direkt in das
Kassenbuch geschrieben hat, dem kann es ja egal
sein, ab 01.01.07 schreibt er hier statt 16 eine 19.
Wer jedoch korrekterweise die Steuerschlüssel extern
pflegt und im Kassenbuch eine Referenz verwendet, hat
durch die neuen Regelungen das von mir beschriebene
Problem.

Gruß W. Wolf

[Peter Fleischer]

Post by Wolfgang Wolf

Post by Stefan Dase

Post by Wolfgang Wolf
Wer seine Steuersätze in einer Tabelle schön sauber gepflegt
hat, gem. der Normalisierung im Kassenbuch also lediglich
den Netto-Wert mit Steuerschlüssel hinterlegt hat,
schaut nun in die Röhre. :-)

Nicht, wenn man korrekterweise die Gültigkeit mit angegeben hat oder
die Steuer nur als Referenz pflegt. :-)

bitte noch mal meinen Text genau lesen! Das Problem
hat man eben dann wenn man mit Referenzen
arbeitet.

Hi Wolfgang,
das stimmt nicht, wenn man es richtig macht.

Post by Wolfgang Wolf
Die Steuerschlüssel sind nun mal vorgegeben.

Niemand gibt die Identifikatoren für einen Datensatz in einer Datenbank vor.
Wenn als Identifikator aber fremde Vorgaben genutzt werden, dann hast du ein
Problem. Nur wer, der sich mit Datenbanken auskennt, machst das schon

Post by Wolfgang Wolf
Wer den Steuersatz unsauber als Wert direkt in das
Kassenbuch geschrieben hat, dem kann es ja egal
sein, ab 01.01.07 schreibt er hier statt 16 eine 19.

Das hat aber wenig mit Normalisierung zu tun.

Post by Wolfgang Wolf
Wer jedoch korrekterweise die Steuerschlüssel extern
pflegt und im Kassenbuch eine Referenz verwendet, hat
durch die neuen Regelungen das von mir beschriebene
Problem.

NEIN. Das Problem hat er nur, wenn er nicht sauber normalisiert, d.h. wenn
er für die Beziehung nicht den Satzidentifikator nimmt, sondern eine
externen Wert, deren Bedeutung zeitabhängig ist. In diesem Fall müsste die
Zeitabhängigkeit mit in die Beziehung eingeschlossen werden, was den
Normalisierungszielen entgegen wirkt.

[Wolfgang Wolf]

Hallo Peter,
"Peter Fleischer" <***@gmx.de> schrieb

[...]

NEIN. Das Problem hat er nur, wenn er nicht sauber normalisiert, d.h. wenn er für die Beziehung nicht den Satzidentifikator nimmt,
sondern eine externen Wert, deren Bedeutung zeitabhängig ist. In diesem Fall müsste die Zeitabhängigkeit mit in die Beziehung
eingeschlossen werden, was den Normalisierungszielen entgegen wirkt.

Hast schon recht! Ich habe wohl Stefans Satz falsch verstanden.
Mit: "Nicht, wenn man korrekterweise die Gültigkeit mit angegeben
hat oder die Steuer nur als Referenz pflegt." dachte ich dass er
sich mit "Steuer als Referenz" auf den Datev-Schlüssel bezieht.
Vermutlich hat er aber auch einen eigenen Schlüssel gemeint und
die Referenz im Kassenbuch zeigt auf diesen Schlüssel.

Eines sollte Zinar jetzt aber nach dieser Diskussion klar sein:
richtiges Planen ist wohl das A und O. :-)


Gruß
W. Wolf


Gruß
W. Wolf

[Ralf Brostedt]

Post by Wolfgang Wolf
im Zuge der Umsatzsteuererhöhung wurden die Datev-Steuerschlüssel
Umsatzsteuer alt: 3=16% neu: 3=19%
Umsatzsteuer alt: 5=15% neu: 5=16%
Vorsteuer alt: 7=15% neu: 7=16%
Vorsteuer alt: 9=16% neu: 9=19%
Wer seine Steuersätze in einer Tabelle schön sauber gepflegt
hat, gem. der Normalisierung im Kassenbuch also lediglich
den Netto-Wert mit Steuerschlüssel hinterlegt hat,
schaut nun in die Röhre. :-)

Wer macht denn so etwas? Ist es nicht eher so, dass diese Stammdaten
unveränderlich bleiben und einfach ein neuer Schlüssel (respektive ein
neuer Datensatz) für den neuen Mehrwerststeuersatz angelegt wird, der
dann als neuer Default-Wert für Produkte mit vollem Mehrwertsteuersatz
definiert wird?

So würde ich das zumindest machen, aber ich bin auch nur
Softwareentwickler, kein Kaufmann.

[Peter Fleischer]

Post by Ralf Brostedt

Post by Wolfgang Wolf
im Zuge der Umsatzsteuererhöhung wurden die Datev-Steuerschlüssel
Umsatzsteuer alt: 3=16% neu: 3=19%
Umsatzsteuer alt: 5=15% neu: 5=16%
Vorsteuer alt: 7=15% neu: 7=16%
Vorsteuer alt: 9=16% neu: 9=19%
Wer seine Steuersätze in einer Tabelle schön sauber gepflegt
hat, gem. der Normalisierung im Kassenbuch also lediglich
den Netto-Wert mit Steuerschlüssel hinterlegt hat,
schaut nun in die Röhre. :-)

Wer macht denn so etwas? Ist es nicht eher so, dass diese Stammdaten
unveränderlich bleiben und einfach ein neuer Schlüssel (respektive ein
neuer Datensatz) für den neuen Mehrwerststeuersatz angelegt wird, der
dann als neuer Default-Wert für Produkte mit vollem Mehrwertsteuersatz
definiert wird?
So würde ich das zumindest machen, aber ich bin auch nur
Softwareentwickler, kein Kaufmann.

Hi Ralf,
genau so ist es eigentlich richtig. Wenn man sprechende Schlüssel (im obigen
Fall die Datev-Steuerschlüssel) als Primärschlüssel für Beziehungen nutzt,
dann fliegt man früher oder später auf die Nase.

[Wolfgang Wolf]

Hallo Ralf
"Ralf Brostedt" <***@compuserve.de> schrieb
[...]

Wer macht denn so etwas? Ist es nicht eher so, dass diese Stammdaten unveränderlich bleiben und einfach ein neuer Schlüssel
(respektive ein neuer Datensatz) für den neuen Mehrwerststeuersatz angelegt wird, der dann als neuer Default-Wert für Produkte mit
vollem Mehrwertsteuersatz definiert wird?

Da hast Du schon recht. Wer seine Steuertabelle
mit drei Spalten anlegt, einen eigenen Schlüssel
pflegt und die Datev-Vorgabe lediglich mitschleppt,
den Datev-Steuerschlüssel also nicht als Primärschlüssel
verwendet ist fein raus. Ich kenne aber einige
PPS- und Warenwirtschaftsysteme die das nicht machen,
auch unseres nicht.
Das meinte ich dann auch mit gründlichem Studium
der Normalisierung. Hier kann man Fehler machen die
später sehr, sehr weh tun...

Gruß
W. Wolf

[Frank Müller]

Hallo Wolfgang,

Post by Wolfgang Wolf
Hallo Frank,

Post by Frank Müller
Das sind also die Bewegungsdaten der Kasse.
Hier ist es nicht unbedingt notwendig die Einnahmen / Ausgaben
in zwei Feldern zu speichern, denn worum es sich handelt ergibt
sich aus dem Vorzeichen des Betrags. (Ausgabe = negative Einnahme)

Definiere in diesem Zusammenhang die Gutschrift ;-)

Na ja eine Gutschrift hat nicht direkt etwas mit dem
Kassenbuch zu tun (siehe unten) Man kann sich natürlich
darüber halten, dass eine Gutschrift an einen Kunden
natürlich einen positiven Betrag ausweist, aber es sich
doch um einen "Verlust" handelt.

Aber wenn es um reine Einnahmen / Ausgaben
in einer Kasse geht, dann ist das auch kein Problem
wenn z.B. ein Kunde in den Laden kommt, einen
gekauften Artikel zurück gibt und sein Geld
zurück bekommt. Also Ausgabe im Kassenbuch.

Post by Wolfgang Wolf
Nein, zwei Tabellen für Ausgaben / Einnahmen braucht Zinar
wirklich nicht, aber der von Dir empfohlene Buchungsgrund
sollte es schon sein. Ausgabe / Einnahme nur über das
Vorzeichen zu definieren, wäre mir doch zu wenig. Daraus
ergibt sich, der Normalisierung folgend, die dritte Tabelle.
Da stimme ich dir zu 100% zu.

Ja sicher, nicht NUR über das Vorzeichen definieren,
das war ja auch die Kurzform.

Post by Wolfgang Wolf
Von Kunden sprechen wir im allgemeinen im geschäftlichem
Umfeld. Also benötigen wir noch höchstwahrscheinlich die
Tabelle mit den Steuersätzen.

Na ja, das ist genau die Frage was der OP eigentlich
machen möchte und wie man den Begriff "Kassenbuch"
definiert.

So wie ich das verstanden habe möchte er nur
reine Ausgaben / Einnahmen erfassen, das ist also
wie ein Kontoauszug einer Bank. Da wird ja auch
in den Salden nicht differenziert warum wieso
und wie sich der Betrag zusammen setzt.

Post by Wolfgang Wolf
Wer sich so weit vorwagt
bekommt dann auch zu spüren was es bedeutet wenn Entscheidungsträger

Ja da hast du natürlich recht, und ein einfaches "Kassenbuch"
kann so etwas sowieso nicht leisten. Denn unabhängig von den
Steuersätzen müssten ja auch noch ganz andere Sachen berücksichtigt
werden wenn der Zahlungseingan eines Kunden vom Betrag her nicht
mit dem offenen Posten übereinstimmt. Da kommen dann solche
Sachen wie Skontoaufwand / Skontoertrag mit entsprechenden
Steuerkorrekturen in der Buchen ins Spiel usw. usw.

Aber das wäre eher eine Fibu anstatt eines Kassenbuchs.
Vielleicht ist dem OP ja gar nicht klar was er möchte!?

Mal ganz abgesehen davon, dass es ja durchaus
Unternehmensformen geben kann wo die Steuer anders
verbucht wird als wenn bilanziert wird. (EÜR z.B, Kleinunternehmer)

Gruß,
Frank

[zinar Sozdar]

Post by Stefan Dase
Hallo Zinar,

Post by zinar Sozdar
Hallo Luete,
ich möchte unter VB6 ein Kassenbuch Programm erstellen.Um die
Kundeninformationen zu speichern, habe Tabelle 1 und für die Einnahmen
und Ausgaben habe Tabelle 2
Tabelle 1
ID | Kunde | Adresse | Tel | Fax | Datum
--------------------------------------------------------------

--------
Was soll hier in den Feldern Datum und Anf.Bestand gespeichert werden?
Da würde ich eine eindeutige Kundennummer vergeben im Programm
und diese in der anderen Tabelle bei Bedarf verwenden.

Post by zinar Sozdar
Tabelle 2
ID | Datum | Einnahmen | Ausgaben | Text
----------------------------------------------------------------

--------

Post by zinar Sozdar
In Tabelle 1 werden Kunden-Daten gespeichert.(Adresse Tel. usw.)
in Tabelle 2 werden Einnahmen und Ausgaben für z.B Januar gespeichert.

Das sind also die Bewegungsdaten der Kasse.
Hier ist es nicht unbedingt notwendig die Einnahmen / Ausgaben
in zwei Feldern zu speichern, denn worum es sich handelt ergibt
sich aus dem Vorzeichen des Betrags. (Ausgabe = negative Einnahme)
Das Feld Bestand (Kassenbestand?) ist hier nicht notwendig da sich
dieser mit jedem Datensatz ändert und jederzeit ermittelt werden kann.
Wenn du den Bezug zu den Kunden aus der anderen Tabelle bzw.
zu Gründen von Einnahmen und Ausgaben herstellen möchtest, fehlt
in dieser Tabelle noch ein Feld wo der Grund vermerkt werden kann.
(Beispielsweise die Kundennummer des Kunden)

Post by zinar Sozdar
Ich mochte aber so Programieren dass die z.B
Daten von 2007-->Januar, 2007-->Febr......usw
Daten von 2008-->Januar, 2008-->Febr..... usw.

Ds ist nicht sinnvoll da für jeden Monat bzw. jedes Jahr
eine eigene Tabelle anzulegen. Da das Datum ja erfasst wird,
kannst du jederzeit Salden über beliebige Zeiträume per Abfrage
ermitteln und in deinem Programm ausgeben lassen.

Post by zinar Sozdar
Kann einer mir schreiben wie ich das realisieren kann? Brauche ich
vielleicht noch zwei Tabellen
z.b Jahr und Monat und die verknüpfen?

Nein, was du bräuchtest ist eine oder mehrere weitere Tabellen
für die Daten die sich selten oder gar nicht ändern bzw. nicht
für jede Kassenbewegung in dieser Tabelle vollständig gespeichert
werden sollten.
Also z.b. eine Tabelle für die Kunden (mit eindeutiger Kundennummer)
Eine Tabelle für die "Gründe" der Einnahmen / Ausgaben. Eine Bewegung
in einer Kasse muß ja nicht unbedingt etwas mit Kunden zu tun haben das
kann alles mögliche sein.
Schildere doch mal etwas genauer was du überhaupt machen möchtest bzw.
was dein Kassenbuch überhaupt können soll. Nur dann kann man konkret
etwas dazu sagen. (Wenn das gewerblich genutzt werden soll, dann sind
da nämlich noch ein paar Sachen mehr zu beachten als nur Tabellenaufbau)
Gruß,
Frank

Hallo Frank,
erstmal danke, dass du dir Zeit genommen hast und mir zurück
geschrieben hast.
Das Programm was ich schreiben muss soll nur Einnahmen und Ausgaben
für jeden Monat im Jahr in die Datenbank schreiben.
d.H

Tabelle 1

ID | Kunde | Adresse | Tel | Fax | Datum
--------------------------------------------------------------
1 | Laden 1| xxxxxxxx|1111| 222 |01.01.2007
2 | Laden 2|yyyyyyyy |333 |4444|01.01.2007
................................................................
................................................................
10

und

Tabelle 2

Jan | Feb
|Mrz |Apr...........Dez
-----------------------------------|---------------------------------------|-------------------|--
Datum | Ein. |Ausg | Datum | Ein |Ausg |
-------------|----------------------|--------------- |---------
|-----------|--------------------------------
01.01.07 |1000€| 200€ | 01.02.07 |1000€ | 200€ |
02.01.07 | 500€ | 100€ | 02.01.07 | 500€ | 100€ |

03.01.07 |..................... | 03.01.07 |.................. ..|..
usw

das ganze für alle 12 Monate im Jahr und für das Jahr 2008 das
selbe....

Das Preblem ist, ich weiss nicht, wie ich die Tabellen miteinander
verknüpfen kann, sodas es wie oben aussieht?

Mfg
Zinar

[Frank Müller]

Hallo Zinar,

Post by zinar Sozdar
erstmal danke, dass du dir Zeit genommen hast und mir zurück
geschrieben hast.
Das Programm was ich schreiben muss soll nur Einnahmen und Ausgaben
für jeden Monat im Jahr in die Datenbank schreiben.

Also einfach nur "rein" und "raus" aus der "Kasse"?
Bzw. so wie es auf einem Kontoauszug einer Bank
aussieht?

Verabschiede dich einfach mal von dem Gedanken, dass
"für jeden Monat" etwas zu bedeuten hat. Wenn du jedem
Datensatz das DATUM erfasst läuft das unabhängig von
Monaten oder Jahren.

Post by zinar Sozdar
d.H

Das heißt gar nichts ausser dass du ein falsches
Design deiner Datenbank hast bzw. ein falsches
Verständnis von Abfragen gegen eine Datenbank.

Es ist da absolut nicht notwendig und auch unsinnig
für einzelne Zeiträume Tabellen oder Felder anzulegen.

[Unsinniger Tabellenaufbau...]

Post by zinar Sozdar
das ganze für alle 12 Monate im Jahr und für das Jahr 2008 das
selbe....

Und für 2009 / 2010 usw?
Verabschiede dich von dem Gedanken Tabellen oder Spalten
fest auf ein Datum zu fixieren. Das kann nur schief gehen.

Post by zinar Sozdar
Das Preblem ist, ich weiss nicht, wie ich die Tabellen miteinander
verknüpfen kann, sodas es wie oben aussieht?

ich sag es mal ganz krass so: Die Struktur einer Tabelle
hat erst mal überhaupt nichts mit der Optik / Aussehen
der darin enthaltenen Datensätze zu tun. Die DB ist
nur für die reine Speicherung der Daten zuständig.

Wie die dann wie auch immer angezeigt werden ist
Sache deines Programms. Du mußt halt entsprechende
Abfragen (z.B. nach Zeiträumen) auf den Datenbestand
los lassen und dann diesen anzeigen.

Du hast den Thread ja bestimmt verfolgt und ich gehe
mal davon aus, dass du da einige Infos gelesen hast,
die auf dich überhaupt nicht zutreffen.

Also sag doch einfach mal was genau dein Programm
eigentlich können soll und wer es wofür verwenden
möchte. Und auch den Punkt "du musst" ein Programm
schreiben macht mich stutzig. Ist das dein Chef, ein Kunde
oder wer hat dir diesen Auftrag geben so ein Programm
zu schreiben?

Gruß,
Frank