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



11.12.2017

Dla biznesu

BenQ MH760
07.12.2017

Pamięć masowa SDS

SUSE Enterprise Storage 5
05.12.2017

Bezpieczna platforma

Red Hat OpenStack Platform 12
30.11.2017

ITewolucja w bezpieczeństwie....

9 listopada w katowickim hotelu Novotel odbyła się kolejna odsłona konferencji z cyklu...
28.11.2017

Smukle i elegancko

HP Spectre 13 i x360
23.11.2017

Z IEEE 802.3bz

Przełączniki Netgear
21.11.2017

4K z USB-C

EIZO FlexScan EV2785
16.11.2017

Wielofunkcyjne MFP

Canon imageRUNNER ADVANCE C256i, C356i oraz C356P
14.11.2017

Fabryka Przyszłości w drodze...

W dniach 25 i 26 października we Wrocławiu odbyła się czwarta edycja konferencji...

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"