Ich versuche zu verstehen, welche Vorteile der Aufbau von SQL über einen objektorientierten Builder DSL im Gegensatz zur Parametrisierung einer Raw-SQL-Zeichenfolge bietet. Nach der Untersuchung / Implementierung der gleichen Abfrage drei Möglichkeiten, stelle ich fest, dass das rohe SQL bei weitem am einfachsten zu lesen ist. Dies wirft die Frage auf, "warum durch einen Reifen springen?" Warum deklarieren und verwenden Sie einfach Raw SQL?
Hier ist was ich heraufgekommen bin:
Zuerst denke ich, dass es das SQL portabler macht, da es dann von jeder DB mit einem Adapter genutzt werden kann. Ich denke, das ist das große, oder? Dennoch ist das meiste T-SQL für die meisten Datenbanken nicht verständlich?
Zweitens stellt es ein Abfrageobjekt zur Verfügung, das wiederverwendet werden kann - als Basis für andere Abfragen, named-scope-Verkettungen usw.
Was ist die Hauptrendite für Investitionen, die Sie realisieren, indem Sie SQL erstellen, statt es zu deklarieren?
%Vor%Ich schätze die benannten Bereiche wirklich und sehe, wie eine Verkettung nützlich sein kann. Ich mache mir keine Sorgen über den Zugriff auf verwandte Datensätze über ein Modell. Ich spreche nur über das Erstellen einer komplexen Abfrage.
Der Link, den @Kyle Heironimus den Gedanken von Nick Kallen über Arel gegeben hat, hatte diese Zeile:
Sie werden die Verwendung des Abgeleiteten bemerken Tabelle im Subselect. Das ist schrecklich, meiner Meinung nach. Nur fortgeschritten SQL-Programmierer wissen, wie man das schreibt (Ich habe diese Frage oft im Job gestellt Interviews habe ich noch nie gesehen jemand bekommt es richtig). Und es sollte nicht schwer sein!
Nun, Kallen führt dies auf das Fehlen der Schließung unter Komposition in SQL zurück. Das mag in einigen Fällen wahr sein, aber meine Erfahrung ist viel prosaischer - dass die meisten Entwickler bei SQL furchtbar sind. Sie kennen nur die grundlegendsten Dinge, diese grundlegenden Dinge werden missbraucht, wenn sie nach prozeduralen Lösungen in einer Set-basierten Sprache suchen. Ich musste argumentieren, dass die Datenbank bei 3NF in einer Firma, bei der ich war, argumentierte, mit allen anderen Entwicklern, sie haben es einfach nicht verstanden. Talentierte Leute (die meisten von ihnen :), aber keine Ahnung von SQL oder Datenbanken.
Setzen Sie es in C # oder Ruby oder Python & lt; Sprache der Wahl einfügen & gt; und die Entwickler sind wieder glücklich. Sie können beim prozeduralen / OO-Denken bleiben und Code produzieren, der ihnen gut aussieht.
Ich weiß, das wird mir keine Stimmen einbringen, wahrscheinlich eher das Gegenteil, aber es ist meine Meinung. Arel sieht interessant aus. BTW.
Als Nachtrag zu den Kommentaren, die ich oben gemacht habe, über sechs Monate später und nachdem ich die Sequel-Bibliothek während dieser Zeit sehr oft benutzt habe, kann ich sagen, dass es wirklich eine schöne Sache ist, und jetzt fühle ich, dass ich sie benutzen würde es voraus der Verwendung von straight SQL. Es ist nicht nur unglaublich leistungsfähig und erlaubt mir, einfache und fortgeschrittene Dinge ohne zu viel Kopfschütteln zu tun (es wird immer welche geben), es kann die SQL ausgeben, die es benutzt hat, und es erlaubt mir auch, in SQL zu gehen, wenn ich fühle ich muss.
Das macht meine Kommentare über das SQL-Verständnis der meisten Entwickler keineswegs zunichte. (Ich wurde kürzlich von einem Entwickler darüber informiert, dass es sich bei der Normalisierung um ein Relikt aus einer Zeit handelt, in der Speicherplatz teuer war.) Oh je!) nur, dass die Entwicklung der Sequel-Bibliothek offensichtlich von denen gemacht wurde, die Datenbanken wirklich verstehen. Wenn Sie SQL und DB-Design usw. kennen, gibt es Ihnen mehr Leistung schneller. Ich kann nicht dasselbe von den anderen ORMs sagen, die ich benutzt habe, aber vielleicht würden andere anders denken.
Sie haben die Gründe schon ziemlich getroffen.
Hier sind Gedanken vom Schöpfer von Arel.