Datenbanklogik
-
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...
-
Ich kenne keinen technischen Grund der grundsätzlich gegen alle ORMs sprechen würde. Ich kenne nichtmal einen der gegen "die üblichen" ORMs spricht. Vermutlich aber nur deswegen weil ich zu wenig ORMs kenne.
Mein Argument ist:
Man kauft sich damit zusätliche Dinge ein. Auf der Negativseite sind da u.A.
* Zusätliche Komplexität
* Zusätliche Einarbeitungszeit für bestehende und neue Programmierer
* Zusätliche Bugs
* Zusätlicher Aufwand beim DebuggenWas mMn. nicht zu vernachlässigen ist. Einen Programmierer der SQL kann findet man noch relativ leicht. Einen Programmierer der mit dem speziellen ORM Erfahrung hat welches man sich ausgesucht hat ... schwerer.
Weiters ist mMn. zu beachten dass es ja nicht reicht sich so ein ORM mal eben angesehen zu haben. Programmierer die sich ein komplexes Framework "mal eben angesehen" haben schreiben nach meiner Erfahrung damit fürchterlichen Code. Weil "mal eben angesehen" halt nicht ausreichend ist um zu verstehen wie man ein Werkzeug effizient einsetzt. So einsetzt wie es gedacht war, so einsetzt dass möglichst wartbare und verständliche Programme rauskommen.
Und dann ist die Frage was besser ist: halbwegs guter "SQL zu Fuss" Code, oder fürchterlicher "mit ORM" Code.Du hast natürlich Recht wenn du schreibst (sinngemäss) dass das für so ziemlich jedes Werkzeug gilt. Ändert aber mMn. nichts daran dass es halt so ist
Und ich sage ja auch nicht dass man ORMs niemals irgendwo verwenden sollte. Ich sage nur: je nachdem
... was die Programmierer die man schon hat bereits können
... was in anderen Programmen die bereits vorhanden sind und gewartet werden müssen schon verwendet wird
... wie gross/komplex das Projekt ist bzw. in absehbarer Zeit werden wird
usw.
muss man sich überlegen ob die Vorteile einer Technologie/eines Werkzeugs die Nachteile aufwiegen. Das kann dann so oder so ausgehen.TL;DR: Es geht schon um etwas mehr als "ich mag nicht".
Andere Frage: Kennst du ein ORM für .NET (C#) welches du generell empfehlen könntest? Als DB sollte es zumindest SQL CE und MSSQL unterstützen. Wenn SQLite auch noch mit unterstützt wird ist es kein Schaden, aber ist nicht wirklich nötig.
Also etwas was deiner Meinung nach für die meisten Projekte halbwegs gut geeignet ist, keine schlimme Lernkurve hat, keine schlimmen Bugs/Performanceprobleme etc.
-
Also für C# ist ja das Entity Framework (EF) das Standard-ORM.
Als Alternative, aber auch mit steilerer Lernkurve, gibt es noch NHibernate.Für kleinere Projekte (bzw. als Einstieg) würde ich aber eher so etwas wie FluentData oder Dapper empfehlen.
Ich selber benutze aber keinen direkten SQL-Code mehr in meinen Sourcen!
-
Guckt euch doch mal bitte die Queries an die das Entity Framework generiert. So welchen Müll würde niemals ein Programmierer hinkriegen.
-
hustbaer schrieb:
Mein Argument ist:
Man kauft sich damit zusätliche Dinge ein. Auf der Negativseite sind da u.A.
* Zusätliche Komplexität
* Zusätliche Einarbeitungszeit für bestehende und neue Programmierer
* Zusätliche Bugs
* Zusätlicher Aufwand beim DebuggenDu setzt bei allen deinen Argumenten voraus das SQL Knowhow komplett vorhanden ist und da keine Fehler gemacht werden. Obwohl ein ORM hier ja gerade enorm das Fehlerpotential reduziert. Da eben Relations in der DB automatisch korrekt sind und du auch den Praktikanten mal da dran lassen kannst weil der da nix kaputt machen kann.
Denn ORM reduzieren die Komplexität (weniger Code), reduzieren die Einarbeitungszeit (wie hole ich mir nochmal alle alle einzelnen offenen Rechnungsposten? getRechnungById(id).getAllOpenPositions()), reduzieren die Bugs (die Relations müssen nur einmal am Anfang definiert werden, danach sind alle Zugriffe garantiert korrekt) und reduziert den Aufwand beim Debuggen da man davon ausgehen kann dass der ORM Code korrekt ist und man selber ja weniger Code schreibt.
Von so Sachen wie nachträglicher Änderbarkeit mal abgesehen.
Aber hier ist ein Stackoverflow von 2008 http://stackoverflow.com/questions/194147/are-there-good-reasons-not-to-use-an-orm - vor 8 Jahren. Und damals schon war ORM nicht mehr Neuland
PS:
und nein, ORMs sind auch nicht perfekt und man wird auch hier immer mal wieder in Probleme rein laufen. Aber das ganze hat man überall. Nur weil etwas nicht perfekt ist, ist es noch lange nicht schlechter als alles per Hand zu machen.Mal von soetwas trivialem wie "SQL Code hat nichts im normalen Code verloren" abgesehen. Man mischt einfach nicht 2 Programmiersprachen - man trennt sie.
-
-
Ich schmeiss einfach mal in den Raum, dass die Firma, bei der ich arbeite, einen SQL Wrapper entwickelt hat:
- etwa 2008 oder 2009 rum
- um unabhängig von den verschiedenen SQL Dialekten zu sein (MSSQL, MySQL, SQLite, ja nur diese 3)
- dieser Wrapper eigentlich nur dafür sorgt, dass man anstatt SQL Strings zu konkatenieren, nun Objekte ineinander steckt (was auch erst zur Laufzeit zu Fehlern führt)
- jegliches Mapping zwischen Objekten und Tabellen manuell durchführen muss
- sowas wie ORM nicht benutzt wird, weil das zu kompliziert, langsam und fehleranfällig ist
- nun anstatt von SQL String Konkattenationen halt im OnClick Event eienr Controller Klasse für einen Button halt über hudnerte Zeilen SQL Objekte zusammengesteckt werden
- die Datenbank Exekutoren ziemlich stark an die jeweiligen Requests pro Seitenaufruf gekettet sind (somit wird eine Testbarkeit mit z.B. Unit-Tests fast unmöglich, im besten Fall jedoch nur sehr kompliziert gemacht, da man halt immer einen kompletten laufenden Anwendungsserver braucht)Ich wollt das einfach mal hier fallen lassen und bin auf die Reaktionen gespannt :>
-
Die Antwort wirst du wohl kennen: schmeiß es weg! Da wurde wohl eindeutig "over engineering" betrieben
-
Th69 schrieb:
Die Antwort wirst du wohl kennen: schmeiß es weg! Da wurde wohl eindeutig "over engineering" betrieben
Sind die Unterschiede zwischen MySQL und MSSQL denn wirklich so groß und gravierend?
(Aus gegebenem Grund können wir Stored Procedures und auch Tabellen Relationen mit Foreign Keys etc. weglassen bei dem vergleich)
-
Shade Of Mine schrieb:
hustbaer schrieb:
Mein Argument ist:
Man kauft sich damit zusätliche Dinge ein. Auf der Negativseite sind da u.A.
* Zusätliche Komplexität
* Zusätliche Einarbeitungszeit für bestehende und neue Programmierer
* Zusätliche Bugs
* Zusätlicher Aufwand beim DebuggenDu setzt bei allen deinen Argumenten voraus das SQL Knowhow komplett vorhanden ist und da keine Fehler gemacht werden.
Ja, richtig. Wobei "keine Fehler gemacht werden" ist relativ. Ich sitze gerade an einem Projekt wo das EF verwendet wurde und muss so ca. alle 15 Minuten 1x kotzen gehen. Fehler kann man immer machen
Shade Of Mine schrieb:
Obwohl ein ORM hier ja gerade enorm das Fehlerpotential reduziert. (...)
Ja. Jaaa. Jaaaaaaaaaa, hast ja vermutlich Recht. So im Grossen und Ganzen zumindest
Dennoch sind gerade in dem von dir verlinkten SO ein paar andere Nachteile beschrieben die ich auch nicht ganz ignorieren würde. Aber kann ja jetzt jeder selbst lesen und sich ne Meinung bilden. Danke für den Link
