Czy dobrą praktyką jest używanie w procedurach zdefiniowanych wcześniej widoków?
Generalnie tak, ale trzeba uważać.
Poza tym, jak przetwarzane są zapytania do widoków zależy od bazy danych.
W MSSQL jest całkiem dobrze.
Powody dla których się nad tym zastanawiam to:
- nie powielanie raz już napisanego kodu
- czytelniejsze jest dla mnie wywołanie procedury z parametrami niż SELECT'a z warunkami
Procedura zwracająca dane to generalnie głupota w MSSQL.
Jest całkowicie zamknięta, nie da się wprost łączyć zwróconych danych z innymi (mam na myśli jakiekolwiek złączenia).
Zdecydowanie lepszym pomysłem jest po prostu User Definied Functions, a takie które zwracają tzw. derived tables działają tak jakby sparametryzowane widoki - czyli szybko.
Przykład:
Mam ogólny widok wyświetlający dane z wielu tabel z pewnego obszaru rzeczywistości aplikacji. Np. wszystkie zamówienia z tego miesiąca wraz z danymi firmy.
Stop, stop.
Na cholerę w widoku warunek na ten miesiąc?
I co potem - następny widok na poprzedni/następny miesiąc/rok/kwartał?
Dlaczego widok bez warunku na datę i ten warunek nakładasz wybierając dane z widoku - po prostu.
Tak, działa to w MSSQL bardzo dobrze.
Generalna rada - pisz ogólne widoki.
A zresztą - pisz ogólny kod :)
Procedura ma za zadanie wyświetlenie konkretnych informacji na podstawie przekazanych parametrów. Np. wyświetlenie zamówienia konkretnej firmy z danego dnia tego miesiąca. Czy w takim razie użycie widoku w tej procedurze będzie zasadne?
Zdecydowanie użycie widoku jest zasadne a procedury bezzasadne.
Zamiast wykonać:
exec pDawajZamowieniaDlaFirmyZdanegoDnia(@IdFirmy int, @Data date)
robisz:
select * from WidokZamowien where IdFirmy = @IdFirmy and Data = @Data
Jak to wygląda w praktyce? Czy jest to dobre podejście? Czy należy unikać tego typu rozwiązań?
Na początek unikałbym takich anemicznych procedur.
Nigdy nie rozumiałem co autor takiej procedury miał na myśli - po co to?