Select * from

[Hansa]

Hi Sharky,

hätte ich nicht befürchtet, daß es ungefähr so ist, wie Du geschrieben hast, dann hätte ich den Thread nicht aufgemacht. Die Umsätze usw. werden meist für ein ganzes Jahr gebraucht, um die Entwicklung zu sehen. Also würde es keinen Sinn machen, die Tabelle in Monate aufzuteilen, wohl aber in Umsatz, Rohgewinn usw., jeweils 12 Monate in einem Satz, denn wer vergleicht schon den Rohgewinn im Juli mit dem Umsatz im Mai ? Den Rest muß ich mir mal in Ruhe überlegen. Trotzdem müßte ich dann die IDs, die ich auf jeden Fall brauche in 12 Tabellen mitschleppen, liegen da noch Foreign Keys usw. drauf, dann würden die Tables (ich bräuchte dann 5 statt einer) doch mächtig aufgebläht oder nicht ?

Sollte man das einfach in Kauf nehmen ?

[Sharky]

Zitat von Hansa:

.... Trotzdem müßte ich dann die IDs, die ich auf jeden Fall brauche in 12 Tabellen mitschleppen, ...

Warum in 12 Tabellen?

Eine Tabelle für die Kunden-Stammdaten
Eine Tabelle für die Kunden-Umsätze

z.b:
Tabelle - Kundenstammdaten

Code:

 k_id      : Integer;
 k_name    : Varchar (50)
 k_name2   : Varchar (50)
 k_name3   : Varchar (50)
 k_strasse : Varchar (50)
 k_plz     : Varchar (5)
 k_ort     : Varchar (50)

Tabelle - Kundenumsatz

Code:

 umsatz_id : Integer;
 ref_k_id  : Integer;
 monat     : Integer;
 jahr      : Integer;
 umsatz    : Real;

Jetzt erzeugst Du für jeden Kunden pro Monat und Jahr einen Eintrag in der Tabelle Kundenumsatz. ref_k_id ist die k_id aus der Tabelle Kundenstammdaten.

Fertig. Jetzt kannst Du ganz einfach abfragen:
Gesamtumsatz eines Kunden in einem Jahr, pro Monat .
Oder Du kannst die Gesamtumsätze aller Kunden für jeweils den Dezember der letzten drei Jahre abrufen.. usw.

P.S.: Ich habe mal eben geschaut. Die Datenbank für mein aktuelles Projekt (Warenwirtschaft mit Marketing. Inkl. Mailprogramm und Textverarbeitung usw.) Besteht aus:
102 Tabellen
57 Sichten

[Hansa]

Diese Tabelle ist die Statistik - Tabelle !!! muß weg....

[X-Dragon]

Zitat von DataCool:

Hi,

ich glaube X-Dragon wollte die DB nicht aufteilen, sondern die Tabelle mit deinen 60 Feldern in mehere Tabellen.

Ob das Sinn macht kann man nur sagen, wenn Du Deine Tabellenstruktur preisgibst !

Data

Ähm ja so war das gemeint, jaja Tabelle und Datenbank ...

@Hansa
Also an den Tabellen wolltest du nichts ändern, und nur die Abfrage der benötigten Daten aus der einen Tabelle optimieren?

[Hansa]

Zitat von X-Dragon:

Ähm ja so war das gemeint, jaja Tabelle und Datenbank ...

@Hansa
Also an den Tabellen wolltest du nichts ändern, und nur die Abfrage der benötigten Daten aus der einen Tabelle optimieren?

Von mir aus ändere ich die Tabellen noch 100mal. Bin heute mittag geflüchtet, weil ich sonst zu nix komme, dann hab ich mir das mal in Ruhe durchgelesen. Der Ansatz von Sharky ist wohl schon richtig so. 2 Sachen gefallen mir aber nicht. Das mit Monat und Jahr ist klar. Aber:

Ich habe ziemlich gleiche Statistiken, die unterscheiden sich nur dadurch, daß in einem Fall auf die Kunden-Table und in dem anderen auf Warengruppen zugegriffen werden soll. Dafür habe ich die entsprechenden IDs in der Statistik-Table drin. Also würde ich sagen, dafür muß ich dann doch jeweils eine eigene Table machen, oder nicht