Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm

[jobo]

Zitat von haentschman:

Zählt eine SP zur Businesslogik (was man auch im Programm abarbeiten könnte) oder zur Datenbanklogik die eine Abfrage "berechnet".
Vieleicht sollte man das mal definitionstechnisch klarstellen.

Businesslogik sind in meinen Augen fachliche Anforderungen, die man nicht unbedingt mit gängigen Datenbankmitteln abdecken kann. Bis hin zur Implementierung von ganzen Geschäftsprozessen.
Beispiel Kundenverwaltung, ich kann Anrede Herr, Frau, (Fräulein) usw. als Constraint definieren, habe aber ein Problem, sobald die Marketingabteilung meint, da muss jetzt auch GenderQueer rein. Und übermorgen stellt man fest, das man 2 vergessen und 3 falsch geschrieben hat.
Also muss es entweder modelliert werden, Anrede Tabelle mit Schnickschnack oder ich streue regulierenden Code ein (Trigger, SP), die eingreifen.
Wenn ich meine CRM Software nun an verschiedene Kunden verkaufen möchte, läuft es darauf hinaus, dass es so gemacht werden muss, dass die es selber einstellen können. Fachliche Anforderungen werden in ein möglichst dynamisches DB Modell umgesetzt.
Trotzdem hindert einen niemand daran, Anrede halt doch per Constraint zu definieren.
Den Begriff aufzudröseln ist nicht immer einfach.

So wird ein Schuh draus:
Wenn ansatzweise die Möglichkeit besteht, dass verschieden schlaue Clients auf die DB zugreifen (schreibend), dann empfiehlt es sich alles wasserdicht zu machen, was davon betroffen ist. Das sorgt dann für Robustheit. Ein Appserver der nicht über das alleinige Zugriffsrecht verfügt, wird da eben zum Risiko. Ein schlauer Client allein nicht. Aber wenn ein Systemzugang einmal offen ist (nur für ein paar Access Reports) und die Schreibrechte ungeregelt, dann hat man m.E. die Kontrolle verloren und kann tatsächlich gleich mit Excel weiterarbeiten.