Zitat:
Aus datenbanktechnischer Sicht sind lückenlose Belegnummern kein Problem und darum sollte vielleicht die Frage erlaubt sein, warum man es als Entwickler/Programmierer/SW-Hersteller nicht tun sollte?
Sogar wenn du nur eine Quelle für deine Nummernvergabe hast, entsteht bei Installationen mit mehreren Clients eine gewisse Wahrscheinlichkeit, das irgendwann mal 2 Clients gleichzeitig eine neue Rechnung erzeugen und in beiden Programmen der Wert der letzten Rechnungsnummer auf Basis des aktuellen Werts +1 ermittelt wird.
Beide haben aber vielelicht schon erfolgreich per update den letzten Wert je um 1 erhöht, abermindestens einer bekommt beim Speichern wegen einem Unique Index auf der Rechnungsnummer in der Datenbank eine
Exception.
Wenn der durch die
Exception dann den Vorgang einfach noch mal macht, ist eine Lücke in den Rechnungsnummern. Diese dann generell wieder aufzufüllen mit der noch fehlenden Rechnungssnummer ist zwar eine nette Idee, aber spätestens bei Jahreswechsel eine sehr blöde Idee. Ob das durch deine Datenbank serialisiert wird und durch Transaktionen sauber abgearbeitet wird oder du andere Techniken eingebaut hast, sei hier jetzt mal offen, natürlich lässt sich so was pro Server mehr oder weniger sauber realisieren, insbesondere wenn der Transaktionen unterstützt. Es bleibt aber dabei, das die bewusste Einplanung von Lücken da eine Menge Arbeit einspart.
Und es gibt durchaus Systeme, da reden wir nicht über 2 oder 3 Rechner, an denen Rechnungen geschrieben werden, sondern wo dutzende Abteilungen im Unternehmen verteilt das machen. Die Chance, das es dann knallt, steigt sehr schnell an. Und wenn die dann noch an unterschiedlichen Standorten verteilt sind, sind Nummerkreise pro Standort sowieso erforderlich, um die Forderung nach Eindeutigkeit erfüllen zu können. Eine Forderung der Lückenlosigkeit gibt es aber nicht.