Bietet LINQ To SQL schnellere Antwortzeiten als die Verwendung von ado.net und oledb?

Question

LINQ vereinfacht die Datenbankprogrammierung ohne Zweifel, aber hat es einen Nachteil? Inline-SQL erfordert eine Kommunikation mit der Datenbank in einer bestimmten Weise, die die Datenbank für Injektionen öffnet. Inline-SQL muss ebenfalls syntaktisch überprüft werden, einen Plan erstellen und dann ausführen, was wertvolle Zyklen erfordert. Gespeicherte Prozeduren sind auch ein grundsolider Standard für die Programmierung von Datenbankanwendungen. Viele Programmierer, die ich kenne, verwenden eine Datenschicht, die die Entwicklung vereinfacht, jedoch nicht in dem Maße, wie LINQ dies tut. Ist es Zeit, die SPs aufzugeben und LINQ zu gehen?

Answer 1

LINQ to SQL zeigt tatsächlich einige alarmierende Leistungsprobleme in der Datenbank. Im Grunde erstellt es mehrere Ausführungspläne basierend auf der Länge des von Ihnen verwendeten Parameters. Ich habe vor einiger Zeit auf meinem Blog LINQ to SQL may cause performance problems darüber gepostet.

Nun, ist das zu sagen, dass LINQ keinen Platz hat? Kaum. LINQ hat definitiv einen Platz im Entwicklungs-Toolkit, genau wie gespeicherte Prozeduren. Letztendlich möchten Sie gespeicherte Prozeduren verwenden, wenn die Leistung unbedingt erforderlich ist, und in jeder anderen Situation ein ORM-Tool verwenden.

Soweit es Inline-SQL gibt, gibt es Möglichkeiten, Inline-SQL auszuführen, so dass der Plan nur einmal erstellt und nie neu kompiliert wird. Die meisten ORMs sollten sich auch um diesen Aspekt der Leistungsoptimierung kümmern, und die Verwendung dieser Methoden ist normalerweise der sicherste Weg, um SQL auszuführen, da Sie gezwungen sind, parametrisierte Abfragen zu verwenden.

Wie bei den meisten Datenbanklösungen hängt die richtige Antwort vom Problem ab, das Sie lösen möchten. Wenn Sie die Entwicklungsgeschwindigkeit gegenüber der Datenbank-/Anwendungsleistung bevorzugen, ist die Verwendung von LINQ oder eines anderen DAL/ORM-Tools der beste Weg. Wenn Sie die Leistung der Entwicklung vorziehen, ist die Verwendung von gespeicherten Prozeduren und reinen Datensätzen die beste Wahl. LLBLGen bietet sogar einen LINQ to LLBLGGen-Layer, so dass Sie LINQ verwenden können, um LLBLGen-Objekte abzufragen, und LLBLGen tatsächlich die Erstellung Ihrer Abfragen übernimmt und einige der Fehler von LINQ vermeidet.

Answer 2

Dies ist eine Performance von Maximilian Beller. Laut ihm ist LINQ viel langsamer. Read his comprehensive study

Answer 3

Es hängt davon ab, was Sie tun. LINQ wird bei der tatsächlichen Daten-/Mengenmanipulation weniger effizient sein als eine echte Datenbank. Aber Sie sparen viel, wenn Sie sich nicht über ein Netzwerk mit der Datenbank verbinden müssen.

Wenn sich Ihre Datenbank auf demselben Computer befindet oder formal gut verbunden ist, ist es wahrscheinlich besser, sie zu verwenden.

Aber wenn Sie eine große Ergebnismenge von einer entfernten Datenbank zurückbekommen, die eine signifikante Übertragungszeit bedeuten könnte, oder wenn es eine wirklich kurze Abfrage ist, die den Overhead nicht rechtfertigen würde, wäre LINQ wahrscheinlich besser.

Answer 4

Wenn Sie am Benchmarking interessiert sind, hat Rico Mariani eine excellent 5-part study, die die qualitativen und quantitativen Unterschiede abdeckt.

Er mag ein MS-Typ sein, aber er ist bekannt als eine Performance-Nuss - seine Benchmarks sind gründlich und gut durchdacht.

Answer 5

Denken Sie nur daran, einen Spaltennamen zu ändern - ändern Sie jetzt die (n) SPs und (x) Ansichten.

Tun Sie alles, was in der Datenbank teuer ist (wie Suchen, Sortieren usw.) und Sie werden kein Problem bemerken.

Wenn Sie ein großes Gitter ohne Paging anzeigen möchten ... dann verwenden Sie einen Datensatz - dieser ist schneller.

StackOverflow verwendet auch linq2sql - sehen Sie ein Problem :)?

Verwenden Sie ein ORM - es ist der Weg, auf den meisten Anwendungen zu gehen.

PS: auch über Mikro-Benchmarks - wie .. wählen wir 10.000 Zeilen mit einem ORM - DO DO DO IT. Das ist nicht der Grund, warum Sie ein ORM verwenden. Wenn Sie 10.000 Zeilen auswählen möchten, verwenden Sie ADO.

Answer 6

Aufgrund der Struktur von LINQ to SQL, gibt es keine Möglichkeit, schneller als mit Raw SQL, entweder Ihre eigenen wohlgeformten Abfragen oder als eine gespeicherte Prozedur. Was LINQ kauft, ist nicht Geschwindigkeit, sondern Typ Sicherheit und Organisation; Kurz gesagt, die meisten Vorteile, die ORMs Ihnen normalerweise gewähren.

Bei LINQ to SQL geht es nicht um Geschwindigkeit, sondern darum, ein wartungsfreundlicheres Softwaresystem aufzubauen. Es geht darum, die alle Sachen gewidmet Software Ingenieure und Architekten kümmern sich um, Sachen wie lose Kopplung und Schichtung

Das ist nicht zu sagen, dass Sie nicht ein paar wirklich wartbaren Code mit LINQ bauen können - niemand Sie hält von selbst schießt in der Fuß aber Sie - aber richtig gemacht, kann LINQ enorm helfen. Ich sage nicht, dass LINQ eine Silberkugel ist. Es gibt viele Probleme, die die Verwendung in vielen Unternehmenssituationen erschweren - deshalb bietet MS Entity Framework (ADO.NET 3.0) an.Natürlich ist das auch nicht perfekt angesichts der jüngsten EF Vote of No Confidence.

Ist LINQ to SQL oder sogar EF besser als Raw SQL? Ich würde sagen Hells Yeah. Gibt es andere Lösungen, die besser funktionieren könnten? Könnte sein.

Answer 7

Ihre grundlegende Prämisse fehlerhaft ist ..

Inline SQL erfordert eine mit der Datenbank in einer bestimmten Art und Weise zu kommunizieren, um die Datenbank zu Injektionen öffnet.

Nein, tut es nicht. Hard-Coding Benutzer eingegebene Werte in eine SQL-Anweisung, aber Sie könnten dies auch mit speichern Verfahren.

Die Parametrisierung Ihrer Abfragen schützt vor Angriffsangriffen, aber Inline-SQL kann genauso einfach wie gespeicherte Prozeduren parametrisiert werden.

Inline SQL muss auch Syntax geprüft werden, haben einen Plan gebaut, und dann ausgeführt.

Alle Sql (SPs und inline) müssen Syntax-geprüft sein und einen Plan auf den ersten Anruf aufgebaut haben. Danach wird der genaue Text der Anfrage & der Ausführungsplan zwischengespeichert. Wenn eine andere Anfrage mit genau demselben Text (ohne Parameter zählen) empfangen wird, wird der zwischengespeicherte Ausführungsplan verwendet.

Wenn Sie also Werte in Inline-SQL fest codieren, stimmt der Text nicht überein, und die Abfrage muss erneut analysiert werden. Wenn Sie jedoch Parameter verwenden, stimmt der Text der Abfrage überein, und Sie erhalten einen Cache-Treffer. In diesem Fall wäre es egal, ob die Abfrage in Inline-SQL oder einem SP erfolgt.

Mit anderen Worten, das einzige Problem mit Inline-SQL ist, dass es einfach ist, etwas langsames & unsicher zu tun. Aber macht Inline-SQL schnell & sicher ist keine Arbeit mehr, die einen SP verwendet.

Das bringt uns zu LINQ, die immer mit Parametern, auch wenn Sie die Werte in die LINQ-Anweisung fest codieren, machen "schnell & sicher" Inline-SQL trivial.

LINQ hat auch den Vorteil gegenüber SPs, dass Sie Ihren gesamten Code an einer Stelle haben, anstatt über zwei verschiedene Maschinen verteilt zu sein.