Dlaczego prefiks schematu (dbo) jest obowiązkowy, gdy wywołujemy funkcję?

Gdy użytkownik jest odwzorowany z domyślnym schematem (dbo) i możemy wybrać wszystkie tabele w [dbo] bez prefiksu schematu.

Możemy wykonywać procedury składowane bez prefiksu, jeśli jest to schemat domyślny.

W związku z tym, dlaczego musimy poprzedzić funkcję schematem?

Dzięki!

sql-server functions

— Rajesh Ranjan
źródło

Odpowiedzi:

Dlaczego więc możemy wywoływać funkcję bez prefiksu (schematu), utworzoną pod dbo?

Z książki online Dokument na UDF

Funkcje o wartościach skalarnych mogą być wywoływane tam, gdzie używane są wyrażenia skalarne. Obejmuje to kolumny obliczeniowe i definicje ograniczeń CHECK. Funkcje o wartościach skalarnych można również wykonywać za pomocą instrukcji EXECUTE. Funkcje o wartościach skalarnych muszą być wywoływane przy użyciu co najmniej dwuczęściowej nazwy funkcji .

Jest to w zasadzie ograniczenie ustalone przez zespół programistów SQL Server i uważam, że jest całkiem poprawne. Nawet jeśli jest to w jakiś sposób dozwolone (tylko ze względu na rozmowę), nadal używałbym prefiksu schematu.

Zawsze popieram używanie nazwy schematu, nawet jeśli zadziałałoby bez dodawania go. Jest to najlepsza praktyka i wszyscy „dobrzy” programiści używają jej bez względu na to, jak bardzo jest zbędna.

Innym powodem, dla którego widzę, jest to, że aparat bazy danych potrzebuje czegoś, aby odróżnić funkcje systemowe od funkcji getdate ()zdefiniowanych przez użytkownika. Jeśli możesz wywoływać funkcję bez nazwy schematu, w jaki sposób silnik bazy danych rozróżniałby funkcję utworzoną przez użytkownika o nazwie Getdate lub funkcję systemową GETDATE ().

— Shanky
źródło

Więc dlaczego jest inaczej w SP. Jak powiedziałeś, być może unikniesz kolizji nazw. Właśnie utworzyłem SP w „bazie danych procedury sp_help as select getdate ()” w mojej bazie danych użytkowników i kiedy wykonuję ze schematem lub bez (SQL) SQL Server odnosi się do SP systemu. Dlaczego nie wykonuje mojego SP, które utworzyłem.

— Rajesh Ranjan

@rajeshRajan Ponieważ masz nazwę sp_procname (poprzedzasz procedurę SP), SQL Server musi najpierw zajrzeć do głównej bazy danych dla skompilowanego planu, a ponieważ ten proces istnieje w głównej bazie danych, zostanie wykonany nie twój, jeśli nie można go znaleźć w mistrzu to wykonałby twój. Nigdy nie należy tworzyć proc z prefiksem sp_, ponieważ ma on problemy z wydajnością.

— Shanky

Myślę, że Shanky odpowiedział bezpośrednio na pytanie „dlaczego”, kiedy wspomniał, że zostało ustawione przez zespół programistów SQL Server. Można zapytać, dlaczego to zrobili i dlaczego zachowanie funkcji jest niespójne z procedurami, ale odpowiedź prawdopodobnie nie ma większego znaczenia.

— Michael J Swart,

BTW, nie można zmierzyć wpływu na wydajność procedur rozpoczynających się od „sp_”. To nie był problem od lat. Prefiks sp nadal może nie być dobrym pomysłem, ale wydajność nie jest powodem.

— Michael J Swart,

Druga odpowiedź wyjaśnia, że jest to ograniczenie, ale nie powód.

Wymaganie nie zawsze jest prawdziwe. Skalarne UDF mogą być EXECustawiane i nadal używać domyślnej rozdzielczości ( przykład )

Wyobrażam sobie, że ma to na celu uniknięcie kolizji nazw.

Gdyby można było odwoływać się do funkcji bez schematu, ktoś, kto utworzył własną funkcję, która została wywołana crypt_gen_randomw 2000 lub 2005 r., Napotkałby problemy z aktualizacją do późniejszej wersji, ponieważ stała się ona nazwą wbudowanej funkcji w 2008 r.

execUżycie nie jest dwuznaczne, ponieważ nie można tak tak nazwać wbudowanych funkcji.

— Martin Smith
źródło

— Rajesh Ranjan

@Rajesh. Obiekty zaczynające się od sp_ mają specjalną obudowę, aby zawsze sprawdzały bazę danych master / zasobów. Udokumentowano, że należy unikać tego prefiksu. Nie ma takiej konwencji dla wbudowanych funkcji.

— Martin Smith,