8 Dynamisk SQL (Norsk)

Dynamisk SQL er en programmeringsteknikk som lar deg bygge SQL-setninger dynamisk ved kjøretid. Du kan lage mer generelle, fleksible applikasjoner ved å bruke dynamisk SQL fordi fullteksten til en SQL-setning kan være ukjent ved kompilering. For eksempel lar dynamisk SQL deg lage en prosedyre som fungerer på en tabell hvis navn ikke er kjent før kjøretid.

I tidligere versjoner av Oracle var den eneste måten å implementere dynamisk SQL i et PL / SQL-program på. ved hjelp av DBMS_SQL -pakken. Oracle8i introduserer innfødt dynamisk SQL, et alternativ til DBMS_SQL -pakken. Ved å bruke innfødt dynamisk SQL kan du plassere dynamiske SQL-setninger direkte i PL / SQL-blokker.

Dette kapittelet dekker følgende emner:

• Hva er Dynamic SQL?
• Når skal du bruke dynamisk SQL
• Et dynamisk SQL-scenario som bruker innfødt dynamisk SQL
• Innfødt dynamisk SQL kontra DBMS_SQL-pakken
• Applikasjon Utviklingsspråk annet enn PL / SQL

Hva er dynamisk SQL?

Dynamisk SQL lar deg skrive programmer som refererer til SQL-setninger hvis fulltekst ikke er kjent før kjøretid. Før du diskuterer dynamisk SQL i detalj, kan en klar definisjon av statisk SQL gi et godt utgangspunkt for å forstå dynamisk SQL. Statiske SQL-setninger endres ikke fra kjøring til kjøring. Hele teksten til statiske SQL-setninger er kjent under kompilering, noe som gir følgende fordeler:

• Vellykket kompilering verifiserer at SQL-setningene refererer til gyldige databaseobjekter.
• Vellykket kompilering verifiserer at nødvendige rettigheter er på plass for å få tilgang til databaseobjektene.
• Ytelse for statisk SQL er generelt bedre enn dynamisk SQL.

På grunn av disse fordelene, bør du bare bruke dynamisk SQL hvis du ikke kan bruke statisk SQL for å nå dine mål, eller hvis bruk av statisk SQL er tungvint sammenlignet med dynamisk SQL. Imidlertid har statisk SQL begrensninger som kan overvinnes med dynamisk SQL. Det kan hende at du ikke alltid kjenner hele teksten til SQL-setningene som må utføres i en PL / SQL-prosedyre. Programmet ditt godtar muligens brukerinngang som definerer SQL-setningene som skal utføres, eller programmet kan trenge å fullføre noe bearbeidingsarbeid for å bestemme riktig fremgangsmåte. I slike tilfeller bør du bruke dynamisk SQL.

Tenk for eksempel på et rapporteringsapplikasjon som utfører standardforespørsler på tabeller i et datalagermiljø der det eksakte tabellnavnet er ukjent frem til kjøretid. For å imøtekomme den store datamengden i datalageret effektivt lager du en ny tabell hvert kvartal for å lagre fakturainformasjonen for kvartalet. Disse tabellene har alle nøyaktig samme definisjon og er navngitt i henhold til startmåneden og året i kvartalet, for eksempel INV_01_1997, INV_04_1997, INV_07_1997, INV_10_1997, INV_01_1998 osv. I et slikt tilfelle kan du bruke dynamisk SQL i rapporteringsapplikasjonen for å spesifisere tabellnavnet ved kjøretid.

Med statisk SQL må all datadefinisjonsinformasjonen, for eksempel tabelldefinisjoner, referert til av SQL-setningene i programmet, være kjent under kompilering. Hvis datadefinisjonen endres, må du endre og kompilere programmet på nytt. Dynamiske SQL-programmer kan håndtere endringer i datadefinisjonsinformasjon, fordi SQL-setningene kan endres «i farta» ved kjøretid. Derfor er dynamisk SQL mye mer fleksibel enn statisk SQL. Dynamisk SQL lar deg skrive applikasjonskode som kan brukes på nytt fordi koden definerer en prosess som er uavhengig av de spesifikke SQL-setningene som brukes.

I tillegg lar dynamisk SQL deg utføre SQL-setninger som ikke støttes i statisk SQL-programmer, slik som DDL-utsagn (Data Definition Language). Støtte for disse utsagnene lar deg oppnå mer med PL / SQL-programmene dine.

Når skal du bruke dynamisk SQL

Du bør bruke dynamisk SQL i tilfeller der statisk SQL ikke støtter operasjonen du vil utføre, eller i tilfeller der du ikke vet de eksakte SQL-setningene som må utføres av en PL / SQL-prosedyre. Disse SQL-setningene kan avhenge av brukerinndata, eller de kan avhenge av behandlingsarbeidet som er utført av programmet. De følgende avsnittene beskriver typiske situasjoner der du bør bruke dynamisk SQL og typiske problemer som kan løses ved å bruke dynamisk SQL.

Slik kjører du dynamiske DML-uttalelser

Du kan bruke dynamisk SQL til å utføre DML-setninger der den eksakte SQL-setningen ikke er kjent før kjøretiden.For eksempler, se DML-eksemplene i «Eksempler på DBMS_SQL-pakkekode og innfødt dynamisk SQL-kode» og «Eksempel på DML-operasjon».

Å utføre uttalelser som ikke støttes av statisk SQL i PL / SQL

I PL / SQL kan du ikke utføre følgende typer utsagn ved bruk av statisk SQL:

• DDL-utsagn (Data definition language), for eksempel CREATE, DROP, GRANT, og REVOKE
• Sessionsuttalelser (SCL), slik som ALTER SESSION og SET ROLE
  Se også:

  Oracle8i SQL-referanse for informasjon om DDL- og SCL-setninger.

Bruk dynamisk SQL hvis du trenger å utføre noen av disse typene utsagn i en PL / SQL-blokk.

I tillegg tillater ikke statisk SQL i PL / SQL bruk av TABLE -klausulen i SELECT uttalelser. Det er ingen slik begrensning i dynamisk SQL. Følgende PL / SQL-blokk inneholder for eksempel en SELECT -uttalelse som bruker TABLE -setningen og innfødt dynamisk SQL:

Slik utfører du dynamiske spørsmål

Du kan bruke dynamisk SQL til å opprette applikasjoner som utfører dynamiske spørsmål, som er spørsmål hvis fulltekst ikke er kjent før kjøretid. Mange typer applikasjoner må bruke dynamiske spørsmål, inkludert:

• Programmer som lar brukerne legge inn eller velge søk eller sorteringskriterier ved kjøretid
• Programmer som lar brukerne legge inn eller velg optimeringshint på kjøretid
• Applikasjoner som spør etter en database der datadefinisjonene til tabeller stadig endres
• Programmer som spør etter en database der nye tabeller opprettes ofte

For eksempler, se «Spørreeksempel» og se spørreeksemplene i «Et dynamisk SQL-scenario som bruker innfødt dynamisk SQL».

For å referere til databaseobjekter som ikke eksisterer ved kompilering

Mange typer applikasjoner må samhandle med data som genereres med jevne mellomrom. For eksempel kan det være mulig å bestemme definisjonen av databasetabellene ved kompilering, men ikke navnene på tabellene, fordi nye tabeller genereres med jevne mellomrom. Søknaden din trenger tilgang til dataene, men det er ingen måte å vite de eksakte navnene på tabellene til kjøretiden.

Dynamisk SQL kan løse dette problemet, fordi dynamisk SQL lar deg vente til kjøretiden for å spesifisere tabellnavn du trenger tilgang til. For eksempel i eksemplet på datalagerprogrammet som er diskutert i «Hva er dynamisk SQL?», Genereres nye tabeller hvert kvartal, og disse tabellene har alltid samme definisjon. I dette tilfellet kan du tillate en bruker å spesifisere navnet på tabellen ved kjøretid med et dynamisk SQL-spørsmål som ligner på følgende:

For å optimalisere utførelsen dynamisk

Hvis du bruker statisk SQL, må du ved kompilering bestemme hvordan du vil konstruere SQL-setningene dine, om du vil ha hint i uttalelsene dine, og hvis du inkluderer hint, nøyaktig hvilke hint du skal ha. Du kan imidlertid bruke dynamisk SQL til å bygge en SQL-setning på en måte som optimaliserer utførelsen og / eller sammenkobler hintene til en SQL-setning dynamisk. Dette lar deg endre hintene basert på din nåværende databasestatistikk uten å kreve rekompilering.

For eksempel bruker følgende fremgangsmåte en variabel kalt a_hint for å tillate brukere for å overføre et hintalternativ til SELECT -uttalelsen:

I dette eksemplet kan brukeren sende en av følgende verdier for a_hint:

For å påkalle dynamiske PL / SQL-blokker

Du kan bruke EXECUTE IMMEDIATE uttalelse for å påkalle anonyme PL / SQL-blokker. Evnen til å påkalle dynamiske PL / SQL-blokker kan være nyttig for applikasjonsutvidelse og tilpasning der modulen som skal utføres bestemmes dynamisk ved kjøretid.

Anta for eksempel at du vil skrive et program som tar en hendelse nummer og forsendelse til en behandler for arrangementet. Navnet på behandleren er i skjemaet EVENT_HANDLER_ event_num, der event_num er nummeret på hendelsen. En tilnærming ville være å implementere utsenderen som en bryteruttalelse, som vist nedenfor, hvor koden håndterer hver hendelse ved å ringe et statisk anrop til den aktuelle håndtereren.

Denne koden er ikke veldig utvidbar fordi avsenderkoden må oppdateres hver gang en behandler for et nytt arrangement legges til. Ved å bruke innfødt dynamisk SQL kan du imidlertid skrive en utvidbar hendelsesavsender som ligner på følgende:

For å utføre dynamiske operasjoner ved hjelp av Invoker-rettigheter

Ved å bruke invoker-rights-funksjonen med dynamisk SQL, du kan bygge applikasjoner som utsteder dynamiske SQL-setninger under privilegiene og skjemaet til innkalleren.Disse to funksjonene, invoker-rettigheter og dynamisk SQL, lar deg bygge gjenbrukbare applikasjonskomponenter som kan fungere på og få tilgang til invokerens data og moduler.

Et dynamisk SQL-scenario ved bruk av innfødt dynamisk SQL

Scenariet beskrevet i dette avsnittet illustrerer kraften og fleksibiliteten av innfødt dynamisk SQL. Dette scenariet inneholder eksempler som viser deg hvordan du utfører følgende operasjoner ved hjelp av innfødt dynamisk SQL:

• Utfør DDL- og DML-operasjoner
• Utfør enkle rad- og flere radspørringer

Datamodell

Databasen i dette scenariet er en virksomhets menneskelige ressursdatabase (kalt hr) med følgende datamodell :

En mastertabell med navnet offices inneholder listen over alle selskapets lokasjoner. offices -tabellen har følgende definisjon :

Column Name Null? Type LOCATION NOT_NULL VARCHAR2(200)

Flere emp_ plasseringstabeller inneholder informasjon om de ansatte, der stedet er navnet på byen der kontoret er lokalisert. For eksempel inneholder en tabell med navnet emp_houston medarbeiderinformasjon for selskapets Houston-kontor, mens en tabell med navnet emp_boston inneholder ansatt informasjon for selskapets Boston-kontor.

Hver emp_ plasseringstabell har følgende definisjon:

Følgende seksjoner beskriver forskjellige innfødte dynamiske SQL-operasjoner som kan utføres på dataene i hr database.

Eksempel på DML-operasjon

Følgende innfødte dynamiske SQL-prosedyre gir løft til alle ansatte med en bestemt stillingstittel:

Eksempel på DDL-operasjon

Uttalelsen EXECUTE IMMEDIATE kan utføre DDL-operasjoner. Følgende prosedyre legger for eksempel til et kontorsted:

Følgende prosedyre sletter et kontorsted:

Eksempel på dynamisk enkeltradsspørring

EXECUTE IMMEDIATE -erklæring kan utføre dynamiske enkeltradsspørsmål. Du kan spesifisere bindingsvariabler i USING -satsen og hente den resulterende raden til målet som er spesifisert i INTO -setningen i utsagnet.

Følgende funksjon henter antall ansatte på et bestemt sted som utfører en spesifisert jobb:

Eksempel på dynamisk flere-radsspørring

OPEN-FOR, FETCH og CLOSE -uttalelser kan utføre dynamiske spørringer med flere rader. Følgende prosedyre viser for eksempel alle ansatte med en bestemt jobb på et spesifisert sted:

Innfødt dynamisk SQL kontra DBMS_SQL-pakken

Oracle tilbyr to metoder for bruk av dynamisk SQL innen PL / SQL: innfødt dynamisk SQL og DBMS_SQL -pakken. Innfødt dynamisk SQL lar deg plassere dynamiske SQL-setninger direkte i PL / SQL-kode. Disse dynamiske setningene inkluderer DML-setninger (inkludert spørsmål), PL / SQL anonyme blokker, DDL-setninger, transaksjonskontrolluttalelser og sesjonskontrolluttalelser.

For å behandle de fleste innfødte dynamiske SQL-setningene, bruker du EXECUTE IMMEDIATE uttalelse. For å behandle et flerradespørsmål (SELECT -uttalelse) bruker du OPEN-FOR, FETCH og CLOSE utsagn.

DBMS_SQL -pakken er et PL / SQL-bibliotek som tilbyr et programmatisk API til utføre SQL-setninger dynamisk. DBMS_SQL -pakken har programmatiske grensesnitt for å åpne en markør, analysere en markør, forsyningsbindinger osv. Programmer som bruker DBMS_SQL -pakken ringer til denne pakken for å utføre dynamiske SQL-operasjoner.

Følgende avsnitt gir detaljert informasjon om fordelene med begge metodene.

Fordeler med innfødt dynamisk SQL

Innfødt dynamisk SQL gir følgende fordeler i forhold til DBMS_SQL pakke:

Brukervennlighet

Innfødt dynamisk SQL er mye enklere å bruke enn DBMS_SQL -pakken.Fordi naturlig dynamisk SQL er integrert med SQL, kan du bruke den på samme måte som du for tiden bruker statisk SQL i PL / SQL-kode. I tillegg er innfødt dynamisk SQL-kode vanligvis mer kompakt og lesbar enn ekvivalent kode som bruker DBMS_SQL -pakken.

DBMS_SQL -pakken er ikke like enkel å bruke som innfødt dynamisk SQL. Det er mange prosedyrer og funksjoner som må brukes i en streng rekkefølge. Vanligvis krever utføring av enkle operasjoner en stor mengde kode når du bruker DBMS_SQL -pakken. Du kan unngå denne kompleksiteten ved å bruke naturlig dynamisk SQL i stedet.

Tabell 8-1 illustrerer forskjellen i mengden kode som kreves for å utføre den samme operasjonen ved hjelp av DBMS_SQL pakke og innfødt dynamisk SQL.

Tabell 8-1 Kodesammenligning av DBMS_SQL-pakke og Native Dynamic SQL

Ytelsesforbedringer

Ytelsen til native dynamisk SQL i PL / SQL er sammenlignbar med ytelsen til statisk SQL fordi PL / SQL-tolken har innebygd støtte for native dynamisk SQL. Derfor er ytelsen til programmer som bruker innebygd dynamisk SQL, mye bedre enn for programmer som bruker DBMS_SQL -pakken. Vanligvis utfører native dynamiske SQL-setninger 1,5 til 3 ganger bedre enn tilsvarende setninger som bruker DBMS_SQL -pakken. Selvfølgelig kan resultatene dine variere avhengig av søknaden din.

DBMS_SQL -pakken er basert på en prosedyre-API, og som et resultat påløper den høye prosedyren for samtale- og datakopiering. Hver gang du for eksempel binder en variabel, kopierer DBMS_SQL pakken PL / SQL-bindingsvariabelen inn i plassen for senere bruk under kjøring. På samme måte, hver gang du utfører en henting, blir dataene først kopiert til plassen som administreres av DBMS_SQL -pakken, og deretter blir de hentede dataene kopiert, en kolonne om gangen, til riktig PL / SQL-variabler, noe som resulterer i betydelig overhead som følge av datakopiering. I motsetning til dette samler innfødte dynamiske SQL setningens klargjøring, binding og utføringstrinn i en enkelt operasjon, noe som minimerer datakopiering og prosedyreanrop og forbedrer ytelsen.

Performance Tips

Når du bruker enten innfødt dynamisk SQL eller DBMS_SQL -pakken, kan du forbedre ytelsen ved å bruke bindingsvariabler, fordi bruk av bindingsvariabler lar Oracle dele en enkelt markør for flere SQL-setninger.

For eksempel bruker følgende innfødte dynamiske SQL-kode ikke bindingsvariabler:

For hver distinkt my_deptno -variabel opprettes en ny markør som kan forårsake ressurskonkurranse og dårlig ytelse. I stedet bind my_deptno som en bindingsvariabel, som i følgende eksempel:

Her blir den samme markøren brukt på nytt for forskjellige verdier av bindingen my_deptno, og forbedrer derved ytelse og skalabilitet.

Støtte for brukerdefinerte typer

Innfødt dynamisk SQL støtter alle typene som støttes av statisk SQL i PL / SQL. Derfor gir innfødt dynamisk SQL støtte for brukerdefinerte typer, for eksempel brukerdefinerte objekter, samlinger og REFs. DBMS_SQL -pakken støtter ikke disse brukerdefinerte typene.

Støtte for henting til poster

Innfødt dynamisk SQL og statisk SQL støtter begge henting i poster, men DBMS_SQL -pakken gjør det ikke. Med innfødt dynamisk SQL kan radene som kommer fra et spørsmål hentes direkte inn i PL / SQL-poster.

I det følgende eksemplet blir radene fra et spørsmål hentet til emp_rec -post:

Fordeler med DBMS_SQL-pakken

DBMS_SQL -pakken gir følgende fordeler i forhold til innfødt dynamisk SQL:

Støtte for klientprogrammer

For tiden støttes DBMS_SQL -pakken i klientprogrammer, men innfødt dynamisk SQL er ikke det. Hver samtale til DBMS_SQL -pakken fra klientsiden, oversettes til en PL / SQL ekstern prosedyrekall (RPC); disse samtalene skjer når du trenger å binde en variabel, definere en variabel eller utføre en setning.

Støtte for DESCRIBE

DESCRIBE_COLUMNS -prosedyren i DBMS_SQL -pakken kan brukes til å beskriv kolonnene for en markør som er åpnet og analysert gjennom DBMS_SQL. Funksjonaliteten ligner på DESCRIBE -kommandoen i SQL * Plus. Innfødt dynamisk SQL har ikke et DESCRIBE -anlegg.

Støtte for Bulk Dynamic SQL

Bulk SQL er muligheten til å behandle flere rader med data i en enkelt DML-setning. Bulk SQL forbedrer ytelsen ved å redusere mengden kontekstbytte mellom SQL og vertsspråket. For tiden støtter DBMS_SQL -pakken dynamisk bulk i bulk.

Selv om det ikke er noen direkte støtte for bulkoperasjoner i native dynamisk SQL, kan du simulere en native dynamisk bulk SQL uttalelse ved å plassere bulk SQL-setningen i en «BEGIN … END» -blokk og utføre blokken dynamisk. Denne løsningen lar deg realisere fordelene med bulk SQL i et eget dynamisk SQL-program. For eksempel kopierer følgende innfødte dynamiske SQL-kode ename -kolonnen i en tabell til en annen:

Flere radoppdateringer og slettinger med en RETURNING-klausul

DBMS_SQL -pakken støtter utsagn med en RETURNING -sats som oppdaterer eller sletter flere rader. Innfødt dynamisk SQL støtter bare en RETURNING -klausul hvis en enkelt rad returneres.

Støtte for SQL-setninger Større enn 32 KB

DBMS_SQL pakken støtter SQL-setninger større enn 32KB; innfødt dynamisk SQL gjør ikke det.

Gjenbruk av SQL-setninger

PARSE -prosedyren i DBMS_SQL pakke analyserer en SQL-setning en gang. Etter den første parsingen kan utsagnet brukes flere ganger med forskjellige sett med bindingsargumenter.

I motsetning til dette forbereder native dynamisk SQL en SQL-setning for utføring hver gang setningen brukes. Uttalelsesutarbeid innebærer vanligvis parsing, optimalisering og plangenerering. Å utarbeide en uttalelse hver gang den brukes medfører en liten ytelsesstraff. Orakles delte markørmekanisme minimerer imidlertid kostnadene, og ytelsesstraffen er vanligvis triviell sammenlignet med ytelsesfordelene ved innfødt dynamisk SQL.

Eksempler på DBMS_SQL pakkekode og innfødt dynamisk SQL-kode

Følgende eksempler illustrerer forskjellene i koden som er nødvendige for å fullføre operasjonene med DBMS_SQL -pakken og innfødt dynamisk SQL. Spesielt presenteres følgende typer eksempler:

• Et spørsmål
• En DML-operasjon
• En DML-returoperasjon

Generelt sett er den innfødte dynamiske SQL-koden mer leselig og kompakt, noe som kan forbedre utviklerens produktivitet.

Spørreeksempel

Følgende eksempel inkluderer en dynamisk spørringsuttalelse med en bindingsvariabel (:jobname) og to valgte kolonner (ename og sal):

stmt_str := "SELECT ename, sal FROM emp WHERE job = :jobname";

Dette eksemplets spørsmål til ansatte med j ob beskrivelse SALESMAN i job kolonnen i emp tabellen. Tabell 8-2 viser eksempelkode som utfører dette spørsmålet ved hjelp av DBMS_SQL -pakken og innfødt dynamisk SQL.

Tabell 8-2 Spørring ved hjelp av DBMS_SQL-pakken og Native Dynamic SQL

DML-eksempel

følgende eksempel inkluderer en dynamisk INSERT uttalelse for en tabell med tre kolonner:

stmt_str := "INSERT INTO dept_new VALUES (:deptno, :dname, :loc)";

Dette eksemplet setter inn en ny rad hvor kolonneverdiene er i PL / SQL-variablene deptnumber, deptname og location. Tabell 8-3 viser eksempelkode som oppnår denne DML-operasjonen ved hjelp av DBMS_SQL -pakken og innfødt dynamisk SQL.

Tabell 8-3 DML-operasjon ved hjelp av DBMS_SQL-pakken og Innfødt dynamisk SQL

DML Retureksempel

Følgende eksempel inkluderer et dynamisk UPDATE uttalelse som oppdaterer plasseringen til en avdeling når avdelingsnummeret (deptnumber) og et nytt sted (location) blir gitt, og deretter returnerer navnet på avdelingen:

stmt_str := "UPDATE dept_new SET loc = :newloc WHERE deptno = :deptno RETURNING dname INTO :dname";

Dette eksemplet setter inn en ny rad som kolonneverdiene er i PL / SQL-variablene deptnumber, deptname, og location. Tabell 8-4 viser eksempelkode som utfører denne DML-returoperasjonen ved hjelp av DBMS_SQL -pakken og innfødt dynamisk SQL.

Tabell 8-4 DML-returoperasjon ved hjelp av DBMS_SQL Package and Native Dynamic SQL

Application Development Languages Other Than PL / SQL

Så langt har diskusjonen i dette kapittelet vært om PL / SQL-støtte for dynamisk SQL.Du kan imidlertid bruke andre språk for applikasjonsutvikling til å implementere programmer som bruker dynamisk SQL. Disse språkene for applikasjonsutvikling inkluderer C / C ++, COBOL og Java.

Hvis du bruker C / C ++, kan du utvikle applikasjoner som bruker dynamisk SQL med Oracle Call Interface (OCI), eller du kan bruke Pro * C / C ++ precompiler for å legge til dynamiske SQL-utvidelser til C kode. På samme måte, hvis du bruker COBOL, kan du bruke Pro * COBOL-forkompilatoren til å legge til dynamiske SQL-utvidelser til COBOL-koden. Hvis du bruker Java, kan du utvikle applikasjoner som bruker dynamisk SQL med JDBC.

Tidligere var den eneste måten å bruke dynamisk SQL i PL / SQL-applikasjoner ved å bruke DBMS_SQL pakke. Det er en rekke begrensninger for å bruke denne pakken, inkludert ytelsesproblemer. Følgelig kan applikasjonsutviklere ha brukt et av alternativene til PL / SQL diskutert ovenfor for å implementere dynamisk SQL. Med introduksjonen av innfødt dynamisk SQL i PL / SQL er imidlertid mange av ulempene med å bruke PL / SQL for dynamisk SQL nå eliminert.

Hvis du har et program som bruker OCI, Pro * C / C ++, eller Pro * COBOL for dynamisk SQL-kjøring, kan nettverksrundturene som kreves for å utføre dynamiske SQL-operasjoner skade ytelsen. Fordi disse applikasjonene vanligvis ligger på klienter, kreves det flere nettverkssamtaler for å fullføre dynamiske SQL-operasjoner. Hvis du har denne typen applikasjoner, bør du vurdere å flytte den dynamiske SQL-funksjonaliteten til lagrede prosedyrer og lagrede funksjoner i PL / SQL som bruker naturlig dynamisk SQL. Dette kan forbedre ytelsen til applikasjonen din fordi de lagrede prosedyrene kan ligge på serveren, og dermed eliminere nettverksomkostningene. Du kan da ringe PL / SQL-lagrede prosedyrer og lagrede funksjoner fra applikasjonen.