Tweet
<p>Hallo !</p>
<p>Ich habe bisher nur mit kleinen Datenbanken mit Delphi und Interbase
gearbeitet und ich möchte einmal eine große Datenbank und Anwendung
programmieren.<br>
Es geht um eine Waren-Ver/Einkauf, Lagerbestand und Kundenverwaltung.</p>
<p>Früher wollte ich eine Desktopversion schreiben und jedem Kunden und jedem
Artikel etc. eine eigene Tabelleninstanz spendieren. Jetzt denke ich an wenige
große Tabellen, aus denen man die benötigten Daten mit SQL, Stored Procedures
und Views auslesen+bearbeiten kann.</p>
<p>Größenordnungen: 100-500 Kunden, 100-500 Artikel, 100-200 Rechnungen pro
Tag mit 1-50 Posten, 2-3 Client-Computer</p>
<p>Ich denke da (grobe Vorstellung) z.B. an eine Tabelle, die für einen bestimmten Zeitraum gilt, z.B.
ein Jahr, die den Verkauf von Ware enthält und in etwa folgende Struktur hat:</p>
<p><i>Tabelle VKJournal:<br>
LaufdNr, RechnungsNr, KundeNr, Datum, ArtikelNr, WareneinkaufPartieNr, Kolli, VKPreis,
NochOffenerBetrag usw.</i></p>
<p>Außerdem gibt es eine Tabelle, in der die Wareneinkäufe (also alle Artikel)
vermerkt werden:</p>
<p><i>WareneinkaufPartieNr, ArtikelNr, Kolli, EKPreis,</i></p>
<p>und für den Wareneinkauf eine Quelle (also die Lieferanten):</p>
<p><i>WareneinkaufPartieNr, Datum, LieferantenNr</i></p>
<p>Täglich fallen also ca 1000 o.a. Buchungszeilen an, das wären dann ja
7*1000*52 = 364000 pro Jahr.</p>
<p>Bei der Eingabe der Kundennummer ins Rechnungsformular soll dann nach den
offenen Rechnungen gesucht werden.<br>
Das sieht dann etwa so aus:</p>
<p>select sum(NochOffenerBetrag)<br>
from vkjournal<br>
where (kundeNr=:KUNDE) and (NochOffenerBetrag<>0);</p>
<p>Es gibt also ständig select-Abfragen über lange Tabellen, die Bruchteile
einer Sekunde dauern sollten, da viele der Kunden, denen Rechnungen geschrieben
werden, diese unverzüglich bezahlen sollen.<br>
Wie sieht es wohl mit der Geschwindigkeit dieser Abfragen aus ?<br>
Wie machen das die Profis ?<br>
Ich würde gerne so eine universale Tabelle benutzen und dann alles andere mit
SQL, Stored Procedures und Views realisieren.<br>
Kann ich aus den gespeicherten Daten eine VIEW Kundenkonten einrichten, die also
aus den Verkäufen die offenen Rechnungen ermittelt, oder muß ich eine zweite
Tabelle dazu führen, die direkt oder am Ende des Tages abgeglichen wird ? Die
Lösung mit einer Tabelle ist natürlich einfacher.</p>
<p>Gruß Marcus</p>
<p>Ich habe bisher nur mit kleinen Datenbanken mit Delphi und Interbase
gearbeitet und ich möchte einmal eine große Datenbank und Anwendung
programmieren.<br>
Es geht um eine Waren-Ver/Einkauf, Lagerbestand und Kundenverwaltung.</p>
<p>Früher wollte ich eine Desktopversion schreiben und jedem Kunden und jedem
Artikel etc. eine eigene Tabelleninstanz spendieren. Jetzt denke ich an wenige
große Tabellen, aus denen man die benötigten Daten mit SQL, Stored Procedures
und Views auslesen+bearbeiten kann.</p>
<p>Größenordnungen: 100-500 Kunden, 100-500 Artikel, 100-200 Rechnungen pro
Tag mit 1-50 Posten, 2-3 Client-Computer</p>
<p>Ich denke da (grobe Vorstellung) z.B. an eine Tabelle, die für einen bestimmten Zeitraum gilt, z.B.
ein Jahr, die den Verkauf von Ware enthält und in etwa folgende Struktur hat:</p>
<p><i>Tabelle VKJournal:<br>
LaufdNr, RechnungsNr, KundeNr, Datum, ArtikelNr, WareneinkaufPartieNr, Kolli, VKPreis,
NochOffenerBetrag usw.</i></p>
<p>Außerdem gibt es eine Tabelle, in der die Wareneinkäufe (also alle Artikel)
vermerkt werden:</p>
<p><i>WareneinkaufPartieNr, ArtikelNr, Kolli, EKPreis,</i></p>
<p>und für den Wareneinkauf eine Quelle (also die Lieferanten):</p>
<p><i>WareneinkaufPartieNr, Datum, LieferantenNr</i></p>
<p>Täglich fallen also ca 1000 o.a. Buchungszeilen an, das wären dann ja
7*1000*52 = 364000 pro Jahr.</p>
<p>Bei der Eingabe der Kundennummer ins Rechnungsformular soll dann nach den
offenen Rechnungen gesucht werden.<br>
Das sieht dann etwa so aus:</p>
<p>select sum(NochOffenerBetrag)<br>
from vkjournal<br>
where (kundeNr=:KUNDE) and (NochOffenerBetrag<>0);</p>
<p>Es gibt also ständig select-Abfragen über lange Tabellen, die Bruchteile
einer Sekunde dauern sollten, da viele der Kunden, denen Rechnungen geschrieben
werden, diese unverzüglich bezahlen sollen.<br>
Wie sieht es wohl mit der Geschwindigkeit dieser Abfragen aus ?<br>
Wie machen das die Profis ?<br>
Ich würde gerne so eine universale Tabelle benutzen und dann alles andere mit
SQL, Stored Procedures und Views realisieren.<br>
Kann ich aus den gespeicherten Daten eine VIEW Kundenkonten einrichten, die also
aus den Verkäufen die offenen Rechnungen ermittelt, oder muß ich eine zweite
Tabelle dazu führen, die direkt oder am Ende des Tages abgeglichen wird ? Die
Lösung mit einer Tabelle ist natürlich einfacher.</p>
<p>Gruß Marcus</p>
Comment