Nie jestem fanem procedur składowanych
Procedury składowane są BARDZIEJ konserwowalne, ponieważ:* Nie musisz ponownie kompilować aplikacji C# za każdym razem, gdy chcesz zmienić niektóre SQL
Skończy się na ponownej kompilacji, gdy zmienią się typy danych, lub zechcesz zwrócić dodatkową kolumnę, lub cokolwiek innego. Liczba przypadków, w których można „przezroczyście” zmienić kod SQL spod aplikacji, jest w sumie dość niewielka
- W efekcie ponownie używasz kodu SQL.
Języki programowania, w tym C#, mają tę niesamowitą rzecz, zwaną funkcją. Oznacza to, że możesz wywołać ten sam blok kodu z wielu miejsc! Zdumiewający! Następnie możesz umieścić kod SQL wielokrotnego użytku w jednym z nich lub jeśli chcesz uzyskać naprawdę zaawansowaną technologię, możesz użyć biblioteki, która zrobi to za Ciebie. Uważam, że nazywają się one obiektowymi mapowaniami relacyjnymi i są dość powszechne w dzisiejszych czasach.
Powtarzanie kodu to najgorsza rzecz, jaką możesz zrobić, gdy próbujesz zbudować aplikację, którą można konserwować!
Zgadzam się, dlatego przechowywaneprocs są złe. O wiele łatwiej jest refaktoryzować i rozkładać (rozbijać na mniejsze części) kod na funkcje niż SQL na… bloki SQL?
Masz 4 serwery internetowe i kilka aplikacji dla systemu Windows, które używają tego samego kodu SQL Teraz zdałeś sobie sprawę, że jest mały problem z kodem SQl, więc wolisz...... zmień proc w 1 miejscu, czy wepchnij kod do wszystkich serwerach internetowych, ponownie zainstaluj wszystkie aplikacje komputerowe (jedno kliknięcie może pomóc) we wszystkich oknach
Dlaczego Twoje aplikacje Windows łączą się bezpośrednio z centralną bazą danych? To wydaje się być OGROMNĄ luką w zabezpieczeniach i wąskim gardłem, ponieważ wyklucza buforowanie po stronie serwera. Czy nie powinny łączyć się za pośrednictwem usługi internetowej lub podobnej do Twoich serwerów internetowych?
Więc wypchnij 1 nowy sproc lub 4 nowe serwery internetowe?
W tym przypadku jest łatwiej wypchnąć jeden nowy sproc, ale z mojego doświadczenia wynika, że 95% „wypchniętych zmian” wpływa na kod, a nie na bazę danych. Jeśli w tym miesiącu wrzucisz 20 elementów na serwery internetowe i 1 do bazy danych, niewiele stracisz, jeśli zamiast tego prześlesz 21 elementów na serwery i zero do bazy danych.
Łatwiejszy przegląd kodu.
Czy możesz wyjaśnić, jak? Nie rozumiem tego. Zwłaszcza biorąc pod uwagę, że sprocs prawdopodobnie nie podlegają kontroli źródła i dlatego nie można uzyskać do nich dostępu za pośrednictwem przeglądarek internetowych SCM i tak dalej.
Więcej wad:
Storedprocs znajdują się w bazie danych, która jawi się światu zewnętrznemu jako czarna skrzynka. Proste rzeczy, takie jak chęć poddania ich kontroli nad źródłami, stają się koszmarem.
Jest też kwestia samego wysiłku. Rozbicie wszystkiego na milion poziomów może mieć sens, jeśli próbujesz uzasadnić swojemu dyrektorowi generalnemu, dlaczego zbudowanie niektórych forów kosztowało go po prostu 7 milionów dolarów, ale w przeciwnym razie tworzenie procedury przechowywanej dla każdego drobiazgu to tylko dodatkowa robota za nic korzyści.
