nicht angemeldet
Moin!
Stored Procedures sind aus meiner Sicht in den meisten Projekten aber tatsächlich nicht wirklich angebracht. Das ist wirklich nur dann sinnvoll, wenn man auf die Datenbank aus mehreren verschiedenen Sprachen zugreift und gewisse Regeln forcieren muss.
was hat das mit verschiedenen sprachen zu tun ? es ist doch leztlich vollkommen wurscht, ob ich anwendungen habe, die die gleiche sprache benutzen oder aber andere. ich will bestimmte dinge nur an einer stelle festlegen, und zwar ganz unabhängig von der anwendung, weil ich ganz einfach darüber die kontrolle haben will. und die performance spielt auch noch eine gewisse rolle...
Es gibt den Ansatz, sämtliche Datenkontrolle zentral in der Datenbank zu lagern. Das ist prima, wenn man eine Herde von DBAs hat, und sich ersparen will, diese ganze Logik in seiner zugreifenden Applikation zu programmieren.
Der Nachteil ist, dass diese Check-Logik unter Umständen ein hartes Performance-Limit setzt und ziemlich effektiv verhindert, dass man die speichernde Datenbank mal so einfach austauschen kann. Ebenfalls müssen sich die Programmierer zur Realisierung von Daten- und Zugriffslogik intensiv mit mindestens zwei Sprachen auseinandersetzen, und werden eventuell doch feststellen, dass "es" in der Datenbank schon zu spät ist, irgendeinen Daten-Fehler festzustellen und zu bemängeln.
Deshalb ist der einfachere Ansatz, die Datenzugriffslogik in der programmierten Applikation zu realisieren, und die Datenbank im Prinzip nur als Speicher zu benutzen, eventuell angereichert um so obskure Features wie Joins. Es gibt ja auch schon zahlreiche Projekte, die Datenspeicher ohne SQL herstellen - das ganze läuft dann unter dem Begriff "NoSQL".
- Sven Rautenberg