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

[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: