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

[Frickler]

Immer wieder lese ich (nicht nur) hier, man möge das Datenbankhandling auf CRUD reduzieren und ansonsten alle Zugriffe programmgesteuert vornehmen:
- Daten in Listen/Objekte einlesen
- Daten in/mit diesen Objekten bearbeiten
- geänderte/neue Daten aus den Objekten wieder in der DB speichern
- direkte DB-Zugriffe (z.B. über datensensitive Steuerelemente) sind verboten
d.h. die ganze Datenbank in unteren Schichten verstecken und nur mit Objekten arbeiten. Die Datenbank ist nur Mittel zum Zweck, um Objekte zu persistieren. Damit wäre die verwendete Datenbank auch relativ egal, weil man eh mit dem kleinstmöglichen SQL-Subset arbeitet. Puristen verzichten sogar auf JOINs und machen auch das in der Anwendung.
Das wäre dann das Prinzip der dummen Datenbank mit dem schlauen Programm.

In manchen Datenbankbüchern wiederum wird gern das umgekehrte Prinzip beschrieben: fast die ganze Programmlogik findet sich in Views, Stored Procedures, Stored Functions und Triggern. Man ist dann natürlich abhängig von der verwendeten Datenbank. Auf Anwendungsseite ist der Zugriff flexibel, es könnten sogar datensensitive Steuerelemente herhalten, denn die Views und Trigger abstrahieren die normalisierte Tabellenstruktur einfach weg. Zudem kann ein passendes Rechtekonzept den Zugriff "am View vorbei" verbieten, so dass sämtliche Anwendungsprogramme die gleichen Zugriffe bekommen.
Das wäre dann die schlaue Datenbank mit dem dummen Programm.

In der Praxis hat man vermutlich immer eine Mischung von beidem, aber je nach Anwendungsfall ist die eine oder andere Ausrichtung stärker vertreten.

Wie ist das bei euch so?

[Lemmy]

Servus,

Variante 2 - Leider. Denn StoredProcedures, Views und co. lassen sich ziemlich schlecht in Unit-Tests überprüfen. Code in Objekten dagegen sehr gut. Daher bauen wir auch gerade dahingehend um...

[Uwe Raabe]

Zitat:

Zitat von Lemmy (Beitrag 1361688)

Denn StoredProcedures, Views und co. lassen sich ziemlich schlecht in Unit-Tests überprüfen. Code in Objekten dagegen sehr gut.

Dazu kommt noch, daß damit ja ein Teil der Sourcen in der Datenbank des Kunden vor Ort abgelegt wird. Das ist bei Updates auch ein nicht zu unterschätzender Aufwand. Immerhin kann der Kunde ja auch mal eben eine alte Datensicherung wieder einspielen - mit den dann veralteten Stored Procedures.

[jobo]

Wir machen beides.

Ich persönlich mag schlaue Datenbanken. Es gibt sicher einen Haufen Argumente dafür und dagegen. Ich nenne zunächst mal 2 pro DB
+ heterogene Anwendungslandschaft spricht stark für eine DB, die schlau ist und "der Chef"
+ komplexe (viele Abhängigkeiten) und große Systeme haben m.E. einen Performancevorteil, wenn ein direkter Zugriff erfolgt.

[jobo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361690)

Immerhin kann der Kunde ja auch mal eben eine alte Datensicherung wieder einspielen - mit den dann veralteten Stored Procedures.

Das ist doch mit dem Datenmodell nicht anders, es kann auch veraltet eingespielt werden.

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361690)

Das ist bei Updates auch ein nicht zu unterschätzender Aufwand

Und bei einem Wechsel des DBMS der absolute Horror :twisted:

[grl]

Zitat:

Zitat von Frickler (Beitrag 1361683)

fast die ganze Programmlogik findet sich in Views, Stored Procedures, Stored Functions und Triggern.

So versuchen wir es fast immer zu machen. Der große Vorteil für uns ist, daß es vollkommen egal ist, mit was der Kunde auf die Daten zugreift - die Daten sind in jedem Fall konsistent.
Außerdem ist damit unserer Erfahrung nach eine viel sauberere und konsequentere Umsetzung von Transaktionen möglich - was wieder Inkonsistenzen verhindert.

Und dann wär da noch der Geschwindigkeitsvorteil - sauber designte und umgesetzte Logik in der DB ist gerade wenn's nicht nur im LAN laufen soll ein enormer Geschwindigkeitsvorteil.

Was immer wieder als Argument dagegen herhalten muss ist der Wechsel des DBMS. Würde ich aber sowieso nie machen - weil man sich dann in allem was man macht immer auf den kleinsten gemeinsamen Nenner einigen muss und damit viel an Unterstützung und Geschwindigkeit die das DBMS bietet liegen lässt.

Zitat:

Zitat von Frickler (Beitrag 1361683)

In der Praxis hat man vermutlich immer eine Mischung von beidem, aber je nach Anwendungsfall ist die eine oder andere Ausrichtung stärker vertreten.

Genau. Mit keinem der beiden Ansäzte lässt sich gänzlich alles abdecken.

Luggi

[Lemmy]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361690)

Zitat:

Zitat von Lemmy (Beitrag 1361688)

Denn StoredProcedures, Views und co. lassen sich ziemlich schlecht in Unit-Tests überprüfen. Code in Objekten dagegen sehr gut.

Dazu kommt noch, daß damit ja ein Teil der Sourcen in der Datenbank des Kunden vor Ort abgelegt wird. Das ist bei Updates auch ein nicht zu unterschätzender Aufwand. Immerhin kann der Kunde ja auch mal eben eine alte Datensicherung wieder einspielen - mit den dann veralteten Stored Procedures.

lässt sich recht einfach damit umgehen: In der DB ist ne Version gespeichert, erwartet die Anwendung eine neuere Version, werden die entsprechenden Updates eingespielt (mit entsprechenden Absicherungen).

[hoika]

Hallo,
ich stimme meinen Vorrednern zu, ausser das hier

Zitat:

Puristen verzichten sogar auf JOINs und machen auch das in der Anwendung.

Purist müsste durch "Kafeetrinker" ersetzt werden,
weil ohne Joins es manchmal doch ziemlich lange dauern könnte,
die Join-Tabelle muss ja auch erst in Objekte geladen werden.

Unit-Tests lassen sich auch mit Testdatenbanken machen,
ist aber in der Tat sehr viel aufwendiger als Objekte.

[Mavarik]

Ich denke auch, es gibt mindestens 2 Sichten...

Kleine Anwendung:
- Datenbank dumm
Größe Anwendung
- Schlaue Datenbank

Warum?
Wenn ich alles selber mache... Ist mir fast egal welche Datenbank dahinterliegt.. Könnte auch ein Bin-Writer sein, der die Daten einfach hintereinanderschreibt und ein Index hat. Klassische ISAM.

Stell dir vor es arbeiten aber 1000 Leute oder mehr auf der Datenbank... Da hat der Leiter des Rechenzentrum Millionen ausgegeben, damit die Datenbank vernünftig skalieren und du machst alles auf dem Client PC...

Mavarik

PS.: Und klar das Schichtmodell in der Anwendung. Die darf gar nicht wissen welche Datenbank genutzt wird...

[haentschman]

Moin...:P

Zitat:

Immer wieder lese ich (nicht nur) hier, man möge das Datenbankhandling auf CRUD reduzieren und ansonsten alle Zugriffe programmgesteuert vornehmen:
- Daten in Listen/Objekte einlesen
- Daten in/mit diesen Objekten bearbeiten
- geänderte/neue Daten aus den Objekten wieder in der DB speichern
- direkte DB-Zugriffe (z.B. über datensensitive Steuerelemente) sind verboten
d.h. die ganze Datenbank in unteren Schichten verstecken und nur mit Objekten arbeiten.

Ich bevorzuge auch diese Variante. :thumb:

Zitat:

ansonsten alle Zugriffe programmgesteuert vornehmen:

Das gilt nur für die Anfrage an die Datenbank und dem Lesen des Ergebnisses. Wie die Datenbank zu dem Ergebnis kommt über SP o.ä. ist ihr Bier.

Zitat:

Die Datenbank ist nur Mittel zum Zweck, um Objekte zu persistieren. Damit wäre die verwendete Datenbank auch relativ egal, weil man eh mit dem kleinstmöglichen SQL-Subset arbeitet. Puristen verzichten sogar auf JOINs und machen auch das in der Anwendung.
Das wäre dann das Prinzip der dummen Datenbank mit dem schlauen Programm.

Persönlich mag ich keine Programmlogik in der DB. :? "Zitat: Das ist bei Updates auch ein nicht zu unterschätzender Aufwand" Die Datenbank speichert Datensätze die "normalisiert" sind. Die einzige Aufgabe ist für die Datenbank seine eigene Konsistenz zu schützen.
Frage: Wo ist der Unterschied von Progammlogik und Datenbanklogik bei Euch? Ist eine SP schon Programmlogik?

Zitat:

Und klar das Schichtmodell in der Anwendung. Die darf gar nicht wissen welche Datenbank genutzt wird... ]

...so sieht es aus. Die Anwendung darf nicht wissen wo ihre Daten herkommen.

[p80286]

Zitat:

Zitat von grl (Beitrag 1361697)

Zitat:

Zitat von Frickler (Beitrag 1361683)

fast die ganze Programmlogik findet sich in Views, Stored Procedures, Stored Functions und Triggern.

So versuchen wir es fast immer zu machen. Der große Vorteil für uns ist, daß es vollkommen egal ist, mit was der Kunde auf die Daten zugreift - die Daten sind in jedem Fall konsistent.
Außerdem ist damit unserer Erfahrung nach eine viel sauberere und konsequentere Umsetzung von Transaktionen möglich - was wieder Inkonsistenzen verhindert.

Und dann wär da noch der Geschwindigkeitsvorteil - sauber designte und umgesetzte Logik in der DB ist gerade wenn's nicht nur im LAN laufen soll ein enormer Geschwindigkeitsvorteil.

Was immer wieder als Argument dagegen herhalten muss ist der Wechsel des DBMS. Würde ich aber sowieso nie machen - weil man sich dann in allem was man macht immer auf den kleinsten gemeinsamen Nenner einigen muss und damit viel an Unterstützung und Geschwindigkeit die das DBMS bietet liegen lässt.

Zitat:

Zitat von Frickler (Beitrag 1361683)

In der Praxis hat man vermutlich immer eine Mischung von beidem, aber je nach Anwendungsfall ist die eine oder andere Ausrichtung stärker vertreten.

Genau. Mit keinem der beiden Ansäzte lässt sich gänzlich alles abdecken.

Luggi

:thumb:

Aus meiner Erfahrung heraus, der Weg die Daten sauber zu halten, ist die "schlaue Datenbank". Was natürlich in der Entwicklung relativ aufwendig ist, da RAD und Selbstdokumentation nicht zu den bevorzugten Zielen der DB-Entwickler zählen. Storage and Retrieval ist der Job von Datenbanken, darum sollte man sie auch ihren Job machen lassen.

gruß
K-H

[nahpets]

Ich frag' mich immer wieder: Wieso sind eigentlich Datenbanken so leistungsfähig, wenn die Nutzer doch alles selbst in ihren Programm "nachprogrammieren"?

Hat man mit vielen (sehr vielen) Daten zu tun, so ist es durchaus sinnvoll die Logik in die Datenbank zu legen. Das kann zu Laufzeitersparnissen im Bereich von Stunden und Tagen führen.

Datenbanken sind dahin optimiert mit Daten umzugehen. Warum soll ich mir alle Daten in den Arbeitsspeicher holen und dort dann die in der Datenbank bereits vorhanden Logik zum Umgang mit vielen Daten nachprogrammieren?

Meine Devise (aus langer Erfahrung mit extremen Datenmengen) ist: Lass alles die Datenbank machen, was die Datenbank machen kann. Sie kann das mit Sicherheit besser, als ich es in meinen kühnsten Träumen nachprogrammieren kann.

In Programmen mache ich nur das, was die Datenbank nicht mit eigenen Mitteln (einschließlich der von mir geschrieben Datenbankprozeduren ...) nicht erledigen kann.

Ansonsten sind die Programme nur zur Steuerung der Datenbank und der Anzeige der Daten für den Nutzer zuständig.

Aber wie immer:

Es gibt verschiedene Möglichkeiten. Für 'ne Adressverwaltung (auch anspruchsvolle) u. ä. ist es sicherlich nicht sinnvoll, groß Datenbanklogik zu schreiben, wenn man's auch mal eben im Programm machen kann. (Oder Datenbankunabhängigkeit eine Voraussetzung ist.)
Oder die Software muss bei Kunde X gegen Datenbank O, laufen, bei Kunde Y gegen M, bei Kunde Z gegen wasweißich, dann gehört die Logik (fast schon zwansläufig) ins Programm.

Aber gerade bei Mengenverarbeitungen, die nicht mal angezeigt werden müssen (also klare Batchanwendungen) sind gute Datenbanken dem "Eigenbau" an Leistungsfähigkeit und Performance klar überlegen.

Es kommt letztlich also darauf an, was man denn da so eigentlich will.

Geschäftlogik lässt sich wunderbar in Triggern "abarbeiten". Der Vorteil: Es ist egal, auf welchem Weg die Daten in die Datenbank kommen. Die Logik zieht immer.

Und bezüglich Datenbankwechselhorror:

Wenn ich mich zu Beginn der Entwicklung für eine Datenbank entscheide, dann ist das so grundsätzlich, dass ein Wechsel danach nicht mehr in Frage kommt, es sei denn, man entwickelt ein System neu.

Und Updatehorror mit veralteten Prozeduren:

Entweder man sichert ein System vollständig und hat dann bei 'nem Restore einen konsistenten Stand oder man sichert nur die Daten und schreibt die bei 'nem Restore zurück.

Wer bei 'nem Restore nur aktuelle Daten hat, aber mit denen veraltete Datenbankroutinen zurückschreibt, hat irgendwo gewaltigen Bockmist verbrochen.

Mir ist noch kein Fall untergekommen, bei dem, in einem vernünftig verwalteten System, nach 'nem Restore Inkonsistenzen bezüglich Daten und Datenbankroutinen entstanden sind.

Zuweilen formuliere ich es immer mal wieder ein bisserl flapsig:

Wer alle Logik ins Programm packt und die Datenbank nur für die pure Datenhaltung nutzt, der kann seine Daten dann auch in CSV-Dateien schreiben und das bisschen Abfragelogik noch selbst implementieren.

Mal so als Beispiel:

Man benötige ein paar Aggregatfunktionen für sagen wir mal so ca. 200.000.000 Datensätze aus 'nem halben Dutzend Tabellen.

Man lade das dann bitte alles in sein Programm und mache mal.

Alternative: Man schreibe dazu die passenden Views und Datenbankprozeduren.

Welcher Weg mag bei der Ausführung dann letztlich der schnellere sein?

Habe noch keine Situation erlebt, in der die Datenbank nicht um längen (Stunden bis Tage) schneller war.

Und wer Angst bezüglich veralteter Datenbankprozeduren ... hat:

Die Datenbanklogik unterliegt selbstverständlich genauso einer Versionierung, wie die übrige Software.
Und das wird alles grundsätzlich konsisten ausgeliefert.

Alles andere wäre stümperhaft.

@grl: Jo, so ist es, Deiner Aussage ist eigentlich nichts mehr hinzuzufügen.

[Rollo62]

Ich nutzt StoredProcedures zwar auch nicht wirklich, wollte da aber immer mal ran.
Den Vorteil sehe ich vor Allem auch in eriner "robusten" DB, die man mit normalen Zugriffen nicht zerstören kann.
Sie kann sich selbst immer valide halten.

Ich denke das ist auch ein nicht zu unterschätzenden Vorteil der schlauen DB.

Aber der ganze Aufwand .... :cry:

Naja, wenn ich mal mehr Zeit habe schau ich mir das nochmal an, solange bin ich im Moment bei CRUD mit REST und JSON.
Einfach ist auch meistens gut (wenn auch kein Ferrari).

Rollo

[himitsu]

Wir haben auch recht viel der Buissineslogik in der DB, aber auch einen Teil in Komponenten (Ableitungen 'ner DataSource+DataSet) und dann noch viel in den Forms (Letzeres vorallem bei alten gewachsenen Formularen)

Unsere Dokumente (Images, PDFs usw. liegen in einer eigenen Serveranwendung) und das dann auch noch transaktionssicher hinzubekommen, wenn man ein Dokument aufnehmen oder verändern will und einem da nicht nur der Code der Forms, Klassen und auch noch der Trigger dazwischenfunken tun ... hat Wochen gedauert und ich bin mir sicher, dass es noch Lücken gibt.

[haentschman]

Zitat:

Wir haben auch recht viel der Buissineslogik in der DB

mal ne dumme Frage... :stupid:
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. :wink:

[Slipstream]

Zitat:

Zitat von nahpets (Beitrag 1361708)

Ich frag' mich immer wieder: Wieso sind eigentlich Datenbanken so leistungsfähig, wenn die Nutzer doch alles selbst in ihren Programm "nachprogrammieren"?

Vielleicht gehts ja vielen so wie mir: ich konnte mich nie so richtig mit SQL anfreunden und habe früher auch immer alles im Programm erledigt, was eigentlich auch die Datenbank machen könnte. 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.

Zitat:

Zitat von nahpets (Beitrag 1361708)

Hat man mit vielen (sehr vielen) Daten zu tun, so ist es durchaus sinnvoll die Logik in die Datenbank zu legen. Das kann zu Laufzeitersparnissen im Bereich von Stunden und Tagen führen. Datenbanken sind dahin optimiert mit Daten umzugehen. Warum soll ich mir alle Daten in den Arbeitsspeicher holen und dort dann die in der Datenbank bereits vorhanden Logik zum Umgang mit vielen Daten nachprogrammieren? Meine Devise (aus langer Erfahrung mit extremen Datenmengen) ist: Lass alles die Datenbank machen, was die Datenbank machen kann. Sie kann das mit Sicherheit besser, als ich es in meinen kühnsten Träumen nachprogrammieren kann.

Sagt mein Kollege auch immer, wenn mal wieder einer versucht, die Datenbank nachzuprogrammieren :-D

Zitat:

Zitat von nahpets (Beitrag 1361708)

Ansonsten sind die Programme nur zur Steuerung der Datenbank und der Anzeige der Daten für den Nutzer zuständig.

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.

Zitat:

Zitat von nahpets (Beitrag 1361708)

Oder die Software muss bei Kunde X gegen Datenbank O, laufen, bei Kunde Y gegen M, bei Kunde Z gegen wasweißich, dann gehört die Logik (fast schon zwansläufig) ins Programm.

Genau. Und deshalb ist es nicht correct zu sagen, man muss alles in der DB machen oder alles im Programm. Vielleicht sind manche Programmierer, die ihr halbes Leben an ihrer einzigen grossen Anwendung, die ihnen den Lebensunterhalt sichert, herumschrauben, mit der Zeit ein wenig im Blick verengt worden und könnten sich dann nicht mehr vorstellen, dass es auch andere Anforderungen gibt. Kleinaufträge müssen bei uns immer rapid entwickelt werden, das ist dann meistens meine Spezialität (deshalb auch manchmal die Nachtschichten), dass das schnell über die Bühne geht, das ist so zu sagen eines unserer Aushängeschilder, wir liefern kleinen Kunden (der letzte war fast zwei Meter gross) kleine Programme sehr schnell. (Sagt mein Kollege immer, wenn so ein Langer kommt: "Die Tür ist nur bis 190 erlaubt, du musst leider den Liferanteneingang benutzen."

Zitat:

Zitat von nahpets (Beitrag 1361708)

Aber gerade bei Mengenverarbeitungen, die nicht mal angezeigt werden müssen (also klare Batchanwendungen) sind gute Datenbanken dem "Eigenbau" an Leistungsfähigkeit und Performance klar überlegen.

Kann ich bstätigen.

Zitat:

Zitat von haentschman (Beitrag 1361714)

Zitat:

Wir haben auch recht viel der Buissineslogik in der DB

mal ne dumme Frage... :stupid:
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. :wink:

Wieso ist das wichtig? Zählt ein Virus noch zu den Tieren oder ist er ein Pflanze? Oder eine Alge? Damit kann man gut streiten, aber es ist doch nicht wichtig, oder?

[mensch72]

"(Client)Programm dumm + (Server)DB schlau" contra "(Client)Programm schlau + (Server)DB dumm" ... da gibt es doch noch was... die Multi-Tier-Architektur:


- die (Server)DB kümmert sich um Datenhaltung incl. Backup&Restore, (Änderungs&Zugriffs)Protokolle, Schreibrechte und transaktionsbasierte physisch (Referenzielle)Datenintegrität
- die logische Funktionalität, also BusinessLogik steckt im APP-Server, der physisch möglichst nah neben/auf dem DB Server im Backend läuft... (erst)hier wird die relational DB Struktur in ein Objekt(relationales)Daten&Funktionsmodell abstahiert. Alle StandardClients greifen nur auf den APP Server zu. Systemtools und Volumen-Interfaces können auch parallel zum AppServer direkt innerhalb des Backenend mit dem DB Server arbeiten
- viele "dumme" Clients arbeiten nur mit dem APP-Server, denen ist somit die verwendete DB völlig egal
- wenige "intelligente" Clients oder Interfaces können innerhalb des Backend auch direkt mit den DB Daten sehr effektiv lesend arbeiten, und ihre Schreibzugriffe sind/werden nach Rechtevergabe von der DB selbst abgesichert... 90% unserer Kunden fühlen sich einfach gut, wenn sie notfalls mit Tool XY selbst mal lesend ohne viel Administrationsaufwand auf IHRE Basisdaten zugreifen können... wirklich "selbst schreiben" wollen nur ganz wenige in die DB, und wenn dann sind es meist Kopplungen von Fremdsystemen, wo deren Anbieter gerne etwas automatisieren wollen... und genau solche Schnittstellen realisieren wir DB intern mit Triggern und allen uns notwendig erscheinenden Validierungen. "Unsere Hauptlogik" steckt im APP-Server und verlässt sich nur auf stimmige von der DB garantierte (Referenzielle)Datenintegrität.


ps:
"Aber gerade bei Mengenverarbeitungen, die nicht mal angezeigt werden müssen (also klare Batchanwendungen) sind gute Datenbanken dem "Eigenbau" an Leistungsfähigkeit und Performance klar überlegen."
Ein paar Zeilen vorher hat jemand von Zugriffen auf 200Mio Datensätze geschrieben, wo er Standard DB bevorzugt... wir machen es da genau anders: ab 24Mio Datensätzen arbeiten wir mit eigenen externen BlockBinaryFiles, welche wir per Trigger konsistent über native DB-AddON schreiben, aber 100% selbst lesend binär im APP Server verarbeiten. Im Finanzumfeld haben wir "mehrfach" hunderte Mio von Datensätzen pro Datenbestand(z.B. auf die Millisekunde genau alle Währungstransaktionen der 9 Hauptwähungen der letzten 10Jahre... das sprengt jeden Standard-SQL-DB-Server)

[haentschman]

Hallo Slipstream,
ich weiß ja nicht womit ich dir auf die Füße getreten bin? :roll: Weil ich in dem anderen Thread nicht deiner Meinung war? :roll:

Zitat:

Wieso ist das wichtig? Zählt ein Virus noch zu den Tieren oder ist er ein Pflanze? Oder eine Alge? Damit kann man gut streiten, aber es ist doch nicht wichtig, oder?

...für solche dummen Kommentare bin ich grad zu haben. :|

[nahpets]

Zitat:

Zitat von haentschman (Beitrag 1361714)

Zitat:

Wir haben auch recht viel der Buissineslogik in der DB

mal ne dumme Frage... :stupid:
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. :wink:

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:

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:

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.

[Slipstream]

Zitat:

Zitat von haentschman (Beitrag 1361720)

Hallo Slipstream,
ich weiß ja nicht womit ich dir auf die Füße getreten bin? :roll: Weil ich in dem anderen Thread nicht deiner Meinung war? :roll:

Zitat:

Wieso ist das wichtig? Zählt ein Virus noch zu den Tieren oder ist er ein Pflanze? Oder eine Alge? Damit kann man gut streiten, aber es ist doch nicht wichtig, oder?

...für solche dummen Kommentare bin ich grad zu haben. :|

Tut mir leid ich fühle mich nicht auf die Füssen getreten. Und dumm bin ich auch nicht, zumindest sagt das meine Frau immer: Du bist doch nicht dumm, machs doch richtig. Also glaub ich meiner Frau lieber als dir, den ich nicht kenne. Ich find meine Kommentare nicht dumm, sondern bildhaft. ich versehe nicht, wieso ich jetzt auf deinen Füssen stehen soll. Über diese Sachen Tier oder Pflanze streiten sie wirklich, die Wissenschaftler, das hab ich nicht erfunden.

Zitat:

Zitat von nahpets (Beitrag 1361722)

@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.

Danke für diese Hilfe, Pflanzen und Tiere sind beide aus Einzellern Bakterien entstanden, wie man heute weiss, deshalb kann man bei diesen frühen Lebewesen nicht festlegen, ob Tier oder Pflanze. Du hast mich genau richtig verstanden, es ist nicht wichtig dass man immer genau zu unterscheiden kann zwischen Datenbank- und Anwendungslogik. Man kann aber prüfen, ob das eine oder das andere besser ist in jedem speziellen Fall.

Ich habe irgendwie den Eindruck, Fremde sind hier nicht so gerne gesehen, oder? Ich spüre ein wenig Feindseligkeit und verstehe das nicht. Aber egal, ihr werdet mir schon sagen, wenn ihr mich nicht hierhaben wollt, stimmts? Vielleicht bin ich auch nur zu viel Freundlichkeit den ganzen Tag verwöhnt und habe verlernt, wie es in Deutschland ist. ich weiss es nicht.

[haentschman]

:P Dann ist es ja gut.
Mir ging es nur darum, das wir alle über das Gleiche reden. :P

[himitsu]

Was man gegen die Logik in der DB sagen kann, ist das Debuggen des Programms.
Gut, es ist zwar bei vielen DBMS auch möglich das zu machen, aber "zusammen" mit dem Programm dann halt nicht, alles in einem Debugger.

Zitat:

Das kann man mit DB-Mitteln nicht realisieren.

Das geht schon, denn viele DBMS bieten es an, dass man Fremdfunktionen einbinden kann.
Da wird eure Funktion dann wir eine normale SP aufgerufen, bzw. wie die BuildIn-Funktionen ala TRIM oder COALESCE.
Ihr schreibt eine DLL z.B. mit Delphi, veröffentlicht eure Funktionen (Exports) und bindet das dann ins DBMS ein.

[bernau]

Auch von mir ne kurze Antwort:

Wenige verschiedene Programme, die auf die Daten zugreifen. Am besten alle Programme mit der gleiche Buisness-Ligik-Unit. Dann kommt die Logik in's Programm. DB bleibt dumm.

Viele Verschiedene Programme, unterschiedlichster Herkunft, die auf die DB zugreiffen, dann die Logik in die DBMS. Man weis doch sonst nie, wer den Fehler verbockt hat.

[jobo]

Zitat:

Zitat von haentschman (Beitrag 1361714)

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. :wink:

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.

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1361727)

Was man gegen die Logik in der DB sagen kann, ist das Debuggen des Programms.
Gut, es ist zwar bei vielen DBMS auch möglich das zu machen, aber "zusammen" mit dem Programm dann halt nicht, alles in einem Debugger.

Zitat:

Das kann man mit DB-Mitteln nicht realisieren.

Das geht schon, denn viele DBMS bieten es an, dass man Fremdfunktionen einbinden kann.
Da wird eure Funktion dann wir eine normale SP aufgerufen, bzw. wie die BuildIn-Funktionen ala TRIM oder COALESCE.
Ihr schreibt eine DLL z.B. mit Delphi, veröffentlicht eure Funktionen (Exports) und bindet das dann ins DBMS ein.

Debuggen kann ich auch die SP, wenn es von den Tools unterstützt wird. Freilich kenne ich auch keins, das es durchgängig macht (Clientcode plus SP).
Aber: ich kann in SQL ellenlange Testscripts schreiben, SP aufrufen bis der Arzt kommt, inkl. Prüfviews usw. und wenn das Ergebnis falsch ist, sag ich rollback und korrigiere die SP oder den View.
Auf diese Weise kann ich tatsächlich komplette Business Prozesse abbilden. Daher ist mir das "Unittesting" Argument auch nicht so klar.

Was komplexe Anwendungen angeht, OCR, Thesaurus und Co, da kann ich nur empfehlen, sich mal die Leistungsfähigkeit führende DB Anbieter plus Erweiterungen anzusehen.
SEPA XML mache ich per SQL, Excel lese ich per SP.
Und falls ich es noch nirgendwo erwähnt hatte ;) PostgreSQL finde ich ist ein Spitzensystem. Dafür würde ich sogar Geld ausgeben, aber es ist leider kostenlos.
PostgreSQL ist im Übrigen auch ein gutes Argument gegen das "Du kannst nicht wechseln". Ich schätze, dass man eine Mehrheit von Oracle Systemen durch PG ersetzen kann, mit überschaubarem, also kalkulierbaren Aufwand und vertretbaren Kosten. Ähnlich sieht es vielleicht bei anderen Systemen aus.
Es gibt sehr abgefahrene Features in manchen DB, Systeme wie von Oracle müssen sich ja irgendwodurch auszeichnen und all das Schmerzensgeld rechtfertigen, z.B. sowas wie Multitenancy, Versionierung von Logik oder andere Sachen. Aber in der Praxis habe ich davon noch nichts eingesetzt.

[jfheins]

Ich verwende liebend gerne das Entity Framework.

Im Wesentlichen baut man seine Klassen so auf, dass eine Klasse einer Tabelle in der DB entspricht. Das genaue DBMS ist dabei zweitrangig (aber nicht ganz unwichtig)
Nun hat man einen DataContext (= Datenbankschema) auf das man Abfragen durchführen kann.

Joins, Where-Einschränkungen und Spaltenauswahl wird dabei im Code definiert, die SQL wird generiert und an die Datenbank weitergereicht. Zurück kommen die Klassen, die man den Tabellen zugeordnet hat. Die Datenbank hat so viele Constraints wie sinnvoll um die Datenintegrität sicherzustellen. Also explizite Foreign-Keys und Unique Indices.

Insofern ist die Datenbank eher "dumm", weil sie keine SP und Trigger enthält, aber natürlich werden Joins in der Datenbank abgewickelt.

Beispiel:

Code:

public IQueryable<Bar> FilteredBars(int user)
{
   return from bar in Bars
         join foo in Foos on bar.ID equals foo.ID
         where foo.List == null || foo.List.Items.Any(item => item.UserID == user)
         select bar;
}

[hanvas]

Zitat:

Zitat von Frickler (Beitrag 1361683)

Immer wieder lese ich (nicht nur) hier, man möge das Datenbankhandling auf CRUD reduzieren...

In manchen Datenbankbüchern wiederum wird gern das umgekehrte Prinzip beschrieben...

Das eine schließt das andere nicht grundsätzlich aus und beide Vorgehensweisen haben Ihre - je nach Anwendungsfall - Berechtigung. Abgesehen davon gibt es ja auch noch Zwischenformen wenn man einen Applikationsserver dazwischenschaltet.

Die Datenbank die Arbeit machen zu lassen hat zunächst einmal den Vorteil das wenig Daten bewegt werden. Wenn ein Client lokal auf eine DB zugreift ist das meist unwichtig, und auch in einem kleineren Netzwerk führt das nicht zu Problemen - wenn aber eine entsprechend große Anzahl an Clients über unterschiedlich schnelle (und manchmal langsame) Übertragungswege auf eine DB zugreift kann jedes gesparte Byte zählen.

Das ist ja der Grund warum man relationalen Datenbanken meist in 3 oder höheren Normalform entwirft, um eine minimale Anzahl an Bytes zu haben die bei jeder Transaktion gelesen, geschrieben oder transportiert werden müssen.

Der zweite Grund der für eine zentralisierte Datenhaltung spricht ist die Tatsache das ein Wildwuchs an Clients die Daten nicht zwangsläufig zerstört. Zwei Clients in unterschiedlichen Versionen greifen bei einem sauberen Design dennoch definiert zu.

Einfache Skalierbarkeit und Ausfallsicherheit (beispielsweise via. Replikation) sind ein weiterer Grund für eine zentralisierte Datenhaltung.

So lange es nur um das Lesen und Schreiben von Objekten geht wiederspricht Deine im Ursprungsposting gemachte Anmerkung Objekte beispielsweise in Listen einzulesen und nur auf diesen Listen zu operieren dem nicht. Lediglich wenn die gleichen Daten von der DB und dem Client manipuliert werden kann es einen Wiederspruch zwischen beiden Modellen geben. Aber dann kann man sich behelfen.

Nach meiner Meinung gehören Operationen die dazu dienen die Normalisierung der Datenbank sicher zu stellen und/oder die dazu dienen nur definierte Schnittstellen (Views, Funktionen, Prozeduren) anzubieten in die Datenbank, das gleiche gilt für Operationen deren Hauptzweck die Datenintegrität ist, ebenso Replikation, Logs etc, da hier von der Client nichts wissen muss.


Operationen oder Geschäftsregeln (in dem Sinne von wenn ich eine Position mit einer Menge von 5 einer Ausgangsrechnung hinzufüge dann verringert sich der Lagerbestand um 5) kann man sowohl in das Datenmodell packen wie auch in den Client. Der Client hat den Vorteil das man flexibler ist, aber eben auch mehr Mist anstellen kann. Da Du aber nach einem Schichtenmodell gefragt hast kannst Du die Schicht mit den Geschäftsmodellen auch in einen App-Server auslagern.

Mit manchem Frameworks geht das recht einfach. Im Moment bin - zumindest bei Delphi - ziemlich begeistert von TMS Aurelius. Fast alles was ich gerade eben beschrieben habe funktioniert damit sehr transparent.

cu Ha-Jö


* Ich hole mir immer das/die Objekte mit dem ich gerade arbeite (und keine anderen) über eine Abfrage. Dabei werden immer so wenig Objekte wie möglich (aber so viele wie nötig) eingelesen und die Liste wächst im Arbeitsspeicher - ändere ich ein Objekt dann wird dieses Objekt (und nur dieses) wieder zurückgeschrieben.

[jobo]

Zitat:

Zitat von hanvas (Beitrag 1361736)

..kann man sowohl in das Datenmodell packen wie auch in den Client. Der Client hat den Vorteil das man flexibler ist, aber eben auch mehr Mist anstellen kann.

Das greif ich doch noch mal auf.

Die Flexibilität im Client hat man nicht zuletzt deshalb, wenn DBServer seitige Möglichkeiten der Regulierung nicht vorhanden sind und oder genutzt werden (dumme Datenbank halt).
Ein Datenmodell serverseitig so abzusichern, dass keine falschen Daten überhaupt erst reinkommen und auch nicht dahingehend manipuliert werden können, dass ein gewünschtes Regelwerk verletzt wird, ist doch der Sinn des ganzen. Das auch noch vor dem Hintergrund, dass selbst komplexe Datenbankoperationen bei einer Verletzung definierter Regeln einfach alles per Rollback zurückdrehen können, zuverlässig, nix passiert, versuchen sie es erneut. Dafür sind DB geschaffen worden (und sie können es mittlerweile sehr gut).
Wenn man alles im Client macht, muss man sich tatsächlich fragen, wofür man eine DB braucht oder wieviel ihrer Fähigkeiten.
Hier war z.B. die Rede von Highvolume Daten im mehrstelligen Millionenbereich, Bank, Börse ...
Wenn ich keine konkurrierenden Schreibzugriffe darauf habe und wenn die Daten von Natur aus eher Log Charakter als alles andere haben, ja, dann muss ich mich oder die DB nicht damit quälen. Referentielle Integritätsprüfung und anderer Zirkus wird hier vermutlich auch nicht stattfinden.
Hier kommt dann ggF. auch hinzu, dass ich diese Daten dem AppServer viel direkter zur Verfügung stellen kann, als es in einem klassischen Appserver - DB Gespann erfolgt. Jegliche Logik, Prüfung etc. die der AppServer durchführt, erfordert den Transport der notwendigen Daten zum Appserver (wurde hier auch schon beschrieben, wahlweise könnte man hier auch Clientprogramm sagen, wenn die Daten eben in Delphi durchgenudelt werden um das Ergebnis 42 zu errechnen). Da kann mir niemand erzählen, dass die gleiche Logikprüfung mit zwischengeschaltetem Transport der Daten gleich schnell oder schneller ist, als ohne diesen Transport. Anders sieht es natürlich aus, wenn die DB wirklich dumm ist und bestimmte Algorithmen nicht beherrscht, die auf dem Client/Appserver verfügbar sind. Dann kann ich außerhalb der DB schneller sein.

Ja und so weiter und so weiter. Mein Fazit, ich weiß, warum ich schlaue DB lieber mag. Aber, it depends.

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.
In Delphi und anderen Sprachen wird teilweise sehr viel Wert gelegt auf die hohe Kunst des Programmierens. Exaktheit der Datentypen, etc. pp.
Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

[mkinzler]

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Begründung, um "flexibel" zu bleiben ... :mrgreen:

[p80286]

Zitat:

Zitat von jobo (Beitrag 1361753)

Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Was bitte ist ein Datetyp? :stupid:

Gruß
K-H

[Lemmy]

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Zitat:

Zitat von jobo (Beitrag 1361753)

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.

ganz einfach weil es "die" Lösung nicht gibt....

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1361760)

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

Gruß
K-H

[Frickler]

Vielen Dank für die vielen guten Anregungen. Ihr seid echt super!

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1361759)

Zitat:

Zitat von jobo (Beitrag 1361753)

Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Was bitte ist ein Datetyp? :stupid:

Ja, äh also, .. komm wir gehen mal nach draußen...
;)

Zitat:

Zitat von Lemmy (Beitrag 1361760)

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Zitat:

Zitat von jobo (Beitrag 1361753)

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.

ganz einfach weil es "die" Lösung nicht gibt....

Ja, es gibt ja verschiedene Datumstypen, lass Dir das mal bitte von p80286 erklären. ;)
Aber wofür/gegen spricht das nun?

Und ja, DIE Lösung gibt es nicht, aber wie widersprüchlich viele mit Ihrem Code/Daten da umgehen, erschließt sich mir nicht.

[Lemmy]

Zitat:

Zitat von p80286 (Beitrag 1361763)

Zitat:

Zitat von Lemmy (Beitrag 1361760)

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

es gibt halt Länder da wird es mit der Geburtsurkunde nicht so genau genommen. Und wenn jemand nur weiß, dass er in Jahr x geboren wurde, dann kommt so ein Datum zu Stande.

[MichaelT]

Die Welt ist grau.

In dem Zusammenhang wird tatsächlich von Business Logik gesprochen. Sobald man so in die Ecke 4GL reinschnuppert...

Eine persistente Abfrage welche ein Ergebnis liefert ist eine Query. Eine Query ist ähnlich einer View, eigentlich eine parametrierte View. Der SQL Server bildet Querys relativ exakt entlang dieser Definition ab.

In Österreich verwenden wir den Begriff Query eher im Kontext TQuery.SQL nämlich der SQL Abfrage. Delphi Query ist eine selche View, deswegen ist sie in einem Datamodule an sich ganz gut aufgehoben. Eine Query wäre dann schon Teil der Business Logik. In dem Zusammenhang kann die Verwendung einer SP, selbst wenn sie einfachste Aufgaben erfüllt (Konvertieren einer Auftragsnummer zum Zwecke der Präsentation oder dem Export) Teil der Businesslogik werden.

Sie leidet am selben Trouble der immer wieder für Diskussion sorgt. Sie schreiben in der Regel nicht im Rahmen *einer* Anwendung auf eine DB.

Fast alle Delphi DB Komponenten haben mit DB im Kontext dieser Diskussion nicht viel zu tun sondern wären Teil der Businesslogik.

Solange allein ein Informationsmodell absicher gegen den Missbrauch durch eine Applikation (Schutz des Informationsmodell) sind sie in der Regel im Umfeld der Business Logik.

Zitat:

Zitat von haentschman (Beitrag 1361714)

Zitat:

Wir haben auch recht viel der Buissineslogik in der DB

mal ne dumme Frage... :stupid:
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. :wink:

[bra]

Was hier als Kriterium seltsamerweise noch gar nicht zur Sprache kam ist, welche Datenbanken überhaupt unterstützt werden. Wenn man sich nur auf eine spezielle konzentriert ist es sicher weniger ein Problem die Logik in der Datenbank unterzubringen, als wenn man verschiedene Datenbanken unterstützt.

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1361770)

Zitat:

Zitat von p80286 (Beitrag 1361763)

Zitat:

Zitat von Lemmy (Beitrag 1361760)

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

es gibt halt Länder da wird es mit der Geburtsurkunde nicht so genau genommen. Und wenn jemand nur weiß, dass er in Jahr x geboren wurde, dann kommt so ein Datum zu Stande.

Verständlich aber trotzdem, Ja und?
wenn eine Person ihr Geburts-(Kalender)-Datum nicht kennt, also diese Information nicht vorliegt, dann wird sie auch nicht eingetragen!
Ja irgendwann 1982 geboren? Wenn diese Information abgespeichert werden soll, daran muß der Designer der DB denken! , dann eben nicht in ein DateField, sondern in ein "YearofBirth"-Feld, und "MonthofBirth" und "Dayofbirth" darf leer (NULL) bleiben.
Sind das Numerische Felder? Kommt darauf an, wenn man mit ihnen rechnen will, wäre es empfehlenswert.

Gruß
K-H

[Benedikt Magnus]

Wenn das Geburtsdatum nicht genau bekannt ist, wird dann nicht (amtlich) eines festgelegt?