To pytanie wyszło z poprzedniego postu/roztworu kopalni:SQL Server dlaczego muszę odświeżyć opinii po stole zmienia
adding a field somehow effects a views results
IMO to zasługuje na swój własny post. Korzystanie z SQL Server 2008 R2.
Dlaczego muszę odświeżać widoki po dodaniu kolumny do tabeli, do której odwołuje się widok? Chociaż nie jest to bezpośrednio konieczne, aby odpowiedzieć na to pytanie/pytanie, scenariusz/zachowanie dla mojego konkretnego scenariusza jest wyjaśnione postem połączonym powyżej.
Nie jestem wielkim fanem poglądów. Bardzo rzadko tworzę je szczerze, pracuję z kodem, którego początkowo nie pisałem. Załóżmy, że masz ponad 70 wyświetleń, których początkowo nie pisałeś, dlatego nie masz pojęcia, które z nich wymagają odświeżania za każdym razem, gdy dodajesz kolumnę bazy danych. Powinienem być w stanie dodać to, co kiedykolwiek kolumna, która kiedykolwiek stawiła w dowolnym czasie bez żadnego wpływu szczerze. Jednostka biznesowa może złożyć wniosek o zmianę, która może wymagać dodania dowolnej liczby pól w dowolnym momencie.
Z pewnością jest inne podejście do tego?
Widok to nie tylko zapytanie, dynamicznie reorganizuje się za każdym razem, gdy się go nazywa. Jest tworzony za pomocą schematu, kolumn itp. Istnieje wiele przypadków (takich jak ten w odnośniku, do którego się odwołujesz), w których dodanie dodatkowych kolumn do zestawu wyników może nieoczekiwanie zachowywać się. Podczas gdy ten rodzaj idzie w przeciwną stronę, niż pożądana wersja, widoki mogą być również zadeklarowane za pomocą opcji SCHEMABINDING, która zabrania zmian schematu dla ukrytych obiektów. Jednak, jak zauważono w kilku miejscach, jeśli chcesz, aby schemat wybierał nową kolumnę, musisz użyć sp_refreshview – Xedni
Dziękuję za poświęcony czas. Chociaż mi się to nie podoba, ma to sens. Zdaję sobie sprawę, że widoki mają przewagę pod względem wykorzystania zasobów. To powiedziawszy, jestem całkiem pewien, że teraz lubię je jeszcze mniej. Doświadczenie użytkownika końcowego, które widziałem dzisiaj w wyniku dodania kolumny do tabeli, było uciążliwe błędne. – Mat41
Widoki nie zawsze są złe. Doskonale nadają się do upraszczania złożonych zapytań, standaryzacji reguł biznesowych w zapytaniach, które mogą być udostępniane w aplikacjach lub przechowywanych procesach, umożliwiają pisanie pól do zmiany nazw lub upraszczają zapytania do baz danych podmiotów trzecich (zwłaszcza te starsze o archaicznych nazwach, takie jak AE1401 jako tabela imię i nazwisko z polami FN144 itp.), a gdy aplikacje współużytkują tabelę, jeśli podstawowe pole tabeli musi się zmienić, nazwa widoku może pozostać taka sama, nie zmuszając do zmiany wielu aplikacji. –