Hey Hansa alter Junge nicht gleich einschnappen, wenn der Hai mal zuschnappt!
Allerdings ist etwas daran: Du mußt 'ne Entscheidung treffen:
1. Du schränkst die möglichen Zieldatenbanken auf ausgewachsene
DB's (also solche mit StoredProcedures, Trigger, Constraints etc.) ein (btw. gibt es DB2 von IBM, welches durchaus ein ausgewachsenes
DBMS ist auch für Linux) und verkleinerst dadurch Deinen möglichen Markt, kannst aber andererseits auch systematisch vernünftige Ansätze verwirklichen.
Oder
2. Du verzichtest auf die Weitergehenden Möglichkeiten ausgewachsener
DBMS's, vergößerst Deinen Markt und "frickelst" es irgendwie zurecht.
Es gibt immer Argumente für die eine und die Andere Seite - soll hier nicht das Thema sein.
Richtig ist es auf jeden Fall, die Business-Logik strikt von der DatenbankStruktur- und Integrität zu trennen: Morgen schießt Deinem Kunden ein Furz aus dem Darm mit dem Umweg über's Rückenmark ins Hirn und Du wirst beauftragt, die Kundennummern um den Tag des Geburtsdatums zu erweitern - was dann (kein Scherz - habe solche und noch viel krudere Nummern erlebt)? Dann hängt Deine Datenbank womöglich komplett an den alten Kundennummern, da Du diese als Primary verwendet hast - viel Spaß damit!
Deshalb denk doch nochmal ernsthaft über eine Auslagerung der Kundennummer in eine separate Lookuptabelle nach, und benutze ansonsten konsequent servergenerierte ID's als Primary Keys in Deinen Tabellen. Wenn dann eine Änderung der Businesslogik in Bezug auf die Kundennummern stattfindet, kannst Du die ohne Kummer in Deiner
DB nachvollziehen.
In meinem aktuellen Projekt habe ich eine
DB mit ca. 160 Tabellen und insgesamt etwa 30 Mio Datensätzen. All diese Tabellen referenzieren am Ende mehr oder weniger direkt eine zentrale Entitätstabelle, die aus 6 Spalten besteht: Id,Typ,DatumStart,DatumStop,IdErzeuger,IdLöscher. Egal, wie sich die Hülle (Atribute) der Entitäten in Zukunft ändert - ich werde immer wieder einen EinEinDeutigen Zugriff auf die Entität haben - eine wirkliche Beruhigung!
Also schnapp wieder aus, und benutze den Hammer zum nageln und die Säge zum sägen
(Ich arbeite schließlich auch ab jetzt mit der Objektablage!)
Gruß
PS: die Protagonisten der "Select max(Id)"-Methode sollten sich mal fragen, wie sicher diese Variante im Mehrbenutzerbetrieb ist, wenn 2 Leute gleichzeitig einen neuen Kunden anlegen wollen, aber leicht zeitlich versetzt posten. Die Katastrophe ist dann vorprogrammiert. Solche sachen gehören nunmal in die Kompetenz der
DB und nicht in die der Clients.