Aufbau Lagerhaltung in SQL

Computer: Software & Programmierung Datenbanken allgemein
#1

Moien

Hab’s gerade mit einem komsichen Programm zu tun und wollte fragen ob das Verfahren normal ist:

Das Programm macht die Verwaltung von Läden (Kaufen, verkaufen, Rechnungen. Lieferscheine…). Alles in SQL (MS SQL Server). Natürlich gibts auch eine Lagerverwaltung.

Um nun den aktuellen Lagerbestand eines Artikel zu bekommen ackert das Ding alle Vorgänge die den Artikel betreffen durch und addiert/subtraiert die Mengen. D.h. in der DB steht nirgens die aktuelle Menge. Der arme Server muss jedesmal durch alle Lieferscheine (Kunden und Lieferrantenseite), Inventuren, usw durch.

Ist das normal ? Könnte man da nicht verdammt viel Rechenzeit sparen … ?

Das Programm enthält im Moment die Daten von etwa 18 Monaten (2,5 GB wenn man’s als Backup unter MS SQL Server speichert). Der 1 GHz Dual-Xenon (viel RAM, schnelle SCSI-Platten in RAID… usw) Server im Keller ist mit dem Erstellen einer Rechnung 5-10 Sekunden voll ausgelastet.

Irgendwie seh ich da ein grosses leistungstechnisches Problem auf uns zukommen. Die Datenmenge wird ja sicher nicht kleiner. Im Moment laufen nur 2-3 Posten mit dem Ding, aber wenn da erstmal 20-30 Leute mit arbeiten… ?

Danke.

#2

Hi,
das hört sich nach schlechter Implementierung an.

Aus Gründen der Redundanz, sollte man zwar keine Daten die man berechnen kann nochmal in der DB ablegen, nur ist das natürlich Theorie.

Grundsätzlich sollte der von dir beschriebene Weg - bei guter Implementierung - auch sehr schnell gehen. Es gibt aber sehrwohl Fälle von man zB. mit Triggern solche Daten in anderen Tabellen vorhalten muss.

Was man wie implentiert, hängt aber von der Datenmenge, Struktur, Häufigkeit usw. ab. Das muss der Entwickler entscheiden.

Gruss
Quaser

#3

Moien

Aus Gründen der Redundanz, sollte man zwar keine Daten die
man berechnen kann nochmal in der DB ablegen, nur ist das
natürlich Theorie.

Und wenn man „nur“ den jetzt-Zustand ablegt und bei Bedarf rückwärts rechent ? Muss ja nicht bei 0 angefangen haben.

Grundsätzlich sollte der von dir beschriebene Weg - bei guter
Implementierung - auch sehr schnell gehen.

Sagen wir’s mal so: Es gab schon halb durchgezogene Lieferungen im System. Die Artikel waren aus der Lieferantenbestellung raus, aber nicht im Lager angekommen. Der PC war abgeschmiert und es waren wohl nicht alle SQL-Befehle rausgegangen. Ich erinner mich da dunkel an atomare Transaktionen… scheint bei dem Ding nicht zu klappen.

Es gibt aber
sehrwohl Fälle von man zB. mit Triggern solche Daten in
anderen Tabellen vorhalten muss.

Z.B. für den Fall wenn man schnell und in weniger als 100 Zeilen SQL den Lagerbestand abfragen will… ?

Danke.

#4

Hi,

Sagen wir’s mal so: Es gab schon halb durchgezogene
Lieferungen im System. Die Artikel waren aus der
Lieferantenbestellung raus, aber nicht im Lager angekommen.
Der PC war abgeschmiert und es waren wohl nicht alle
SQL-Befehle rausgegangen. Ich erinner mich da dunkel an
atomare Transaktionen… scheint bei dem Ding nicht zu
klappen.

Das ist aber das Problem des Entwicklers, wenn er solche wichtigen Ab- und Zubuchungen nicht in Transaktionen klammert oder es besser gleich über eine Stored Procedure macht.

Gruss
Quaser