Statische versus dynamische sql

Uw voorbeeldcode is zo eenvoudig dat er weinig verschil zal zijn, maar in dat geval zou de statische versie waarschijnlijk beter werken.

De belangrijkste reden om dynamische SQL te gebruiken voor prestaties is wanneer de SQL-instructie aanzienlijk kan variëren - d.w.z. dat u tijdens runtime extra code aan de WHERE-component kunt toevoegen op basis van de status van het systeem (beperking door een subquery op adres, indien adres ingevoerd, enz.).

Een andere reden is dat het soms contraproductief kan zijn om Bind-variabelen als parameters te gebruiken.

Een voorbeeld is als je zoiets als een statusveld hebt, waar gegevens niet gelijkmatig zijn verdeeld (maar wel geïndexeerd).

Overweeg de volgende 3 uitspraken, wanneer 95% van de gegevens 'P'rocessed is

   SELECT col FROM table 
   WHERE status = 'U'-- unprocessed
   AND company = :company

   SELECT col FROM table 
   WHERE status = 'P' -- processed
   AND company = :company

   SELECT col FROM table
   WHERE status = :status
   AND company = :company

In de definitieve versie kiest Oracle voor een generiek uitlegplan. In de eerste versie kan het besluiten dat het het beste is om te beginnen met de index op status (wetende dat 'niet-verwerkte invoer' een zeer klein deel van het totaal is).

Je zou dat kunnen implementeren door middel van verschillende statische instructies, maar waar je complexere instructies hebt die slechts een paar tekens veranderen, kan dynamische SQL een betere optie zijn.

Nadelen

Elke herhaling van dezelfde dynamische SQL-instructie leidt tot een zachte ontleding, wat een kleine overhead is in vergelijking met een statische instructie, maar nog steeds een overhead.

Elke NIEUWE sql-instructie (dynamisch of statisch) leidt ook tot een slot op de SGA (gedeeld geheugen) en kan ertoe leiden dat 'oude' instructies worden verwijderd.

Een slecht, maar algemeen systeemontwerp is dat iemand dynamische SQL gebruikt om eenvoudige selecties te genereren die alleen per sleutel verschillen - d.w.z.

SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7

De individuele verklaringen zullen snel zijn, maar de algehele systeemprestaties zullen verslechteren, omdat het de gedeelde bronnen doodt.

Ook is het veel moeilijker om fouten tijdens het compileren op te vangen met dynamische SQL. Als u PL/SQL gebruikt, gooit dit een goede compilatietijdcontrole weg. Zelfs als je iets als JDBC gebruikt (waar je al je databasecode naar strings verplaatst - goed idee!) kun je pre-parsers krijgen om de JDBC-inhoud te valideren. Dynamische SQL =alleen runtime-testen.

Overhead

De overhead van execute instant is klein - het is in de duizendsten van een seconde - het kan echter oplopen als dit binnen een lus is / op een methode die eenmaal per object wordt aangeroepen / etc. Ik heb ooit een snelheidsverbetering van 10x gekregen door dynamische te vervangen SQL met gegenereerde statische SQL. Dit bemoeilijkte echter de code en werd alleen gedaan omdat we de snelheid nodig hadden.