Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] orm mapper vs plain sql

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] orm mapper vs plain sql

    Ich möchte gerne mal so eure Meinung hören, wie ihr zu ORM-Mappern so steht. Wann haltet ihr die Verwendung für sinnvoll, wann nicht? Meine damit: Macht es in riesigen Projekt Sinn Mapper zu verwenden, oder doch plain sql.

  • #2
    Moin,
    es gab letztens im Datenbank-Bereich eine interessante Diskussion dazu: http://www.php.de/datenbanken/111419...sser-ohne.html

    Ich arbeite gerne mit SQL, deshalb hab ich mir auch noch nicht die Zeit genommen mich mit ORMs zu beschäftigen, da hat anderes Vorrang. -> keine eigene Meinung
    [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
    [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

    Kommentar


    • #3
      Ich verwende kein ORM sondern PlainSQL. Meiner Meinung nach sollen die Daten soweit fertig aus der DB kommen, dass sie nur noch linear gemappt werden müssen. Dazu gibt es für jede Art Statement eine Art "Entity", die eine Zeile wiederspiegelt. Hierarchien können (und sollen sich bewusst) nicht abbilden lassen.

      Ich persönlich bin der Meinung, dass sich ORM zu Beginn für ein Projekt lohnenswert auswirken kann. Im längeren Verlauf wird man jedoch schnell an die Grenzen stossen. Insbesondere ist jedoch auch die Art der Anwendung entscheidend. Bei einer einfachen CRUD-Anwendung mag es durchaus Sinn machen. In komplexeren Business Applications, wo einzelne Transaktionen komplexer (z.B. INSERTS mit SELECTS/SUBSELECT) werden halte ich es für angebrachter, Plain SQL zu verwenden. Eine zusätzliche Abstraktionsschicht halte ich für übertrieben.
      [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

      Kommentar


      • #4
        Im längeren Verlauf wird man jedoch schnell an die Grenzen stossen.
        Danke, dass es einen gibt, der es so sieht wie ich. Vllt bediene ich die Dinger falsch, aber es hat noch keinen Mapper gegeben, der mich annähernd mit dem versorgen konnte, was ich wollte. Meiner Meinung nach sind diese Mapper auch eher dazu gedacht einem php-programmierer sql-kenntnisse abzunehmen.

        Kommentar


        • #5
          In der Java-Welt sieht man m.M.n., was ORM "anrichten" kann. Es gibt viele Java-Programmierer die können zwar dank Hibernate & co. Daten aus Datenbanken lesen - summieren oder gruppieren danach jedoch in Java. Und das ist völliger Schwachsinn.
          [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

          Kommentar


          • #6
            Ich arbeite nur noch in Ausnahmefällen ohne eine ORM-Schicht. Es ist mMn die beste Heransgehensweise für 80% aller Probleme, die in einer modernen Programmierumgebung für Anwendungen oder Webseiten aufkommen.

            In Einzelfällen und mit guten Begründungen, die nicht wie von ChristianK beschrieben einfach nur auf falsche Verwendung oder nicht 100%ige Kenntnis der Möglichkeiten der ORM-Schicht beruhen, benutze ich auch manchmal noch "normales" SQL.

            Allerdings nur, wenn es wirklich sein muss.

            Und witzigerweise hat jeder, den ich kenne und ein Verfechter von SQL ist, sich irgendwelche lustigen Klassen/Mapper gebaut, die quasi auch wieder nur eine ORM-Schicht darstellen, nämlich "Datenbankklassen", die Objekte zurückgeben. Das ist nichts anderes als eine ORM-Schicht, die halt noch nicht ausgereift ist, wie die bestehenden Lösungen.


            Es kommt sehr drauf an, was man kann / können muss. Ich beherrsche SQL ziemlich gut, aber ich WILL mich nicht damit auseinandersetzen müssen, weil es fast immer nur ein unnötiger Ballast ist für etwas, was mir die ORM-Schicht abnehmen kann.

            Und die Grenzfälle, in denen die ORM-Schicht tatsächlich nicht mehr weiterkommt (und davon gibt es eigentlich nur einen, nämlich den Object/Relational Impedance Mismatch), sind mMn sehr selten und lassen sich durch ein gutes ERM von vornerein verhindern.
            [URL="http://goo.gl/6Biyf"]Lerne Grundlagen[/URL] | [URL="http://sscce.org/"]Schreibe gute Beispiele[/URL] | [URL="http://goo.gl/f2jR7"]PDO > mysqli > mysql[/URL] | [URL="http://goo.gl/jvfSZ"]Versuch nicht, das Rad neu zu erfinden[/URL] | [URL="http://goo.gl/T2PU5"]Warum $foo[bar] böse ist[/URL] | [URL="http://goo.gl/rrfzO"]SQL Injections[/URL] | [URL="http://goo.gl/Q81WJ"]Hashes sind keine Verschlüsselungen![/URL] | [URL="http://goo.gl/2x0e2"]Dein E-Mail Regex ist falsch[/URL]

            Kommentar


            • #7
              Ein schlaues ORM (Doctrine z.B.) kann mit beidem Umgehen. zu 90% muss ich kein eigenes SQL schreiben. Meistens reicht dann auch DQL, falls nicht kann ich immer noch SQL schreiben. Du kannst den Mapper bei Doctrine auch ausschalten oder selber schreiben usw.

              Wer OOP Programmiert sollte bei Datenbank-Abfragen nicht auf ein ORM verzichten.

              Kommentar


              • #8
                Zum Glück muss man sich in der IT nicht an Pauschalaussagen halten .
                [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

                Kommentar


                • #9
                  Zum Glück hat der TE eine pauschale Frage gestellt, dann müsste man sich dann konsequenterweise daran halten...

                  Kommentar


                  • #10
                    Wer OOP Programmiert sollte bei Datenbank-Abfragen nicht auf ein ORM verzichten.
                    Ok, danke für die Antwort. Kannst du mir erklären, wie du das meinst? Ist das auf eine Vereinbarun deines Teams zurückzuführen, dass nur OO-basiert programmiert wird?

                    Kommentar


                    • #11
                      der Vorteil gerade von Doctrine ORM ist halt der, dass du dein Datenbank Zeugs auf allen Datenbanken laufen lassen kannst.

                      Doctrine nutzt dafür einen DBAL, der eben in der Lage ist, mit den meisten relationalen Datenbanken, die PHP ansprechen kann, SQL auszuführen
                      https://github.com/Ma27
                      Javascript Logic is funny:
                      [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                      Kommentar


                      • #12
                        Hallöchen,

                        Zitat von Phpyton Beitrag anzeigen
                        Danke, dass es einen gibt, der es so sieht wie ich. Vllt bediene ich die Dinger falsch, aber es hat noch keinen Mapper gegeben, der mich annähernd mit dem versorgen konnte, was ich wollte.
                        Zum Beispiel?

                        Zitat von Phpyton Beitrag anzeigen
                        Meiner Meinung nach sind diese Mapper auch eher dazu gedacht einem php-programmierer sql-kenntnisse abzunehmen.
                        Ich persönlich betrachte das Thema generell sehr pragmatisch. Mir ist wichtig, dass ich mit möglich wenig Aufwand schnell Ziele erreichen kann. Bei Doctrine - und ich arbeite sehr intensiv damit - bin ich bisher noch nie an einen Punkt gekommen, an dem mir der ORM im Weg stand. Gerade weil die Möglichkeit besteht Plain-SQL zu verwenden, lassen sich auch komplexe Abfragen aufbauen und verwenden und ggf. manuell mappen. Zudem muss man bei gewöhnlichen Anwendungsfällen nicht den Weg zu Fuß gehen.

                        Viele Grüße,
                        lotti
                        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                        Kommentar


                        • #13
                          der Vorteil gerade von Doctrine ORM ist halt der, dass du dein Datenbank Zeugs auf allen Datenbanken laufen lassen kannst.
                          Ok, zur Kenntnis genommen. Allerdings lasse ich meine Anwendung immer auf der gleichen DB laufen, und das wird auch so bleiben.

                          Zudem muss man bei gewöhnlichen Anwendungsfällen nicht den Weg zu Fuß gehen.
                          Ist nicht böse gemeint, aber was spricht dagegen, plain sql zu benutezn. Für mich sieht das in der jetzigen Form nur wie unnötiger Overhead aus.

                          Kommentar


                          • #14
                            Zitat von Phpyton Beitrag anzeigen
                            Ist nicht böse gemeint, aber was spricht dagegen, plain sql zu benutezn. Für mich sieht das in der jetzigen Form nur wie unnötiger Overhead aus.
                            Ist das "zu Fuß gehen" nicht schon Beispiel genug? => Warum benützt du ein Auto? Zu Fuß kommst du überall hin wo du mit dem Auto auch hinkommst + an weitere Orte. Ergo ist zu Fuß gehen auch immer besser als Autofahren?

                            Ansonsten zum Datenbankumzug: Ist eben wie Feueralarm-Dril, Erdbeben-Drill, Hochwasserszenarien oder Datenverlust ohne Backup. Wollen wirs hoffen das es einen nie betrifft, die Chancen stehen gar nicht schlecht. Aber dennoch zahlt sich die Vorbereitung darauf aus.

                            Kommentar


                            • #15
                              Ist das "zu Fuß gehen" nicht schon Beispiel genug? => Warum benützt du ein Auto? Zu Fuß kommst du überall hin wo du mit dem Auto auch hinkommst + an weitere Orte. Ergo ist zu Fuß gehen auch immer besser als Autofahren?
                              Zwar ein ungewöhnliches Beispiel, aber mit dieser Thematik ist der Groschen schlagartig gefallen. Thanx.

                              Kommentar

                              Lädt...
                              X