Ist SQL wichtig, wenn ich ORM-Frameworks gut kenne? [geschlossen]

50

Ich habe keine ernsthaften Erfahrungen mit SQL und ich hasse es, SQL anstelle von LINQ zu schreiben. Ich bin glücklich genug mit ORMs.

Ist es aus Sicht der Arbeitgeber und der Branche wichtig, SQL zu kennen? Muss ich das beherrschen? Sind Unternehmen, die reines SQL gegenüber ORM-Frameworks bevorzugen, ein "Dinosaurier" in der Programmierwelt?

Jemand
quelle
14
Ich fühle mich alt. SQL wurde so weit abstrahiert, dass Sie diese Frage jetzt ernsthaft stellen können.
Mark
11
@Mark: Vielleicht kannst du die Frage ernsthaft stellen, aber die Antwort ist immer noch dieselbe.
Adam Robinson
30
ist arithmetische kenntnisse noch wichtig, wenn ich einen rechner benutzen kann?
Steven A. Lowe
4
NHibernate ohne Kenntnisse von SQL Profiler und wie man seinen Bauch kitzelt, um JOINs zu verwenden, ist ein Performance-Jihad, der auf Ihren Datenbankserver wartet
Chris S
2
Müssen Sie HTML-Kenntnisse haben, wenn Sie Dreamweaver verwenden können?
Tulains Córdova

Antworten:

63

Das ist schwer zu viel Programmierer zu erklären, denn wenn man nur wissen , grundlegende SQL dann ist es wirklich nicht Sie geben viel von einem Vorteil gegenüber der Krücke eines ORM. Die fortgeschritteneren SQL-Konzepte sind jedoch ein entscheidender Teil des Unterschieds zwischen Anwendungen, die nur funktionieren, und Anwendungen, die eine hohe Qualität aufweisen (insbesondere schnell und zuverlässig).

Ich gehe davon aus, dass jemand anderes die Datenbanken für Sie entwirft , denn dies zu tun , ohne SQL zu kennen, ist einfach zu blass. Aber selbst wenn Sie sich nur gegen sie entwickeln, finden Sie hier nur eine unvollständige Liste aller Dinge, die ORMs nach wie vor schlecht oder gar nicht tun:

  • Rekursive und / oder hierarchische Abfragen
  • Optionale Parameter (insbesondere die Übersetzung in Bereichsprädikate)
  • Benutzerdefinierte Datentypen
  • Plattformspezifische Typen (SQL-Hierarchie-ID und TVPs, Oracle-Arrays und verschachtelte Tabellen usw.)
  • Batch-Einfügungen / Aktualisierungen / Upserts / Deletes
  • Indexhinweise
  • Sperrhinweise (insbesondere Update-Sperren und Dirty Reads)
  • Fehlerbehandlung
  • Äußere Verknüpfungen - ihre Ergebnismengen sind dem OOP-Modell schlecht zugeordnet. Viele ORMs haben ihre eigene Abfragesprache, aber das ist vergleichbar mit der Kenntnis von SQL selbst.
  • Modularisierung durch gespeicherte Prozeduren und UDFs, insbesondere Inline-UDFs und CROSS APPLY-Abfragen
  • Verwendung von OUTPUT / RETURNING zum Staging von Daten in mehreren Tabellen
  • Effiziente Paging-Abfragen
  • Abfragen basierend auf Fensterfunktionen (Rownum, Rang, Partitionen)

Die Liste geht weiter und weiter - viele dieser Dinge hat ein unerfahrener DBA noch nie zu tun gehabt, und ein unerfahrener Entwickler hat noch nie davon gehört -, aber sie sind in größeren Apps sehr wichtig.

ORMs sind wirklich großartig darin, den wirklich langweiligen SQL-Code zu beschleunigen - das heißt, all den repetitiven CRUD- und Mapping-Code und den anderen Code für die Installation. Es ist also absolut keine Schande, sie zu verwenden und niemandem zuzuhören, der sagt, dass sie böse sind. Aber Sie müssen auf jeden Fall noch lernen und ja, sogar SQL beherrschen , und bereit sein, sich in unformatierte DB-Befehle / Abfragen zu stürzen, wenn der ORM sein Gewicht nicht verliert.

Aaronaught
quelle
Ich stimme den meisten Ihrer Punkte zu, aber in Bezug auf äußere Verknüpfungen: Ja, sie sind schlecht in OOP abgebildet, aber ich denke, das OOP-Äquivalent (z. B. GroupJoinin LINQ) ist viel besser.
Svick
@svick: Es hat seine Verwendung, aber es ist nicht dasselbe. Versuchen Sie, eine vollständige äußere Verknüpfung mit zu emulieren GroupJoin.
Aaronaught
Ja, das ist nicht dasselbe. Und ich denke, was Sie die meiste Zeit brauchen, ist tatsächlich eine GroupJoin. Es ist nur so, dass Leute, die an SQL gewöhnt sind, in solchen Fällen sofort an Outer Join denken und sich fragen, wie man das in LINQ umsetzt. Das ist nicht der richtige Ansatz. Sie sollten nicht versuchen, SQL in LINQ zu übersetzen, sondern direkt das übersetzen, was Sie benötigen.
Svick
@svick: Danke für den Tipp. Ich hasse es, Rang zu holen, aber nach einer einjährigen Pause bin ich immer noch einer der Hauptverantwortlichen für SQL und Linq bei Stack Overflow. Ich bin mir ziemlich sicher, dass ich den Unterschied in der Vorgehensweise verstehe. Vollständige Verknüpfungen sind selten, aber manchmal sind sie genau das, was Sie brauchen, und es gibt einfach kein Analogon in Linq. Es ist ziemlich chaotisch und ineffizient, die gleiche Ergebnismenge zu erhalten , unabhängig davon, wie sie strukturiert ist .
Aaronaught
Anscheinend sind wir uns tatsächlich einig. In den meisten Fällen möchten Sie keine äußere Verknüpfung. Aber wenn Sie dies tun, ist es schwierig, es in LINQ zu übersetzen.
Svick
90

Absolut! SQL ist immer noch die Verkehrssprache von Datenbanken, und obwohl Sie möglicherweise viel mit ORMs tun, müssen Sie SQL verstehen, um die Entscheidungen zu verstehen, die ORMs treffen, und die SQL, die sie generieren. Außerdem gibt es noch viele Dinge, die Sie auch mit benutzerdefiniertem SQL und gespeicherten Prozeduren tun müssen. Entschuldigung, kein kostenloses Mittagessen.

Otávio Décio
quelle
6
Tatsächlich. Sie müssen zum Beispiel die Auswirkungen verschiedener Join-Anweisungen kennen und wissen, wie sie sich auf die Leistung auswirken.
Chiron
15
+1 Kein freies Mittagessen! Was ist mit all den Fragen, die sich im Grunde stellen, ob Ignoranz in Ordnung ist?
benzado
7
@benzado: Nicht, dass ich denke, dass dies für SQL gerechtfertigt ist, aber Sie müssen sich für die Unkenntnis einiger Dinge entscheiden. Es gibt viel zu viele Technologien (auch gute!), um sie alle wirklich zu kennen. Ich denke, es ist in Ordnung zu fragen, ob X unnötig ist, wenn ich Y wirklich gut kenne oder ob ich Z mache.
Craig Walker
2
@Craig Ich stimme zu, dass es zu viel gibt, um es zu lernen, aber ein Programmierer sollte wirklich ein Grundwissen über die Ebenen haben, in denen er arbeitet.
benzado
2
@Craig Walker-Datenbanken sind wichtige Wissensdatenbanken für die meisten Geschäftsanwendungen, die nicht besonders gut zu haben sind.
HLGEM
25

Ja, Sie müssen noch SQL kennen. ORMs sind eine sehr undichte Abstraktion und bieten keinen Zugriff auf die volle Leistungsfähigkeit von SQL. Für Spielzeuganwendungen sind Sie möglicherweise mit begrenzten SQL-Kenntnissen in Ordnung. Für Unternehmensanwendungen müssen Sie die Datenbank verstehen, um eine angemessene Leistung des ORM zu erzielen. Außerdem gibt es sehr viele Aufgaben, die mit SQL viel einfacher zu erledigen sind als mit einer Anwendungssprache. Ich habe Java-Programmierer gesehen, die tagelang Code geschrieben haben, um etwas zu tun, das in einer Stunde in SQL hätte codiert werden können. SQL-Kenntnisse sind sehr wertvoll für alle, die Anwendungen schreiben, die eine relationale Datenbank verwenden.

Kevin Cline
quelle
14

SQL-Kenntnisse sind heutzutage ein Muss in der IT. LINQ ist eine Microsoft Only-Technologie. SQL-Anwendungen gehen über die Entwicklung von Web- und Client / Server-Anwendungen hinaus. Sie können keine Datenbanken modellieren und ETL ausführen, wenn Sie nicht mit SQL vertraut sind. Möglicherweise müssen Sie keine SQL-Dialekte beherrschen, die in ORACLE und SQL Server für ihre Data Warehous-Produkte verwendet werden, aber Sie sollten Standard-SQL kennen. SQL-Grundlagen sind einfach, es gibt jede Menge Material, mit dem Sie beginnen können.

Keine Chance
quelle
1
Jeder, der weiß, wie LINQ funktioniert, kann an einem Tag grundlegende SQL-Kenntnisse erwerben. Dies ist ein schreckliches Argument für das Erlernen von SQL.
Boris Yankov
6

Wenn Sie mit einer SQL-Datenbank interagieren, müssen Sie die vom ORM generierte SQL verstehen. Sie müssen die Konzepte von SQL-Datenbanken verstehen und wissen, was Ihr ORM nicht für Sie tun kann. ORMs machen das Leben einfacher (und ich denke, dass Sie in vielen Fällen als Dinosaurier gelten, wenn Sie ohne sie arbeiten), aber sie sind Werkzeuge (um Dinge zu abstrahieren, die Sie kennen), keine Krücken (um Sie am Lernen zu hindern).

Wenn Sie sich weigern, SQL zu lernen, haben Sie keinerlei Probleme damit, SQL-Datenbanken mit oder ohne ORM zu berühren, und Sie sollten eine andere Art von Arbeit finden.

Marnen Laibow-Koser
quelle
Obwohl ich der Meinung bin, dass SQL-Kenntnisse sehr nützlich sind - im Grunde genommen obligatorisch -, stimme ich Ihren Gründen nicht zu. Aus diesem Grund müssen Sie sich mit ASM und Ihrer CPU-Architektur auskennen, bevor Sie ein Programm schreiben, da Hochsprachen die Dinge einfacher machen, aber Werkzeuge (um Dinge zu abstrahieren) sind ein Computer. <--- Macht keinen Sinn. Der eigentliche Grund dafür ist, dass ORM-Tools noch in den Kinderschuhen stecken. Es würde mich nicht wundern, wenn in 5-10 Jahren keine SQL-Kenntnisse mehr benötigt werden
Thomas Bonini
Hochsprachen sind so aufgebaut, dass Sie nicht mehr über die zugrunde liegende Architektur Bescheid wissen müssen. Dies ist möglich, weil die Domäne der zugrunde liegenden Architektur entspricht. ORMs sind jedoch eine andere Sache. Ich bin ein großer Fan von ORMs, aber ich glaube nicht, dass jemals ein Tag kommen wird, an dem Sie eines verwenden können, ohne SQL zu kennen (oder was auch immer die zugrunde liegende DB verwendet). Das Objekt- und das Beziehungsmodell sind von Grund auf inkommensurabel, und ich denke, es wird immer Konzepte geben, die sich nicht von einem zum anderen übertragen lassen. Außerdem spreche ich von den heutigen ORMs, nicht von der Zukunft
Marnen Laibow-Koser
3
+1: "Wenn Sie sich weigern, SQL zu lernen, haben Sie keinerlei Probleme damit, SQL-Datenbanken mit oder ohne ORM zu berühren, und Sie sollten eine andere Art von Arbeit finden."
Vector
2
Ich würde das eine Million Mal unterstützen, wenn ich könnte. Es gibt viel zu viele Leute, die kein Geschäft damit haben, SQl-Datenbanken zu berühren, weil sie allgemein inkompetent sind und nicht wissen, was sie tun. Sie haben Havok überall dort, wo sie Performanceabsichten schaffen und Berichte schreiben (aus denen tatsächliche Geschäftsentscheidungen getroffen werden), die zu schlechten Ergebnissen führen, ohne es zu merken, weil sie SQl absichtlich ignorieren, als wäre es eine Art Ehrenzeichen, die Datenbank zu entstellen das ist entscheidend für ihre Anwendungen.
HLGEM
1
+1 für "Werkzeuge (um Dinge zu abstrahieren, die Sie kennen), nicht Krücken."
Sholsinger
4

Ich gebe zu, dass ich ein eingefleischter ORM-Fan bin und seit Jahren die Vorteile von ORM predige und viel darüber zu sagen hatte, warum ORM SQL übertrumpft.

ABER...

Ich muss zugeben, dass SQL in der realen Welt absolut erforderlich ist und jeder Entwickler ein gutes Verständnis von SQL haben sollte.

SQL-Prozesse sind in fast allen Fällen schneller als der ORM. Auch wenn Sie die ORM-Ausgabe in den meisten Fällen optimistisch gestalten können, ist sie den SQL-Prozessen in Kürze unterlegen.

Gelegentlich benötigen Sie einige Hochleistungs-SQL-Anweisungen, um das gewünschte Ergebnis zu erzielen, und diese Monster-Abfragen lassen sich in SQL-Prozessen einfacher und schneller erstellen.

Nur meine zwei Bits.

SetiSeeker
quelle
4

Es wird eine Zeit kommen, in der Sie etwas Komplexes optimieren müssen, das der ORM erstellt. Zu diesem Zeitpunkt müssen Sie im Allgemeinen eine äußerst komplexe Abfrage auflösen. Wenn Sie noch nie Grundlagen gelernt haben, wie können Sie dann damit rechnen, SQL mit den fortgeschrittenen Inhalten zu erlernen? Sie werden nicht genug verstehen, um überhaupt anzufangen. ORMs in den Händen einer Person, die SQL versteht - ein gutes Werkzeug. ORMs in den Händen von jemandem, der SQL überhaupt nicht kennt - eine Katastrophe, die darauf wartet, passiert zu werden.

Einer der Gründe, warum SQL für das Verständnis von Datenbanken von entscheidender Bedeutung ist, besteht darin, dass Anwendungsprogrammierer naturgemäß nicht in Datensätzen denken. Die einzige Möglichkeit, wie Datenbanken überhaupt effizient arbeiten, sind Mengen. Sie müssen lernen, wie man in Mengen denkt, bevor Sie überhaupt versuchen, ein ORM zu verwenden.

HLGEM
quelle
3

Ich muss Abfragen in ORM-Frameworks häufig manuell erzwingen. Und während die meisten ihre eigene Abfragesprache haben, sind diese alle von SQL inspiriert, der Code wird in SQL umgewandelt, und Sie müssen verstehen, was falsch läuft, indem Sie diese SQL lesen, wenn (nicht wenn, wann) etwas schief geht oder wenn die Leistung schlecht ist.
Selbst wenn Sie SQL nicht direkt schreiben, verstehen Sie es über eine grundlegende Ebene hinaus (obwohl Sie wahrscheinlich nichts über das Schreiben gespeicherter Prozeduren, Trigger usw. lernen müssen, wenn Sie nur auf Datenbanken zugreifen möchten) sollte die Sprache so gut beherrschen, dass der generierte Code verstanden und bei Bedarf angepasst werden kann.

jwenting
quelle
3

Bevor ich über die Frage spreche, zunächst eine kleine Einführung; Ich liebe ORMs. Und ich hasse SQL. Ich liebe ORMs, weil sie das benutzerunfreundliche Durcheinander von SQL verbergen und eine nette, sprachintegrierte Art des Umgangs mit der Datenbank bieten.

Allerdings muss ich zugeben, dass SQL viele Vorteile hat, wobei der größere die Präzision ist. Ich kann ziemlich genau über die Komplexität einer SQL-Abfrage streiten, ohne das zugrunde liegende Datenbankschema genau zu kennen, indem ich die Abfrage durcharbeite. Wenn ich SQL verwende, bin ich daher immer wachsam und habe immer ein Gespür dafür, wohin die Komplexität einer Komponente führt.

Andererseits bin ich bei der Verwendung von ORMs von der einfachen Datenbankintegration so überwältigt, dass ich buchstäblich vergesse, dass es sogar eine Datenbank gibt. Das hat mich mehrfach durcheinander gebracht. In der Vergangenheit habe ich oft unschuldig aussehende ORM-Methoden genannt, die hinter den Kulissen massive und beängstigende Datenbank-Joins aufrufen, die die Leistung zerstören.

Deshalb liegt für mich die Wahrheit irgendwo dazwischen. Ich liebe die Verwendung von ORMs und werde dies auch weiterhin tun, aber ich muss vorsichtiger sein und immer die Auswirkungen (auf SQL-Ebene) eines ORM-Methodenaufrufs untersuchen. Die Implikationen einer Abstraktionsschicht zu kennen, ist in diesem Geschäft Gold wert und rechtfertigt die Verwendung der Abstraktion. Alles andere ist, als würde man sich auf den Fuß schießen.

Charalambos Paschalides
quelle
3
Ich denke auch, dass manchmal (sogar mit regulärem SQL) Leute vergessen, dass nur, weil es einen Datensatz zurückgab, nicht bedeutete, dass es der richtige Datensatz war. Ich denke, dass dies mit einem ORM leichter zu vergessen ist, wenn Sie davon ausgehen, dass es das Richtige getan hat, da Sie nicht wirklich verstehen, was es getan hat.
HLGEM
Ich bin nicht einverstanden damit, dass ORM weniger komplex ist als SQL. Mit SQL können Sie Daten ohne Programmierung abrufen. SQL ist keine Programmiersprache, sondern eine deklarative und hat daher keine Zeit für oder Wenn-Dann-Strukturen.
Tulains Córdova
1
Eine deklarative Programmiersprache ist immer noch eine Programmiersprache. SQL ist eine spezielle Programmiersprache, und ja, sie ist größtenteils deklarativ. Was das Fleisch deines Kommentars betrifft, verstehe ich es nicht. SQL ist zwar keine universelle Programmiersprache, aber dennoch eine Sprache. Sie müssen die Syntax, ihre Einschränkungen und Fehler noch kennen.
Charalambos Paschalides
2

Wenn Sie nur mit der Datenbank interagieren müssen, obwohl Sie gerade eine Anwendung erstellen, brauchen Sie diese wahrscheinlich nicht. In einigen kleineren Unternehmen oder Entwicklerteams müssen Sie möglicherweise Unterstützung leisten. Es ist viel einfacher, eine Verbindung zur Datenbank eines Kunden herzustellen und ein paar SQL-Anweisungen auszuführen, um zu sehen, was mit seinen Daten los ist.

JeffO
quelle
Wer muss NUR über die Anwendung, die er erstellt, mit der Datenbank interagieren?
Tulains Córdova
2

Selbst mit einem guten, ausgereiften ORM werden Sie unweigerlich in Situationen geraten, in denen ineffizientes SQL emittiert wird und Ihr Leben erheblich erleichtert wird, wenn Sie wissen, was in dem generierten SQL vor sich geht. Das heißt, wenn Sie mit dem ORM sehr gut vertraut sind und wissen, wie man einen Profiler für die Datenbank Ihrer Wahl verwendet, können Sie es ziemlich leicht "vortäuschen, bis Sie es schaffen".


quelle
1

Die Antwort auf all diese Arten von Fragen ("Muss ich X kennen?") Lautet "Lerne es, wenn du es zum ersten Mal brauchst, wenn du es jemals brauchst".

Es ist jedoch wichtig, nicht in die Falle zu gehen, Dinge weniger effizient zu erledigen, weil Sie sich nicht bewusst sind oder nicht bereit sind, zu lernen, wie man sie effizient umsetzt.

Was tun Sie beispielsweise in diesem speziellen Fall, wenn Sie feststellen, dass in Ihrem Programm ein Fehler aufgetreten ist, der dazu geführt hat, dass das PostCountFeld Ihrer Benutzertabelle manchmal ungenau ist?

Sie beheben den Fehler und müssen nun den PostCount für alle Benutzer aktualisieren. Wie machst du das?

Wenn Sie dazu ein kleines Skript mit ORM schreiben, sind Sie sehr ineffizient. Eine sehr einfache SQL-Abfrage reicht aus.

Da diese Situationen ziemlich häufig sind, befürchte ich, dass Sie in die oben beschriebene Falle geraten sind!

Thomas Bonini
quelle
2
Ich stimme zu: Wenn Sie SQL nicht kennen, schreiben Sie oft Dutzende von Codezeilen, um das zu tun, was Sie mit einer einzelnen SQL-Abfrage hätten tun können.
Benzado
2
"Lerne es, wenn du es zum ersten Mal brauchst": ro-che.info/ccc/11.html
MatrixFrog
1

Ja, Sie brauchen noch SQL.

Gehen Sie nicht davon aus, dass etwas "Altes" irgendwie unwürdig ist. Sogenannte "Legacy" -Technologien gibt es noch, nachdem sie den Test der Zeit bestanden haben. Wir nennen Wang-Computer kein "Vermächtnis", sie sind gescheitert und verschwunden.

Wenn Sie mich fragen, stört es mich, dass meine Bank wahrscheinlich COBOL auf einem Mainframe oder IBM i verwendet? Absolut nicht. Dies sind grundsolide, erprobte und echte Technologien. Ratet mal, sie verwenden hauptsächlich DB2 SQL. Ich bin viel zufriedener damit, meinem Geld dort zu vertrauen, als mit Software, die in einer modischen Sprache des Monats entwickelt wurde.

Die Dinosaurier lebten auf dieser Erde viel länger als wir Menschen. Und wenn Sie Jurasic Park lesen (ja, Bücher sind besser als Filme), dann frage ich Sie, möchten Sie sich wirklich mit einer Packung überaus cleverer Velociraptoren oder einem verbissenen T-Rex auseinandersetzen, der niemals aufgibt? Lassen Sie sich nicht von der Unterschätzung der "Dinosaurier" beißen. ;-)

WarrenT
quelle
0

Abgesehen von Spielen und (hauptsächlich statistischen) Nachforschungen, mit denen ich keine Erfahrung habe, scheinen Datenbankzugriffe und -operationen einer der wenigen Bereiche zu sein, in denen falsche Entscheidungen zu sehr großen Leistungseinbußen führen. Ich glaube fest an leistungsfähigere Datenbankabstraktionen im Code und an linq, das die Datenbankoperationen mit der Programmiersprache verknüpft und Ihnen alle Tools der Sprache zur Verfügung stellt (Typprüfung, Syntaxprüfung, all die Dinge, die Sie mögen Ihre Programmiersprache), während Sie immer noch viel Macht haben, um das zu tun, was Sie wollen, ist absolut grandios. Leider funktioniert es immer noch nicht. Das heißt, wenn die Abstraktionsschicht falsch optimiert ist und Sie möglicherweise auf Sekunden anstatt auf Mikrosekunden oder Minuten anstelle von Sekunden auf Ihr Ergebnis warten. Da dies sehr auffällige Zeiten sind, Sie müssen sie wegoptimieren, oder Ihre Anwendung "funktioniert" nicht: Die Leistung wird zum größten Problem Ihrer Anwendung. Das heißt, Sie müssen näher an das Metall heranrücken und von Hand optimieren.

Wenn wir an dem Punkt angelangt sind, an dem das Manipulieren großer Datenmengen beispielsweise 3 ms von Hand dauert und 100 ms, wenn Sie die Abstraktionsschicht dies für Sie tun lassen, lassen Sie es auf jeden Fall die Abstraktionsschicht für Sie erledigen, weil Sie dies könnten 30-mal langsamer sein, aber Sie sind trotzdem (wahrscheinlich für die meisten Anwendungen) schnell genug. Die Realität sieht jedoch so aus, dass Sie, wenn Sie nach handoptimierten Lösungen suchen, bei denen Sie eine Reaktionszeit von 200 ms haben, und wenn die Abstraktionsschicht dies für Sie erledigt, der Algorithmus "nur" einen 10-fachen Leistungstreffer hat 2 Sekunden Verspätung, und dann kümmert es dich eine ganze Menge, da es von nicht ganz so schnell bis schmerzhaft langsam geht. Zu sehen, dass relationale Datenbanklösungen nicht gut skalierbar sindIch glaube nicht, dass dies in zwei oder drei Jahren gelöst sein wird. Dies bedeutet, dass Sie sich bei größeren Datenbanken noch eine Weile mit dem Nötigsten befassen müssen, oder Ihre Anwendung wird so langsam sein, dass sie den Wettbewerbern nicht standhalten kann.

Martijn
quelle