Datenbanklogik



  • Skym0sh0 schrieb:

    deejey schrieb:

    Ja, du übersiehst mindestens noch die Stored Procedures, die alles noch verkomplizieren 🙂

    Die hab ich doch genannt...

    oh, sry



  • @deejey

    bei SAP gibt es aber nicht die Problematik das deine SQL-Syntax nicht 100% zwischen verschiedenen DBs passt - oder deine StoreProcedures in verschiedenen Sprachen z.B. T-SQL für Microsoft SQL-Server und PL/SQL für Oracle, oder PL/pgSQL bei PostgreSQL - und viele mehr

    bei SAP bleibt SAP immer deine Basis - oder?



  • Gast3 schrieb:

    @deejey

    bei SAP gibt es aber nicht die Problematik das deine SQL-Syntax nicht 100% zwischen verschiedenen DBs passt - oder deine StoreProcedures in verschiedenen Sprachen z.B. T-SQL für Microsoft SQL-Server und PL/SQL für Oracle, oder PL/pgSQL bei PostgreSQL - und viele mehr

    bei SAP bleibt SAP immer deine Basis - oder?

    Ja, aber nur so lange man das sog. "Open SQL" im ABAP durchgehend benutzt, für die Kompatibilität sorgt dann die untere Schicht und man muss sich keine Gedanken machen. Jedoch kann auch "native SQL" benutzt werden, das geht direkt an den DB-Server, Kompatibilität ist ungewiss.

    Dann gibt es noch so ein DB-spezifisches "HINT" was auch bei Open SQL wirkt, wenn man die DB zur Benutzung eines bestimmten Index zwingen will. Aber wie gesagt, manche Kunden untersagen den Entwicklern DB-spezifische Zugriffe.



  • Ich habe mittlerweile nicht mehr soviel verstanden, weil ich die Systeme alle nicht kenne oO

    Vielleicht kann ich die Diskussion etwas umlenken:

    Nehmen wir mal an, wir nutzen keine Businesslogic in der Datenbank, d.h. Stored Procedures werden nicht genutzt.

    Ist es jetzt besser (komplexe) Abfragen über die Datenbank zu machen oder sich lieber z.B. alle Daten geben zu lassen und dann selbst im eigenen Programm diese zu verarbeiten, z.B. mit LINQ in (C#).NET?

    Intuitiv würde ich sagen, Datenbanksysteme sind genau darauf optimiert, also sollten die das auch machen?!
    Umgekehrt würde ich denken, naja wenn man eine normalisierte Datenbank hat, dann können größere Objekterzeugungen ziemlich groß und komplex werden, da ja viele Tabellen gejoint werden (müssen).


  • Mod

    Erfahrung sagt: Es ist sehr lohnend, sich über diese Art Problematik seine Gedanken zu machen.

    Generell hängt es natürlich erstmal von der Datenbank (den Daten und dem Hintergrund selber ab) was sie können sollte und was nicht.
    Man kann aber auch generell sagen, dass Performance und Erweiterbarkeit schon eine wichtige Rolle spielen.

    Was man auch generell sagen kann, ist, dass eine Datenbanklogik immer auch einer Überlogik folgt, also z.B. Rechenwerk im Chip, Betriebssystem, Schulbildung usw.
    (siehe auch https://de.wikipedia.org/wiki/Lotus_1-2-3 , http://www.aresluna.org/attached/computerhistory/articles/spreadsheets/lotus123review (das Lotus 1 2 3 Programm wurde in Assembler geschrieben und war ziemlich schnell)
    (Ein wichtiges Feature von der Programmierprache Haskell ist "Lazy Evaluation". "Real World" Erfahrungen zeigen aber (z.B. Haskell Schrittweise erlernen, Serveranwendungen, dies und das, dass die (zugrundeliegende) Lamda-Logik zwar toll ist aber eben eher "ideal" denn "funktional" (??), http://community.haskell.org/~simonmar/slides/cadarache2012/5 - server apps.pdf , https://hackhands.com/lazy-evaluation-works-haskell/ )
    (viele Workarounds, Nachsitzstunden -> Lamba-Logik üben, um die wichtigste Grundlage besser (und intuitiver) zu verstehen und -> Assemblerschnittstelle finden und -> Parallelperformance nutzen, Wunschzettel: Datenbankoptimierung (mehr Dokumentation und Ordnung (plus Aussortierung eher fragwürdiger Einträge) (Real World Orientierung, Professionelle Programmierung) erforderlich).

    (ach so, hilft vielleicht: -> http://book.realworldhaskell.org/read/defining-types-streamlining-functions.html )



  • Wie ich schon geschrieben haben, ist es aus Performancesicht meist besser, die Datenbank möglichst viel machen zu lassen. Wenn deine Anfragen dazu führen, dass du weitere Anfragen machen musst, hast du zusätzliche Round Trips - sehr schlecht. Ein Join ist da viel besser. Und die Datenbank kann die Anfragen viel besser cachen, optimieren usw., weil die Datenbankhersteller genau da viel Arbeit reingesteckt haben.



  • In der Regel sind DB seitige Abfragen performanter. Die DB muss ja alle Daten suchen und an den Client übertragen. Findet die Selektion/Auswertung erst im Client statt, müssen mehr Daten zusammengeschaufelt werden.

    Joins in der DB sind deutlich performanter als im Client.

    DB seitige Logic über Stored Proc´s hat den Vorteil, dass die Anfrage nicht jedes mal neu interpretiert werden muss. Bei Interpretation der Anfrage sucht die DB jedes mal einen optimalen Lösungsweg. Im Falle einer SP ist der Lösungsweg bereits hinterlegt.

    Bei einer Kapselung über SP´s als Schnittstelle arbeiten alle Progger Clientseitig mit den gleichen Daten. Sp´s haben benutzerdefinierte Rückgabewerte.

    Datenhaltung in einem Clientseitigen Dataset hat auch den Nachteil, dass die Daten nach Bearbeitung nicht mehr unbedingt konsistent sind. Also ein ganzes Dataset vollgepackt bearbeitet und zurückgespielt, inzwischen können aber woanders Änderungen erfolgt sein.

    Der Aufwand für DB Seitige Logic ist natürlich hoch. Bei einer Webseite mit DB auf dem gleichen Server würde ich aus Kostengründen ein Dataset vorziehen. Es kann auch Sinn machen zu mixen, gerade bei inserts und updates Sp´s zu verwenden für die Konsistenz.

    MS SQL kann neben SQL Sp´s noch , Tabel Funktions, Scalar Funktions, .Net Assemblies und lässt sich über extendet stored Proc´s als Dll erweitern. Aber fang nicht an mit Kanonen auf Spatzen zu ballern.



  • Skym0sh0 schrieb:

    Ist es jetzt besser (komplexe) Abfragen über die Datenbank zu machen oder sich lieber z.B. alle Daten geben zu lassen und dann selbst im eigenen Programm diese zu verarbeiten, z.B. mit LINQ in (C#).NET?

    Wenn Du mit LINQ das ohne TO SQL meinst, sind alle Abfragen mit einfachen
    Schleifen realisiert. Soweit habe ich das zumindest verstanden. Bei "LINQ to SQL"
    wird ein DB-Context angegeben, die Abfragen entsprechend formuliert und der
    Server führt dann das kompilierte Statement aus.

    Läßt Du Dir ganze Tabellen in DataSets zurückliefern und konkretisierts dann
    mit dem tollen LINQ deine Abfragen, Sorts, Joins usw. wird alles in Schleifen
    ohne irgendwelche Indexe realisiert !

    Kann m.M auch garnicht anders funktionieren, wenn Du eine Liste vom Typ
    erstellst. Da ist kein PK oder sonstwas definiert.



  • Ich bin mal wieder an dem Thema am knabbern und grabe deswegen diesen Thread von vor 7 Monaten nochmal aus.
    Meine Frage jetzt, und damals auch schon zum Teil, richtete sich in eine andere Richtung. Und zwar weniger, ob Logik in der Datenbank (ala Stored Procedures) oder in das Programm gehört, sondern vielmehr wie Datenbankanbindungen im Code aussehen.

    Annahme:
    Nehmen wir an, dass wir es eine Reihe von Anwendungen gibt (d.h. eine Umgebung mit mehreren Modulen) die auf einem Server läuft und logischerweise auch auf eine Datenbank zugreifen muss. Die Datenbank kann mal MySQL, mal MSSQL, mal SQLIte sein oder was auch immer. D.h. Stored Procedures wollen wir damit mal ausschließen. Vor allem weil das Datenbanksystem auch mal gewechselt werden kann/können soll.

    Ist es jetzt Best-Practice beim Modellieren einer Anwendung ein schönes ER-Diagramm aufzumalen (oder zu denken), das dann in der Datenbank umzusetzen (nehmen wir auch mal an ohne Foreign-Keys und ohne, dass sich das DBMS um Integrität kümmert bei normalisierten Tabellen*) und im Programmcode dann SQL-Statements zusammen zu setzen? (Können wir hier unterscheiden zwischen dem Low-Level String konkattenieren um eine SQL zu bauen und eine Abstraktionsebene wie JOOQ dazwischen zu setzen?!)

    Oder ist es besser, die Businessdaten als Klassen (z.B. im M vom MVC) zu modellieren und dann später eine Datenabstraktionsschicht (Stichwort DAO Pattern) dadrauf zu setzen?

    Mir ist klar, dass es da sicherlich keine Silver Bullet gibt. Gerade wenn Performance ins Spiel kommt, aber solche Fälle lassen sich eingrenzen, denke ich. Vielleicht können wir sogar mal konkrete Beispiele bauen.

    Um das nochmal zusammen zu fassen:

    - Keine Stored Procedures (weil verschiedene DBMS Ökosysteme)
    - Datenmodellierung nur in der Datenbank
    - Datenmodellierung im Code (Daten Klassen)
    - Datenbankzugriffe wegkapseln
        + DAO Pattern/Repository/ORM etc.
    - SQL im (Controller-) Code zusammenbasteln und feuern
    - Abstraktes SQL wie z.B. JOOQ im Client Code zusammenbasteln
    

    *: Ist das überhaupt eine sinnvolle Annahme? Oder könnte man dann gleich auf Datenbanksysteme scheissen und gute alte Textdateien nehmen?



  • Kann es sein dass du einfach nur ORM suchst?



  • Shade Of Mine schrieb:

    Kann es sein dass du einfach nur ORM suchst?

    Naja, das ist eben die Frage.

    Benutzt man das in der "großen" praktischen Berufswelt?
    Oder ist das mal eben für kleine (Uni-)Projekte ganz lustig, aber dann im Großen kaum wartbar?



  • Das benutzt man in der "großen" praktischen Enterprise Welt.

    Abseits von Enterprise aber dann etwas weniger. Wir machen jetzt nicht so viel mit Datenbanken in der Arbeit, haben aber auch eine Datenbankanbindung in unserer Software. Man könnte wahrscheinlich schon irgendwie ORM reinbringen... Bietet sich aber nicht wirklich an. Kaum irgendwelche üblichen Record- oder Objektbasierten Abfragen und Aktualisierungen, dafür viele völlig unterschiedliche Abfragen. Abstraktionsschichten haben wir natürlich drin, aber kein ORM.



  • Skym0sh0 schrieb:

    Die Datenbank kann mal MySQL, mal MSSQL, mal SQLIte sein oder was auch immer.

    Für grössere Systeme ist das eine unvernünftige Forderung die zu einer unvernünftigen Lösung führen wird.
    Und bei kleineren Systemen ist es sowas von egal wie man es macht...



  • Skym0sh0 schrieb:

    Shade Of Mine schrieb:

    Kann es sein dass du einfach nur ORM suchst?

    Naja, das ist eben die Frage.

    Benutzt man das in der "großen" praktischen Berufswelt?
    Oder ist das mal eben für kleine (Uni-)Projekte ganz lustig, aber dann im Großen kaum wartbar?

    Es gibt nur einen relevanten Grund warum man kein ORM verwenden will: man braucht absolute rohe Performance. Davon abgesehen ist ORM immer eine sehr gute Wahl.



  • Shade Of Mine schrieb:

    Es gibt nur einen relevanten Grund warum man kein ORM verwenden will: man braucht absolute rohe Performance.

    Oder wenns keine "Objekte" gibt. Wir haben im Endeffekt paar Tabelle, die irgendwie verknüpft werden. Das ganze repräsentiert im Endeffekt schon sowas wie "Objekte". Das speichern/laden ist aber uninteressant und macht kaum was aus. Es gibt viele verschiedene Queries, die entweder irgendwas bereinigen, oder zusammenfassen, auswerten, was auch immer... Alles ziemlich unterschiedlich, bietet sich nicht an, irgendwelche Objekte dafür zu definieren.



  • Mechanics schrieb:

    Oder wenns keine "Objekte" gibt. Wir haben im Endeffekt paar Tabelle, die irgendwie verknüpft werden. Das ganze repräsentiert im Endeffekt schon sowas wie "Objekte". Das speichern/laden ist aber uninteressant und macht kaum was aus. Es gibt viele verschiedene Queries, die entweder irgendwas bereinigen, oder zusammenfassen, auswerten, was auch immer... Alles ziemlich unterschiedlich, bietet sich nicht an, irgendwelche Objekte dafür zu definieren.

    Wenn du Beziehung zwischen Tabellen hast, hast du "Objekte".



  • Meinst du man sollte für quasi alles in der Applikation das ORM Framework verwenden, oder halt nur dort wo es sich anbietet? Diverse Batch-Operationen finde ich nämlich in SQL sehr praktisch. Ich kenne natürlich nicht jedes ORM Framework, aber ich kann mir nicht vorstellen dass ein ORM Framework etwas ala "UPDATE Foo SET x = 123 WHERE y = 42" schlagen kann.
    (Also nicht nur was Performance angeht sondern auch beim Thema Verständlichkeit/Lesbarkeit.)

    Ansonsten...
    Einen 2. Grund der für mich gegen ORM spricht - speziell bei kleinen Projekten: Die Einarbeitungszeit bzw. die diversen Eigenheiten/Nachteile/Fallen/Bugs die verschiedenen ORM Lösungen mit sich bringen.
    Für jemanden der bereits viel Erfahrung mit zumindest einem ORM hat welches er für ausreichen gut hält ist das kein Thema. Für Neulinge u.U. schon.

    Ich kenne mich z.B. mit Datenbanken und SQL mMn. gut bis sehr gut aus, aber von ORM Frameworks hab' ich echt nicht sehr viel Ahnung. Dementsprechend ... würde heute jemand zu mir kommen und mir ein kleines bis mittelgrosses Projekt umbinden wo ne DB benötigt wird, würde ich mir 3x überlegen ob ich es riskiere mich auf ein mir unbekanntes Framework zu setzen. Weil mir meine Erfahrung sagt dass man die Eigenheiten wegen denen man es später bereut irgend eine Technologie eingesetzt zu haben in der Evaluierungsphase kaum finden kann. Also nicht mit realistischem Aufwand.



  • hustbaer schrieb:

    ich kann mir nicht vorstellen dass ein ORM Framework etwas ala "UPDATE Foo SET x = 123 WHERE y = 42" schlagen kann.
    (Also nicht nur was Performance angeht sondern auch beim Thema Verständlichkeit/Lesbarkeit.)

    ORM bedeutet nicht dass du kein SQL schreiben kannst. ORM bedeutet dass du die Assoziationen die du in der Datenbank hast, transparent für die Anwendungslogik zur Verfügung hast.

    Oft schreibt man dann eben kein "SQL" sondern ein ORM-SQL dass leicht andere Features hat und vom ORM dann nach SQL übersetzt wird, aber das sind dann ja Details.

    ORM heißt nicht "noSQL" 😉

    Einen 2. Grund der für mich gegen ORM spricht - speziell bei kleinen Projekten: Die Einarbeitungszeit bzw. die diversen Eigenheiten/Nachteile/Fallen/Bugs die verschiedenen ORM Lösungen mit sich bringen.

    Wenn ich das selbe sagen würde nur ORM durch RAII tauschen würde man mich hier wohl köpfen 😉

    Know How ist natürlich immer ein Entscheidungsgrund bei Technologien aber wenn man viel mit DBs macht dann will man sich mit ein paar ORM Libraries auskennen. ORM wird halt dann nett sobald die DB komplex wird. Wenn jeder Query den du schreibst 7 joins hat, dann bist du heilfroh über ein ORM. Ach, ich könnte jetzt 100 Gründe aufzählen aber wenn das Hauptargument gegen ORM ist, dass es Neuland(tm) ist, dann kann man da halt nichts machen.



  • Shade Of Mine schrieb:

    Wenn ich das selbe sagen würde nur ORM durch RAII tauschen würde man mich hier wohl köpfen 😉

    Wäre auch ein recht unpassender Vergleich.
    Gäbe es das ORM Framework wäre der Vergleich vielleicht noch gerade so OK, aber so... ist das Problem ja schonmal "welches nehmen wir?".

    Shade Of Mine schrieb:

    Know How ist natürlich immer ein Entscheidungsgrund bei Technologien aber wenn man viel mit DBs macht dann will man sich mit ein paar ORM Libraries auskennen. ORM wird halt dann nett sobald die DB komplex wird. Wenn jeder Query den du schreibst 7 joins hat, dann bist du heilfroh über ein ORM. Ach, ich könnte jetzt 100 Gründe aufzählen aber wenn das Hauptargument gegen ORM ist, dass es Neuland(tm) ist, dann kann man da halt nichts machen.

    Du hast geschrieben "es gibt nur einen relevanten Grund" und das stimmt mMn. so halt einfach nicht.



  • hustbaer schrieb:

    Du hast geschrieben "es gibt nur einen relevanten Grund" und das stimmt mMn. so halt einfach nicht.

    OK, der Grund "ich mag nicht" ist natürlich auch immer ein gültiger Grund.

    PS:
    aber es scheint ja keinen einzigen technischen Grund zu geben der gegen ORM spricht wenn ich mir den Thread so durchlese...


Anmelden zum Antworten