Problemem jest rozwiązywanie nazw.
Gdy masz parametr hostname
i hostname
w tabeli, do której się odwołujesz, reguły rozpoznawania zakresu powodują zamieszanie większości ludzi. Dlatego wiele osób zaleca stosowanie konwencji nazewnictwa parametrów i zmiennych lokalnych, która odróżnia je od nazw tabel. W moim kodzie na przykład używam p_
aby poprzedzić nazwy parametrów i l_
aby poprzedzać zmienne lokalne.
W kodzie, jeśli masz
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = Hostname;
hostname
jest rozpoznawany jako kolumna w tabeli, a nie parametr. Powoduje to, że zapytanie zwraca każdy wiersz w tabeli, w której hostname
nie ma wartości null, co powoduje błąd. Możesz jawnie poprzedzić nazwę parametru nazwą funkcji, aby wymusić hostname
rozwiązać do parametru
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = GET_SYSTEMID.Hostname;
To działa. Ale dodanie prefiksu nazwy funkcji zazwyczaj jest denerwujące. Jeśli przyjmiesz konwencję przedrostków nazw parametrów i nazw zmiennych lokalnych, otrzymasz coś w stylu
FUNCTION GET_SYSTEMID(p_hostname varchar2)
RETURN NUMBER
IS
l_sysID number;
BEGIN
SELECT mySystems.SYSTEMID
INTO l_sysID
FROM mySystems
where mySystems.HOSTNAME = p_hostname;
return l_sysID;
END GET_SYSTEMID;
To również działa i wydaje się (moim zdaniem) bardziej przejrzyste niż dodawanie wyraźnych przedrostków nazw funkcji w całym miejscu.