Wie Schema fürRechnungssystem realisieren?

Hallo NG,

Ich stehe gerade vor einer Designfrage für ein Rechnungssystem.

Der Kunde bekommt in der Woche mehrere tausend Bestellungen von
unterschiedlichen Kunden, dementsprechend viele Rechnungen werden erstellt.

Gedankenkonstrukt eins:

Es gibt eine Rechnungstabelle "rechnungen", in der aus einer Sequence oder
einer function, die irgendwas macht eine eindeutige Rechnungsnummer
erstellt wird und noch ein paar zusatzinfos gespeichert sind. Ungefähr so:

rechn_nr int4 primary key not null default nextval('zaehler'), datum date
not null, zeit time not null, bemerkungen text, ... usw. und so fort.

Ich könnte dann für jede Rechnung, auch wenn es der gleiche Kunde ist, eine
einzelne Tabelle erstellen, in der ich dann die einzelnen Positionen der
Rechnung festhalte. Das Geschäft des Kunden ist so aufgebaut, daß ein
einzelner Kunde vermutlich nicht mehrmals bestellt, also eigentlich keine
gesonderten Kundenprofile oder dergleichen angelegt werden müssen. Somit
würde dann für jeden Bestellvorgang eine Tabelle angelegt werden. Das
Volumen der letzten 6 Jahre beläuft sich auf ca. 2 Millionen
Bestellvorgänge...also nehme ich mal an, daß ich nach ungefähr der gleichen
Zeit ca. 2 Millionen Tabellen in meiner Datenbank habe, was leicht
unübersichtlich ist. Jedoch werden die zu den Rechnungen gehörigen
Positionen recht schnell gefunden, da jede Bestellung eine eigene relativ
kleine Tabelle ist (zwischen 1 - 50 Datensätze).

Gedankenkostrukt zwei:

Es gibt wieder die gleiche Tabelle "rechnungen" (dient zur
Übersichtlichkeit) und ich speichere alle Positionen von allen Bestellungen
in einer Tabelle ab.

Beispiel:

rech_nr | kund_nr | position | menge | epreis
--------+---------+----------+-------+-------
0001| 389743| 1| 2| 14,99
0002| 423941| 1| 1| 7,99
0001| 389743| 2| 3| 2,99
0003| 342342| 1| 5| 49,95
0001| 389743| 3| 1| 1,00

Ich könnte dann mit einem "select * from where rech_nr='0001';"
alle Positionen zu entsprechender Rechnungsnummer finden. Nachteil: Mit
wachsender Datensatzanzahl wird der Zugriff langsamer, oder? Hierbei könnte
ein Index auf die Rechnungsnummer zwar helfen, aber bei mehreren Millionen
Datensätzen?

Die Geschwindigkeit dieser Lösung müßte sich entgegengesetzt proportional
zur Anzahl der Datensätze verhalten, oder?

Gedankenkonstrukt drei:

Ich könnte eine Mischlösung aus den ersten beiden Varianten erstellen, indem
ich zwar alle Positionionen von allen Rechnungen in eine Tabelle werfe,
diese dann aber quartalsweise rotiere, sodaß die Tabellen nicht allzu groß
werden und ich trotzdem noch einigermaßen den Überblick für eventuelle
händische Eingriffe behalte..jedoch erfordert diese Lösung zusätzlichen
Aufwand auf Seiten der Applikation, da die schon rotierten Tabellen auch im
Zugriff stehen müssen, deswegen präferiere ich diese Lösung nicht so.

Was meint ihr dazu?

Eingesetztes DBMS ist Postgres 7.4.3, Update auf 8.0 wäre Möglich, jedoch
will ich erstmal abwarten, ob's vielleicht irgendwelche kritische Fehler
hat. Späteres Update ist ja via pg_dumpall möglich.

Wieviele Tabellen kann Postgres ab, bevor es in's Schlingern kommt? (für
Lösung 1), und ab wievielen Datensätzen wird das Heraussuchen der
Rechnungspositionen quälend? (für Lösung zwei?).

Lösung 3 will ich eigentlich nicht :o), da ich keine Lust habe die Software
zu modifizieren, aber wenn's ja nicht anders geht?

Oder ist das hier gar alles totaler Käse und ihr habt eine bessere Idee wie
ich das lösen kann?

Gruß!

Sven
--
Accent on helpful side of your nature. Drain the moat.

Re: Wie Schema für Rechnungssystem realisieren?

Sven Ladegast schrieb:

> Was meint ihr dazu?

zwei

Grüße, Matthias

Re: Wie Schema fürRechnungssystem realisieren?

Sven Ladegast wrote:
>
> Ich stehe gerade vor einer Designfrage für ein Rechnungssystem.
>
> Gedankenkonstrukt eins:
>
> Es gibt eine Rechnungstabelle "rechnungen"
>
> rechn_nr int4 primary key not null default nextval('zaehler'), datum date
> not null, zeit time not null, bemerkungen text, ... usw. und so fort.
>
> Ich könnte dann für jede Rechnung, auch wenn es der gleiche Kunde ist, eine
> einzelne Tabelle erstellen

Setzen, durchgefallen!

> Gedankenkostrukt zwei:
>
> Es gibt wieder die gleiche Tabelle "rechnungen" (dient zur
> Übersichtlichkeit) und ich speichere alle Positionen von allen Bestellungen
> in einer Tabelle ab.

Ja, ungefähr so ist das richtig. ABER

> Beispiel:
>
> rech_nr | kund_nr | position | menge | epreis
> --------+---------+----------+-------+-------
> 0001| 389743| 1| 2| 14,99
> 0002| 423941| 1| 1| 7,99
> 0001| 389743| 2| 3| 2,99
> 0003| 342342| 1| 5| 49,95
> 0001| 389743| 3| 1| 1,00

noch nicht normalisiert. Dir fehlen Grundlagen.


> Mit wachsender Datensatzanzahl wird der Zugriff langsamer, oder? Hierbei könnte
> ein Index auf die Rechnungsnummer zwar helfen, aber bei mehreren Millionen
> Datensätzen?

Genau dafür gibt es Indizes; damit man auch mehrere Milliarden
Datensätze schnell durchsuchen kann. Auch hier fehlen dir
anscheinend Grundlagen. Tu dir und deinem Kunden einen Gefallen
und lerne erstmal wie man sowas richtig macht.


XL

Re: Wie Schema fürRechnungssystem realisieren?

Matthias P. Wuerfl wrote:

>> Was meint ihr dazu?
>
> zwei

Warum? :o)
Was wird aus meinen Bedenken bzgl. der Datenmenge? Das wird doch nicht mit 2
Mill. Datensätzen genauso performant sein wie mit 10, oder? :o)

Sven

--
We have only two things to worry about: That things will never get
back to normal, and that they already have.

Re: Wie Schema fürRechnungssystem realisieren?

Sven Ladegast wrote:

[viel}

Anmerkung: Habe gerade gemerkt, daß ich in die falsche Newsgroup gepostet
habe. dcdm und dclpd sind bei mir direkt übereinander...hab mich wohl
vertippert.

Gruß!

Sven
--
So you think that money is the root of all evil.
Have you ever asked what is the root of money?
-- Ayn Rand

Re: Wie Schema fürRechnungssystem realisieren?

Sven Ladegast schrieb:

Moin,

>>> Was meint ihr dazu?
>>
>> zwei
>
> Warum? :o)
> Was wird aus meinen Bedenken bzgl. der Datenmenge? Das wird doch nicht mit
> 2 Mill. Datensätzen genauso performant sein wie mit 10, oder? :o)

Aber ähnlich schnell mit einem Index.

Christoph

Re: Wie Schema für Rechnungssystem realisieren?

Sven Ladegast schrieb:

> Das wird doch nicht mit 2
> Mill. Datensätzen genauso performant sein wie mit 10, oder? :o)

Nein, aber der Aufwand aus Tausenden Tabellen die richtige rauszusuchen
ist sehr hoch (wenn das mit *den* Mengen *überhaupt* geht.....)

Grüße, Matthias

Re: Wie Schema für Rechnungssystem realisieren?

Hallo Sven,

ich habe gerade das selbe Problem wie Du.

Sven Ladegast wrote:
> Gedankenkonstrukt eins:

Bei meinem Rechnungssystem habe ich diese Wariante gewählt.

Ich Besitze 3 Tabellen:
* rechnungen
* rechnungs_liste ( rechnungs_position )
* artikel

Tabelle rechnungen:
* rechnungs_id
* rechnungs_nr
* kunden_nr

Tabelle rechnungs_liste
* rechnungs_nr
* artikel_nr

Tabelle artikel
* artikel_id
* artikel_nr

Ich entwickle zwar gerade diese System, bin aber an der logig trotzdem
ein wenig am zweifeln.

> Gedankenkostrukt zwei:

Das halte ich für eine nicht so gute Lösung.

> Gedankenkonstrukt drei:

Verstehe nicht genau wie Du das meinst.

> Wieviele Tabellen kann Postgres ab, bevor es in's Schlingern kommt? (für
> Lösung 1), und ab wievielen Datensätzen wird das Heraussuchen der
> Rechnungspositionen quälend? (für Lösung zwei?).

Benutze MySQL, kann die da nicht weiter helfen.


Gruss
Alexander Wahl

Re: Wie Schema fürRechnungssystem realisieren?

Alexander Wahl wrote:

> Ich entwickle zwar gerade diese System, bin aber an der logig trotzdem
> ein wenig am zweifeln.

Das liegt vermutlich daran, daß wir die logischen Verknüpfungen (wenn es
mehr werden) nicht ganz so gut nachvollziehen können.

Ich habe am Montag das restliche Pflichtenheft bekommen und mußte auch
mein bisheriges Datenbankschema anpassen. Dabei habe das Ganze mir vorher
auf Papier alles genau aufgemalt wie's sein soll. Nach ca. 2 Stunden
hatte ich dann ein Schema, welches den Anforderungen gewachsen und auch
erweiterungsfähig ist.

Das Rechnungssystem habe ich dabei erst einmal außen vorgelassen. Es geht
jetzt in erster Linue um die Backendverwaltung inkl. Benutzer und
entsprechender Rechte, was ein Benutzer darf und was nicht.

Die Fremdschlüssel erfüllen den Zweck, daß die Daten "konsistent" bleiben,
sprich: Als Beispiel keine Rechnung ohne passenden Kunden :o)

Ich habe so ziemlich alles auseinandergerupft und in kleine Tabellen
gepackt. Mit Hilfe von Joins setze ich mir dann die entsprechenden Daten
wieder zusammen.

Zum Rechnugssystem: So wie Dein Schema wird wohl meins auch irgendwie
aussehen. Eine Artikeltabelle brauche ich auf jeden Fall und sämtliche
Rechnungspositionen aller Rechnungen werden auch in einer Tabelle
gespeichert. Eine eigene Rechnungstabelle gibt's dann auch noch, die
einen entsprechenden Fremdschlüssel auf eine Kundentabelle hat. Der Kunde
hat sich umentschieden und möchte eine Kundendatenbank führen, kommt mir
hier also ein wenig entgegen...

Soweit ist das erstmal meiner Ansicht nach richtig. Inweiweit Du Dein
Schema normalisierst, hängt davon ab wie flexibel Deine Anfragen sein
müssen...?

Das hier[1] hat mir eigentlich sehr weitergeholfen.

Gruß!

Sven

[1] https://bs.seminar-karlsruhe.de/ad/uploads/material/Datenban ken (Adam).pdf
--
Ring around the collar.