Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



18.04.2018

Dla biznesu

Monitory AOC 6x
13.04.2018

Ochrona sieci przemysłowych

Stormshield SNi40
09.04.2018

Disaster recovery

Veeam Availability Orchestrator
05.04.2018

Pamięci masowe i SDS

IBM Spectrum Storage
27.03.2018

Wydajna podstawa

Asus RS700-E9, Asus WS C621E SAGE
22.03.2018

Seria dla profesjonalistów

Toshiba E-Generation
21.03.2018

Odzyskiwanie plików - nowa...

Zachowanie bezpieczeństwa plików jest dla wielu przedsiębiorców priorytetem. Z myślą o...
19.03.2018

Superszybkie SSD

Samsung SZ985 Z-SSD
15.03.2018

EPYC w serwerach

Dell EMC PowerEdge

JĘZYK PL/SQL – fakty i mity

Data publikacji: 03-01-2017 Autor: Kamil Stawiarski

Każdy, kto zaczyna przygodę z programowaniem, na początku uczy się dobrych praktyk. Co warto robić, czego nie warto, które techniki są wydajne, na które nie warto tracić czasu. Wielu szuka też jednoznacznej odpowiedzi na pytanie, co jest szybsze. Delikatnie rzecz ujmując, osoby te nie są wtedy sympatykami odpowiedzi – to zależy…

Umysł, żyjący w świecie deterministycznych zależności, obrazowanych piękną logiką instrukcji warunkowych i pętli, skupia się na tworzeniu algorytmów, mających precyzyjnie wykonać zadaną pracę w lokalnym środowisku deweloperskim. Z biegiem czasu działanie to staje się nawykiem i źródłem standardowej odpowiedzi programisty nr 7: „u mnie działa”.


Odwieczny konflikt programisty z administratorem jest w rzeczywistości często konfliktem młodego umysłu, który wierzy w logikę narzędzi, z którymi pracuje, z umysłem starego wygi, który niejedno widział i wie, że dokumentacja dokumentacją, wiedza wiedzą, a tak naprawdę w większości przypadków wygrywa intuicja i doświadczenie. To walka ze specem, który na każde pytanie udzieli cynicznej odpowiedzi – to zależy.

W poszukiwaniu odpowiedzi na dręczące nas pytania sięgamy więc do rzeczy niemal świętej – dokumentacji technicznej produktu. Niestety, z biegiem lat i wzrostem doświadczenia znajdujemy tam coraz więcej nieścisłości czy wręcz przekłamań. Czasem też niektóre części dokumentacji nie do końca zgadzają się z praktyką i materiałami szkoleniowymi. Jak więc weryfikować poprawność dokumentacji, jeśli nie mamy dostępu do kodów źródłowych? Prześledźmy kilka przykładów.

> PRAGMA UDF

Pierwsze, czego dowiadujemy się o języku PL/SQL, to fakt, jak wspaniale jest on zintegrowany z silnikiem bazodanowym oraz że możemy bez problemu używać w SQL własnych funkcji PL/SQL, jeśli standardowe mechanizmy nie do końca nas zadowalają. Niestety, na podstawowych szkoleniach rzadko wspomina się o karze związanej z takim zachowaniem – a mianowicie o tzw. zmianie kontekstów między silnikiem SQL a PL/SQL.

Najprościej można zobaczyć różnicę w opóźnieniach spowodowanych przez zmiany kontekstów. Rozważmy następujący przypadek – stwórzmy prostą funkcję PL/SQL, której jedynym zadaniem jest mnożenie razy 2:

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2013 Presscom / Miesięcznik "IT Professional"