Zitat:
Wir haben auch recht viel der Buissineslogik in der
DB mal ne dumme Frage...
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.
Sagen wir mal so: Datenbanklogik schließt nicht aus, dass sie Geschäftslogik ist.
Für mich ist Datenbanklogik der Teil der Geschäftslogik, der in der Datenbank liegt und von der Datenbank ausgeführt wird.
Auch Views sind für mich ein Teil der Geschäftslogik. Sie stellen halt eine definierte Sicht auf die von der Datenbank vorgehaltenen Daten dar.
Für mich gehört alles in der Datenbank, was nicht der reinen Datenvorhaltung dient, zur Geschäftslogik.
Unter Datenvorhaltung verstehe ich hier (mal unfein ausgedrückt): "
CSV-Dateien auf hohem Niveau"
Zitat von
Slipstream:
Alles kann man natürlich nicht in Stored Procedures legen. Wir haben zum Bleispiel ein Textanalyse-Machine, das nicht nur Rechtschreibung und Grammatik korrigiert, sondern auch Synonyme kennt, Worthäufigkeiten ermittelt und der Gleiches mehr. Das kann man mit
DB-Mitteln nicht realisieren.
Jain: Sagen wir mal so: Man kann alles auf die Datenbank verlagern, was die Datenbank mit Datenbankmitteln erledigen kann.
Habe mal Routinen geschrieben, mit denen man bei Adressdaten auf Ähnlichkeiten achtet, um die Anlage von Adressdubletten (möglichst weitgehend) zu vermeiden (quasi ein extrem aufgemotztes SoundEx und sonstige Phonetikvergleiche ... Gewusel). Das geht mit der Datenbank, man muss halt die Programmiersprache der Datenbank genauso beherrschen, wie man's von Delphi nach jahrelanger Erfahrung gewohnt ist.
Da müssen dann halt ein paar Datenbankpackages her. Dazu ein paar Funktionen, die auch in Triggern aufgerufen werden können und plötzlich ist es egal, wer aus welcher Quelle, welche Daten in das System schubste: Dubletten werden erkannt, bei Unsicherheit protokolliert und der Fachabteilung frisch zubereitet zur Überprüfung vorgelegt.
Und das ganze läuft auch noch sauschnell. Dieses Tempo hat keine der vorherigen Programmlösungen (auch keine der seinerzeit kaufbaren) hinbekommen.
Und
SQL schreibt man nicht mal einfach so. Man muss schon eine entsprechende Denkweise erlernen, um sinnvoll und performant Daten aus einer Datenbank heraus bzw. hinein zu bekommen. Da braucht man mehr als nur die Kenntnis der korrekten Syntax. Man muss nicht nur das Datenmodell kennen, sondern möglichst das Datenmodell incl. der zugehörigen Fachlichkeit. Hat man das zusammen, dann kann man sich zuerstmal überlegen, wie die fachlichen Zusammenhänge zwischen den auszuwertenden / verarbeitenden Daten sind und damit dann anfangen ein möglichst performantes
SQL zu formulieren. Ein "select * from tabelle left right full wasweißichjoin order by 1,2,3,4" ist da oft nicht unbedingt die erste und beste Lösung.
Zitat von
Slipstream:
Zum Glück arbeite ich seit Jahren in einem Team mit einen hervorragenden Datenbankspezialisten, der nicht nur einfach alles übernimmt, was an
SQL-Programmierung nötig ist, sondern seinen Kollegen auch geduldig erklärt, wie eine bestimmte SP arbeitet.
Das Glück hatte ich auch bei zwei großen Projekten. Solche Leute sind schlicht und einfach Gold wert und leider eher selten zu finden.
@haentschman
Slipstream wollte mit seinem Virus-Tier-Pflanzenvergleich (vermutlich) nur eine Analogie zwischen Business und Datenbanklogik herstellen. Die Grenzen sind fließend und können nicht absolut festgelegt werden. Es gibt halt auch hier immer etwas, das man ohne schlechtes Gewissen in beide "Töpfe" stecken kann. Es ist einfach kein reines "Schwarz-Weiß" zwecks Unterscheidung möglich. Oder eben keine klare und eindeutige Unterscheidung zwischen Tier und Pflanze.
Ich persönlich halte es auch nicht für wichtig, streng zwischen Geschäfts- und Datenbanklogik zu unterscheiden. Im Vordergrund steht für mich eine möglichst perfekte Funktionalität der umzusetzenden Anforderungen.