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


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

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:

Artykuł pochodzi z miesięcznika: IT Professional

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

.

Transmisje online zapewnia: StreamOnline

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