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



28.06.2017

Core i9 – nowa seria...

Intel Core i9 Skylake-X i Kaby Lake-X
23.06.2017

Z autotrackingiem

Aver PTC500
20.06.2017

Do budynków i na zewnątrz

Ubiquiti UAP-AC-HD
16.06.2017

Monitor 16:3

BenQ BH281
13.06.2017

Monitorowanie

Axence nVision 9.2
12.06.2017

Exatel Security Day –...

Już 20 czerwca w Warszawie rozpocznie się druga edycja Exatel Security Day. W tym roku...
09.06.2017

Automatyzacja...

Red Hat Ansible
06.06.2017

Optymalizacja wydatków

Snow for Office 365
01.06.2017

Zarządzanie końcówkami

baramundi Management Suite 2017

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"