LINQ zu SQL vs gespeicherte Prozeduren?[geschlossen]

StackOverflow https://stackoverflow.com/questions/14530

Frage

Ich warf einen Blick auf die "Beginner' s Guide to LINQ" - Beitrag hier auf StackOverflow (Anfänger-Guide zu LINQ), hatte aber eine follow-up-Frage:

Wir reden über Rampe bis ein neues Projekt, wo fast alle unserer Datenbank op ' s werden ziemlich einfache Datenabfragen (es ist ein anderes segment des Projekts, das bereits schreibt die Daten).Die meisten unserer Projekte bis zu diesem Punkt machen die Verwendung von gespeicherten Prozeduren für solche Dinge.Ich würde jedoch gerne nutzen, LINQ-to-SQL ob es mehr Sinn macht.

Die Frage ist also diese:Für einfache Datenabfragen, welcher Ansatz besser ist, LINQ-to-SQL oder gespeicherte Prozeduren?Alle spezifischen pro oder Kontra?

Vielen Dank.

War es hilfreich?

Lösung

Einige Vorteile von LINQ über sprocs:

  1. Art der Sicherheit:Ich denke, wir alle verstehen das.
  2. Abstraktion:Dies gilt insbesondere mit LINQ-to-Entities.Diese Abstraktion ermöglicht es auch den Rahmen, um zusätzliche Verbesserungen, können Sie ganz einfach nutzen. PLINQ ist ein Beispiel für das hinzufügen der multi-threading-Unterstützung für LINQ.Code-änderungen sind minimal, um diese Unterstützung hinzufügen.Es würde VIEL schwieriger sein, dies zu tun, data access code, ruft einfach sprocs.
  3. Debugging-Unterstützung:Ich kann jede .NET-debugger zum Debuggen der Abfragen.Mit sprocs, können Sie einfach zu Debuggen SQL und Erfahrung ist weitgehend an Ihren Datenbankanbieter (MS SQL Server bietet eine query analyzer, aber oft ist das nicht genug).
  4. Herstellerunabhängigkeit:LINQ funktioniert mit vielen Datenbanken und die Anzahl der unterstützten Datenbanken wird nur erhöhen.Sprocs sind nicht immer tragbar, zwischen Datenbanken, entweder wegen der unterschiedlichen syntax-oder feature-Unterstützung (wenn die Datenbank das unterstützt sprocs überhaupt).
  5. Bereitstellung:Andere haben erwähnt, dass dies bereits, aber es ist einfacher, eine einzelne Montage als für die Bereitstellung einer Reihe von sprocs.Damit verbindet sich auch mit #4.
  6. Einfacher:Sie müssen nicht lernen, T-SQL zu tun, auf die Daten zugreifen, noch müssen Sie lernen, die data-access-API (z.B.ADO.NET) erforderlich für den Aufruf der sprocs.Dies ist im Zusammenhang mit #3 und #4.

Einige Nachteile von LINQ vs sprocs:

  1. Netzwerk Verkehr:sprocs müssen nur serialisieren sproc-name-argument-Daten über die Leitung, während LINQ sendet die gesamte Abfrage.Dies kann wirklich schlimm, wenn die Abfragen sind sehr Komplex.Aber LINQ ist die Abstraktion ermöglicht es Microsoft, um dies zu verbessern im Laufe der Zeit.
  2. Weniger flexibel:Sprocs in vollem Umfang nutzen können, eine Datenbank featureset.LINQ eher generisch, es ist Unterstützung.Dies ist üblich, in jeder Art von Sprache Abstraktionen (z.B.C# vs-assembler).
  3. Kompilieren:Wenn Sie änderungen vornehmen müssen, um die Art, wie Sie Daten zuzugreifen, Sie neu kompilieren zu müssen, version, und strukturieren Sie Ihre Montage.Sprocs können manchmal erlauben einem DBA tune the data access routine ohne erneut bereitstellen müssen nichts.

Sicherheit und Verwaltbarkeit sind etwas, was die Leute darüber streiten, zu.

  1. Sicherheit:Für Beispiel, Sie können schützen Ihre sensiblen Daten, indem Sie den Zugriff auf die Tabellen direkt, und legen Sie ACLs auf die sprocs.Mit LINQ können Sie jedoch immer noch den direkten Zugriff auf Tabellen und stattdessen ACLs auf aktualisierbare Tabelle Ansichten zu erreichen ein ähnliches Ende (vorausgesetzt, dass Ihre Datenbank unterstützt updatable views).
  2. Verwaltbarkeit:Mithilfe von Ansichten gibt Ihnen auch den Vorteil der Abschirmung Ihrer Anwendung nicht brechen von schema-änderungen (wie Tabellen Normalisierung).Können Sie die Ansicht aktualisieren, ohne dass Ihre Daten zugreifen-code zu ändern.

Ich verwendet, um eine große sproc Kerl, aber ich bin ab zu lehnen in Richtung LINQ als eine bessere alternative im Allgemeinen.Wenn es einige Bereiche, in denen sprocs sind deutlich besser ist, dann werde ich wohl noch schreiben eine sproc aber der Zugriff mit LINQ.:)

Andere Tipps

Ich bin generell ein Befürworter von setzen alles in gespeicherten Prozeduren, aus all den Gründen, die für DBAs wurden herumreiten auf für Jahre.Im Fall von Linq, es ist wahr, dass es keine performance-Unterschied mit einfachen CRUD-Abfragen.

Aber halten Sie ein paar Dinge Bedenken, wenn die Entscheidung:mit jedem ORM Paare Sie Sie fest, um Ihre Daten Modell.Ein DBA hat keine Freiheit, um änderungen des Datenmodells, ohne Sie zu zwingen, ändern Sie Ihren code kompiliert.Mit gespeicherten Prozeduren können Sie ausblenden von diesen Arten von Veränderungen in einem Ausmaß, da die parameter-Liste und-Ergebnisse set(s) zurückgegeben, die von einem Verfahren darstellen, den Vertrag, und die Innereien kann verändert werden um, gerade so lange, dass der Vertrag noch eingehalten.

Und auch, wenn Linq verwendet wird, für komplexere Abfragen, tuning der Datenbank wird eine viel schwierigere Aufgabe.Wenn eine gespeicherte Prozedur ausgeführt wird langsam kann der DBA die ganz auf den code konzentrieren, sich in isolation, und hat eine Menge von Optionen, nur damit, dass der Vertrag immer noch zufrieden, wenn er/Sie fertig ist.

Ich habe gesehen, viele, viele Fälle, in denen schwerwiegende Probleme in einer Anwendung wurden behoben, indem die änderungen am schema und code in gespeicherte Prozeduren ohne änderung bereitgestellt, die kompilierten code.

Vielleicht ein Hybrid-Ansatz wäre schön mit Linq?Linq kann natürlich verwendet werden, um die gespeicherten Prozeduren aufrufen.

Linq zu Sql.

Sql-server-cache der Abfrage-Pläne, also gibt es keine performance-Gewinn für sprocs.

Ihre linq-Anweisungen, auf der anderen Seite, wird logischerweise Teil und getestet mit Ihrer Anwendung.Sprocs sind immer ein bisschen getrennt und sind schwieriger zu pflegen und zu testen.

Wenn ich arbeitete an einer neuen Anwendung von Grund auf neu jetzt würde ich nur verwenden Sie Linq, keine sprocs.

Für basic-Daten-retrieval-ich würde für Linq, ohne zu zögern.

Seit dem Umzug in Linq-ich habe festgestellt, das folgende Vorteile:

  1. Debuggen von meinem DAL ist nie einfacher gewesen.
  2. Compile-Zeit sich in Sicherheit, wenn Ihr schema ändert, ist unbezahlbar.
  3. Die Bereitstellung ist es einfacher denn alles ist zusammengestellt in DLL.Nicht mehr die Verwaltung von deployment-Skripten.
  4. Da Linq unterstützen können Abfragen nichts, die die IQueryable-Schnittstelle, werden Sie in der Lage zu verwenden die gleiche syntax zum Abfragen von XML-Objekte und jede andere Datenquelle, ohne eine neue syntax zu lernen

LINQ wird aufblasen der Prozedur-cache

Wenn eine Anwendung unter Verwendung von LINQ to SQL und den Abfragen mit der Verwendung von Zeichenfolgen, die können sehr variabel in der Länge, die SQL Server-Prozedur-cache wird aufgebläht, die mit einer version der Abfrage für jede mögliche Schnur Länge.Betrachten Sie beispielsweise das folgende sehr einfache Abfragen gegen die Person.AddressTypes Tabelle in der AdventureWorks2008-Datenbank:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Wenn Sie die beiden folgenden Abfragen ausführen, werden wir sehen zwei Einträge in der SQL Server-Prozedur-cache:Eine Schranke mit einer NVARCHAR(7), und die andere mit einer NVARCHAR(11).Stell dir jetzt vor, wenn es Hunderte oder Tausende von verschiedenen input-strings, die alle mit unterschiedlichen Längen.Die Prozedur-cache würde unnötig gefüllt mit allen möglichen verschiedenen Pläne für die exakt gleiche Abfrage.

Mehr hier: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Ich denke, die pro LINQ argument zu sein scheint, kommen von Menschen, die nicht haben eine Geschichte mit der Datenbank-Entwicklung (allgemein).

Vor allem, wenn mit einem Produkt wie VS DB Pro oder Team Suite, viele der Argumente, die hier nicht gelten, zum Beispiel:

Schwieriger zu pflegen und zu Testen:VS bietet vollständige syntax checking, stilprüfung, referentieller constraint prüfen und mehr.Es auch bieten volle unit-testing-Fähigkeiten und refactoring-tools.

LINQ macht echte unit-Tests unmöglich, da (in meinen Augen) scheitert es bei der SÄURE-test.

Debuggen ist einfacher in LINQ:Warum?VS ermöglicht die vollständige Schritt-in die von verwaltetem code und regelmäßige Debuggen von SPs.

In einer einzigen DLL kompiliert, anstatt deployment scripts:Einmal wieder, VS kommt zur Rettung, wo es erstellen und bereitstellen vollständiger Datenbanken oder Daten-safe inkrementelle änderungen.

Nicht haben, um zu erfahren, TSQL mit LINQ:Nein, Sie nicht, aber Sie müssen lernen, LINQ - wo ist der nutzen?

Ich sehe wirklich nicht, dies als einen Vorteil.Werden in der Lage, etwas zu ändern, in isolation klingt gut in der Theorie, aber nur, weil die änderungen die Erfüllung eines Vertrages, bedeutet nicht, dass es Rücksendung der korrekte Ergebnisse.Um in der Lage sein, zu bestimmen, was die richtigen Ergebnisse werden Sie brauchen Kontext und Sie erhalten den Kontext des aufrufenden Codes.

Ähm, lose gekoppelte apps sind das ultimative Ziel, alle guten Programmierer, wie Sie wirklich erhöhen die Flexibilität.Lage, Dinge zu ändern, die in isolation ist fantastisch, und es ist Ihre unit-tests, dass sorgt dafür, dass Sie immer noch zurückgeben entsprechenden Ergebnisse.

Bevor Sie alle aufgeregt, ich denke, LINQ seinen Platz hat und eine große Zukunft.Aber für komplexe, datenintensive Anwendungen ich glaube nicht, dass es bereit ist, an die Stelle von gespeicherten Prozeduren.Dies war eine Ansicht, die ich hatte, hallte von einem MVP an der TechEd in diesem Jahr (der namenlos bleiben).

EDIT:Die LINQ-zu-SQL-Stored-Procedure Seite der Dinge ist etwas, was ich noch brauche, um mehr zu Lesen auf - je nachdem, was ich finde, ich kann ändern mein oben diatribe ;)

LINQ ist neu und hat seinen Platz.LINQ ist nicht erfunden, um ersetzen Sie die gespeicherte Prozedur.

Hier konzentriere ich mich auf einige performance-Mythen-und NACHTEILE, nur für "LINQ to SQL", natürlich könnte ich völlig falsch ;-)

(1)die Leute sagen LINQ-Anweisung kann "cache-Speicher" in SQL server, so dass es nicht an Leistungsfähigkeit verlieren.Teilweise wahr."LINQ to SQL" tatsächlich ist die Laufzeit der übersetzung von LINQ-syntax TSQL-Anweisung.So aus der performance-Perspektive,eine hartcodierte ADO.NET SQL-Anweisung keinen Unterschied als LINQ.

(2)ein Beispiel Gegeben, ein Kunden-service-Benutzeroberfläche hat ein "Konto übertragen" Funktion.diese Funktion kann update 10 DB-Tabellen und wieder einige Nachrichten in einem Schuss.Mit LINQ, Sie haben zu bauen, ein Satz von Anweisungen und senden Sie Sie als eine batch-SQL-server.die Leistung dieses übersetzt LINQ->TSQL-batch kann kaum passen gespeicherte Prozedur.Der Grund?denn Sie können zwicken die kleinste Einheit der Anweisung in der Gespeicherten procedue mithilfe der integrierten SQL-profiler und Ausführungsplan-tool, Sie können nicht tun dies in LINQ.

Der Punkt ist, wenn man einzelne DB Tabelle und kleinen Satz von Daten, CRUD, LINQ ist so schnell, wie SP.Aber für viel mehr komplizierte Logik, die gespeicherte Prozedur wird mehr Leistung tweakable.

(3)"LINQ to SQL" leicht macht, Neulinge einzuführen, Leistung Schweine.Jeder leitende TSQL-Mann kann Ihnen sagen, Wann nicht zu verwenden CURSOR (im Grunde sollten Sie nicht verwenden Sie CURSOR in TSQL in den meisten Fällen).Mit LINQ und dem charmanten "foreach" - Schleife mit Abfrage, Es ist so einfach für einen Neuling, zu schreiben, wie code:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Sie können sehen, dass dies einfach anständig code ist so attraktiv.Aber unter der Haube .NET runtime just translate dieses eine update-batch.Wenn es nur 500 Zeilen, diese ist 500 line TSQL-batch;Wenn es sind Millionen Zeilen, das ist ein hit.Natürlich, erfahrene Benutzer nicht verwenden diese Art, diese Arbeit zu tun, aber der Punkt ist, es ist so leicht zu fallen in diese Weise.

Der beste code ist kein code, und mit gespeicherten Prozeduren, die Sie schreiben müssen mindestens ein code in der Datenbank und code in die Anwendung zu nennen , in der Erwägung, dass mit LINQ to SQL oder LINQ to Entities, Sie nicht haben zu schreiben jeden zusätzlichen code über jedes andere LINQ-Abfrage abgesehen von der Instanziierung ein context-Objekt.

LINQ hat definitiv seinen Platz in der Applikations-spezifische Datenbanken und in kleinen Unternehmen.

Aber in einem großen Unternehmen, wo eine zentrale Datenbanken dienen als hub-gemeinsame Daten für viele Anwendungen, brauchen wir eine Abstraktion.Wir müssen die Sicherheit zentral verwalten können und zeigen Sie den Zugriff Geschichten.Wir müssen in der Lage sein zu tun impact-Analyse:wenn ich eine kleine änderung an den Daten Modell zu dienen, ein neues business zu müssen, welche Abfragen geändert werden müssen und welche Anwendungen müssen neu geprüft werden?Ansichten und Gespeicherten Prozeduren geben Sie mir, dass.Wenn LINQ all das tun können, und machen unsere Programmierer mehr produktiv, ich werde es begrüßen, -- hat jemand Erfahrung mit, die es in dieser Art von Umgebung?

Ein DBA hat keine Freiheit änderungen zu machen, das Datenmodell, ohne dass Sie ändern Sie Ihren kompilierten code.Mit gespeicherte Prozeduren, können Sie diese ausblenden Arten von Veränderungen in einem Ausmaß, da der Liste der parameter und Ergebnisse(s) aus einer Prozedur zurückgegeben darstellen seinen Vertrag, und die Innereien werden können geändert herum, gerade so lange, dass Vertrag noch eingehalten.

Ich sehe wirklich nicht, dies als einen Vorteil.Werden in der Lage, etwas zu ändern, in isolation klingt gut in der Theorie, aber nur, weil die änderungen die Erfüllung eines Vertrages, bedeutet nicht, dass es Rücksendung der korrekte Ergebnisse.Um in der Lage sein, zu bestimmen, was die richtigen Ergebnisse werden Sie brauchen Kontext und Sie erhalten den Kontext des aufrufenden Codes.

IMHO, RAD = LINQ RUP = Stored Procs.Ich arbeitete für eine große Fortune-500-Unternehmen für viele Jahre, auf vielen Ebenen, einschließlich der Verwaltung, und ehrlich gesagt, ich würde nie mieten RUP-Entwicklern eine RAD Entwicklung.Sie sind so begrenzt, dass Sie nur sehr geringe Kenntnisse von, was zu tun ist, auf anderen Ebenen des Prozesses.Mit einer zentralisierten Umgebung, macht es Sinn zu geben, DBAs, die Kontrolle über die Daten, die durch sehr bestimmte Einstiegspunkte, weil andere sich ehrlich gesagt nicht wissen, die besten Möglichkeiten zu erreichen Daten-management.

Aber große Unternehmen bewegen schmerzhaft langsam in der Entwicklung arena, und das ist sehr teuer.Es gibt Zeiten, wenn Sie brauchen, um schneller zu sparen Sie Zeit und Geld, und LINQ bietet das und mehr in Pik.

Manchmal denke ich, dass DBAs sind voreingenommen gegen LINQ, weil Sie denken, es droht Ihren job security.Aber das ist die Natur der Bestie, meine Damen und Herren.

Ich glaube, Sie müssen gehen mit procs für etwas wirkliches.

A) Schreiben Sie alle Ihre Logik in linq bedeutet, dass Ihre Datenbank ist weniger hilfreich, da nur Ihre Anwendung kann zu verzehren.

B) ich bin nicht davon überzeugt, dass die Objekt-Modellierung ist besser als relationale Modellierung sowieso.

C) Testen und entwickeln eine gespeicherte Prozedur in SQL ist eine Hölle von viel schneller als ein kompilieren Bearbeiten Zyklus in jedem Visual Studio-Umgebung.Sie gerade Bearbeiten, F5 und drücken Sie wählen und Sie sind aus dem Rennen.

D) Es ist leichter zu verwalten und implementieren von gespeicherten Prozeduren als Assemblys..Sie setzen einfach die Datei auf dem server, und drücken Sie F5,...

E) Linq to sql noch schreibt beschissenen code zu Zeiten, wenn Sie es nicht erwarten.

Ehrlich gesagt, ich glaube das ultimative Ding wäre für MS zu verstärken, t-sql, so dass es tun können Sie eine join-Projektion impliclitly den Weg linq funktioniert.t-sql wissen sollten, wenn Sie wollten, um zu tun.lineitems.Teil, zum Beispiel.

LINQ nicht verbieten die Verwendung von gespeicherten Prozeduren.Ich habe im gemischten Modus mit LINQ-SQL und LINQ-storedproc.Ich persönlich bin froh, dass ich nicht haben zu schreiben die gespeicherten procs....pwet-tu.

Es gibt auch das Problem der möglichen 2.0 rollback.Vertrauen Sie mir, es ist mir passiert ein paar mal so, ich bin sicher, dass es passiert ist, die anderen.

Ich bin damit einverstanden, dass Abstraktion ist die beste.Zusammen mit der Tatsache, der ursprüngliche Zweck ein ORM ist RDBMS-match-up-nett zu den OO-Konzepten.Aber wenn alles geklappt hat, bevor LINQ, indem er, um ein bisschen Abgehen von OO-Konzepten dann screw 'em.Konzepte und Realität nicht immer passen gut zusammen.Es gibt keinen Raum für militante Eiferer in ES.

Ich nehme an, du meinst Linq To Sql

Für jede CRUD-Befehl, es ist einfach die Leistung eine gespeicherte Prozedur vs.jede Technologie.In diesem Fall besteht kein Unterschied zwischen den beiden wird vernachlässigbar sein.Versuchen, die Profilerstellung für eine 5 (simple types) field-Objekt über 100.000 select-Abfragen finden Sie heraus, ob es einen echten Unterschied.

Auf der anderen Seite die real deal-breaker sein wird, die Frage auf, ob Sie sich wohl fühlen, setzen Sie Ihre business-Logik in der Datenbank, oder nicht, das ist ein argument gegen gespeicherten Prozeduren.

Nach gurus, ich definieren, LINQ als Motorrad-und SP car.Wenn Sie möchten, gehen für einen kurzen Ausflug und haben nur kleine Passagiere(in diesem Fall 2), gehen Sie würdevoll mit LINQ.Aber wenn Sie gehen wollen für eine Reise und haben große band, ich denke, Sie sollten entscheiden, SP.

Als Fazit, das die Auswahl zwischen ein Motorrad oder ein Auto ist, hängt von Ihrer route (business), Länge (Zeit), und die Passagiere (Daten).

Hoffe es hilft, ich kann mich auch irren.:D

Alle diese Antworten, die Neigung zu LINQ sind vor allem reden über die EINFACHE ENTWICKLUNG, die mehr oder weniger verbunden mit der schlechten Qualität der Codierung oder Faulheit im Code.Ich bin wie, dass nur.

Einige Vorteile von Linq, die ich hier gelesen habe, wie , einfach zu testen, einfach zu Debuggen usw., aber diese sind nicht angeschlossen, um die Endgültigen output-oder end-Benutzer.Dies ist immer die Mühe verursachen, die Ende-Benutzer auf die performance aus.Was ist der Punkt laden viele Dinge in Erinnerung und die Anwendung von filtern auf die in der Verwendung von LINQ?

Wieder TypeSafety, ist Vorsicht geboten, dass "wir sind vorsichtig zu vermeiden falsche typecasting", die wieder schlechter Qualität wir sind versuchen zu verbessern, indem Sie mithilfe von linq.Auch in diesem Fall, wenn etwas in der Datenbank ändert, z.B.Größe der String-Spalte, dann linq Bedürfnisse zu werden re-kompiliert und würde nicht typesafe, ohne dass ..Ich habe es versucht.

Obwohl wir gefunden haben, ist gut, süß, interessant, etc. bei der Arbeit mit LINQ, es hat scher Nachteil der Herstellung Entwickler faul :) und es ist bewiesen, 1000 mal, dass es schlecht ist (vielleicht am schlimmsten) auf die performance im Vergleich zu den Gespeicherten Procs.

Stoppen Sie faul sind.Ich bin stark versucht.:)

Für einfache CRUD-Operationen mit einem einzigen Daten-access-point, ich würde sagen, gehen Sie für LINQ wenn Sie sich wohl fühlen mit der syntax.Für kompliziertere Logik, die ich denke, sprocs sind mehr effektiv ist performance-Weise, wenn Sie sind gut in T-SQL und mehr erweiterte Funktionen.Sie haben auch die Hilfe von Tuning Advisor, SQL Server Profiler für debugging Ihrer Anfragen SSMS etc.

Gespeicherte Prozedur macht das testen einfacher und Sie können die Abfrage ändern, ohne den code der Anwendung.Auch mit linq, immer eine Daten nicht bedeuten, dass es die richtigen Daten.Und die Prüfung der Richtigkeit der Daten bedeutet, dass Sie die Anwendung ausführen, aber mit der gespeicherten Prozedur, es ist einfach zu testen ohne Sie zu berühren die Anwendung.

Die Ergebnisse können wie folgt zusammengefasst werden

LinqToSql für kleine Websites und Prototypen.Es spart wirklich Zeit für das Prototyping.

Sps :Universal.Ich kann die Feinabstimmung meine Fragen und überprüfen Sie immer ActualExecutionPlan / EstimatedExecutionPlan.

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

Sowohl LINQ und SQL haben Ihre Plätze ein.Beide haben Ihre vor-und Nachteile.

Manchmal für komplexe Daten abrufen, die Sie benötigen könnten, gespeicherte Prozeduren.Und manchmal möchten Sie vielleicht anderen Menschen zu, verwenden Sie Ihre gespeicherte Prozedur in Sql Server Management Studio.

Linq to Entities ist ideal für schnelle CRUD-Entwicklung.

Sicher, Sie können erstellen Sie eine app mit nur einer oder der anderen.Oder Sie können es mischen.Es kommt alles auf Ihre Anforderungen.Aber SQL gespeicherte Prozeduren wird nicht gehen Weg jederzeit bald.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top