Ja, aber im Mehrbenutzerbetrieb dürfte das Unterfangen, Dubletten hauptsächlich per Programmcode zu ermitteln, eher schwierig werden, auf jeden Fall keinesfalls verlässlich.
In 'ner
DB-
Exception steht gewöhnlich drin, was passiert ist, Schlüsselverletzung ...
Wenn ich also einen Datensatz speichere und dann als
Exception einen Constraintverletzung bekomme oder eine Verletzung eines eindeutigen Schlüssels, weiß ich schon, dass es sich um eben diese handelt. Und im Zusammenhang mit der Fachlichkeit, bei der der Fehler auftritt, sollte ich damit durchaus in der Lage sein, dem Anwender eine aussagefähige Meldung zu geben bzw. im Programm entsprechend zu reagieren.
Wenn man im Programm vor dem Speichern auf eventuell mögliche Schlüsselverletzungen prüft, so kann man dann zwar auch schon reagieren, muss aber beim Speichern trotzdem nochmal mit dem Auftreten einer entsprechenden
DB-
Exception rechnen und die dann auch vernünftig und aussagefähig für den Anwender handhaben.
An einer vernünftigen Verarbeitung von Datenbankfehlern kommt man also nicht vorbei. Die vorherige Prüfung ausserhalb der Datenbank ist also höchstens ein "Nice To Have", dass den Programmierer beruhigt, aber keinesfalls ein sicherer Umgang zur Vermeidung von Dubletten.
Die ausschließliche oder überwiegende Prüfung von Schlüsselverletzungen im Programm kann man (meiner Meinung nach) nur dann ernstlich in betrachtziehen, wenn absolut sichergestellt ist, dass eine Datenbank nur von einem Programm und einem Nutzer zeitgleich genutzt wird, also ein exklusiver Zugriff auf die Datenbank vorliegt.