Czy procedury składowane są ogólnie bardziej wydajne niż instrukcje wbudowane na nowoczesnych systemach RDBMS? [duplikat]
Konwencjonalna mądrość stwierdza, że procedury przechowywane są zawsze szybsze. Więc, ponieważ są zawsze szybsze, używaj ich cały czas .
Jestem prawie pewien, że jest to ugruntowane w jakimś kontekście historycznym, gdzie kiedyś tak było. Teraz nie jestem zwolennikiem, że przechowywane proc nie są potrzebne, ale chcę wiedzieć, w jakich przypadkach procedury przechowywane są niezbędne w nowoczesnych bazach danych, takich jak MySQL, SQL Server, Oracle, czy Insert_your_DB_here>. Czy to przesada mieć dostęp do wszystkich procedur przechowywanych?
20 answers
Zauważ , że jest to ogólne spojrzenie na procedury składowane, które nie są regulowane do konkretnego DBMS. Niektóre DBMS (a nawet, różne wersje tych samych DBMS!) może działać wbrew temu, więc będziesz chciał sprawdź dwukrotnie z docelowym DBMS przed założeniem, że to wszystko nadal trwa.
Od prawie dekady jestem Sybase ASE, MySQL i SQL Server DBA (wraz z rozwojem aplikacji w C, PHP, PL / SQL, C#.NET i Ruby). Więc nie mam szczególny topór do szlifowania w tej (czasami) świętej wojnie.
Historyczne korzyści z wydajności przechowywanych proc były z reguły następujące (w żadnej szczególnej kolejności):
- Pre-parsed SQL
- Pre-generated query execution plan
- zmniejszone opóźnienie sieci
- potencjalne korzyści z pamięci podręcznej
Pre-parsed SQL -- podobne korzyści do skompilowanego i zinterpretowanego kodu, z wyjątkiem bardzo mikro poziomu.
Still an przewaga? Nie bardzo zauważalne w ogóle na nowoczesnym procesorze, ale jeśli wysyłasz pojedyncze polecenie SQL, które jest bardzo duże jedenasty-miliard razy na sekundę, narzut parsowania może się sumować.
Wstępnie wygenerowany plan wykonywania zapytań . Jeśli masz wiele łączy permutacje mogą rosnąć dość nie do opanowania (nowoczesne optymalizatory mają limity i odcięcia ze względu na wydajność). Nie jest nieznane, aby bardzo skomplikowany SQL miał odrębne, mierzalne (widziałem skomplikowane zapytanie wziąć 10 + sekund tylko, aby wygenerować plan, zanim poprawiliśmy DBMS) opóźnienia ze względu na optymalizator próbuje dowiedzieć się" prawie najlepszy " plan realizacji. Procedury przechowywane zazwyczaj przechowują to w pamięci, dzięki czemu można uniknąć tego narzutu.
nadal masz przewagę? Większość DBMS (najnowsze wersje) buforuje plany zapytań dla poszczególnych poleceń SQL, znacznie zmniejszając różnicę wydajności między przechowywanymi procami A ad hoc SQL. Istnieją pewne zastrzeżenia i przypadki, w których tak nie jest, więc musisz przetestować na docelowym DBMS.
Ponadto coraz więcej DBMS pozwala na dostarczanie planów ścieżki optymalizatora (abstrakcyjnych planów zapytań), aby znacznie skrócić czas optymalizacji (zarówno dla procedury ad hoc, jak i przechowywanej SQL!!).
WARNING buforowane plany zapytań nie są panaceum wydajności. Czasami generowany Plan zapytań jest nieoptymalny. Na przykład, jeśli wyślesz
SELECT * FROM table WHERE id BETWEEN 1 AND 99999999, DBMS może wybrać Pełne skanowanie tabeli zamiast indeksu Skanuj, bo chwytasz każdy wiersz w tabeli (tak mówi statystyki). Jeśli jest to pamięć podręczna wersja, wtedy można uzyskać słabe wydajność, gdy później wyśleszSELECT * FROM table WHERE id BETWEEN 1 AND 2. Rozumowanie za tym jest poza zakresem tego wpisu, ale więcej informacji na stronie: http://www.microsoft.com/technet/prodtechnol/sql/2005/frcqupln.mspx oraz http://msdn.microsoft.com/en-us/library/ms181055.aspx oraz http://www.simple-talk.com/sql/performance/execution-plan-basics/"podsumowując, stwierdzili, że dostarczanie czegokolwiek innego niż wspólne wartości podczas kompilacji lub rekompilacji dokonano w wyniku kompilowanie i buforowanie optymalizatora Plan zapytań dla tego konkretnego wartość. Jednak, kiedy ten plan zapytań był ponownie wykorzystane do kolejnych egzekucji to samo zapytanie dla wspólnych wartości ("M", " R " lub "T"), w wyniku czego poniżej optymalnej wydajności. To poniżej optymalnego problemu wydajności istniał aż do zapytania przekompilowane. W tym momencie, na podstawie podana wartość parametru @ P1, zapytanie może, ale nie może mieć problem z wydajnością."
Zmniejszone opóźnienie sieci A) jeśli używasz tego samego SQL w kółko - i SQL dodaje się do wielu KB kodu-zastąpienie tego prostym "exec foobar"może naprawdę dodać. B) przechowywane proc mogą być używane do przenoszenia kodu proceduralnego do DBMS. To oszczędza tasowanie duże ilości danych do klienta tylko po to, aby wysłać strumyk informacji z powrotem(lub wcale!). Analogicznie do łączenia w DBMS vs. w kodzie (każdy ulubiony WTF!)
nadal masz przewagę? A) nowoczesne 1Gb (i 10GB i więcej!) Ethernet naprawdę czyni to znikomym. B) zależy jak nasycona jest Twoja sieć-po co wrzucać kilka megabajtów danych tam iz powrotem bez powodu?
Potencjalne korzyści z pamięci podręcznej Wykonywanie przekształceń po stronie serwera dane mogą być potencjalnie szybsze, jeśli masz wystarczającą pamięć na DBMS, a potrzebne dane znajdują się w pamięci serwera.
nadal masz przewagę? Chyba że aplikacja ma dostęp do pamięci współdzielonej danych DBMS, krawędź zawsze będzie przechowywana procs.
Oczywiście żadne omówienie optymalizacji procedur składowanych nie byłoby kompletne bez omówienia parametryzowanego I ad hoc SQL.
Parametryzowany / przygotowany SQL
Rodzaj krzyżówki w języku hosta, który używa "parametrów" dla wartości zapytań, np.:
SELECT .. FROM yourtable WHERE foo = ? AND bar = ?
Zapewniają one bardziej uogólnioną wersję zapytania, którą współcześni optymalizatorzy mogą wykorzystać do buforowania (i ponownego wykorzystania) planu wykonywania zapytań, co skutkuje znaczną korzyścią z wydajności procedur składowanych.
Ad Hoc SQL Po prostu otwórz okno konsoli DBMS i wpisz polecenie SQL. W przeszłości byli to "najgorsi" wykonawcy (na średnia), ponieważ DBMS nie miał możliwości wstępnej optymalizacji zapytań, jak w parametryzowanej / zapisanej metodzie proc.
nadal wada? Niekoniecznie. Większość DBMS ma możliwość "abstrakcyjnego" ad hoc SQL do sparametryzowanych wersji - w ten sposób mniej lub bardziej neguje różnicę między nimi. Niektóre robią to domyślnie lub muszą być włączone z ustawieniem polecenia (SQL server: http://msdn.microsoft.com/en-us/library/ms175037.aspx , Oracle: http://www.praetoriate.com/oracle_tips_cursor_sharing.htm).
Wyciągnęłaś wnioski? Prawo Moore ' a nadal maszeruje, a optymalizatory DBMS, z każdym wydaniem, stają się bardziej wyrafinowane. Oczywiście, możesz umieścić każde głupie, nastoletnie polecenie SQL wewnątrz przechowywanego proc, ale po prostu wiedz, że programiści pracujący nad optymalizatorami są bardzo inteligentni i nieustannie szukają sposobów na poprawę wydajności. Ostatecznie (jeśli jeszcze go nie ma) wydajność ad hoc SQL stanie się nie do odróżnienia (średnio!) z wydajności procedury składowanej, więc wszelkiego rodzaju massive procedura składowana używa * * wyłącznie dla "powodów wydajności" * * brzmi jak przedwczesna Optymalizacja dla mnie.
W każdym razie, myślę, że jeśli unikniesz przypadków edge i masz dość waniliowy SQL, nie zauważysz różnicy między procedurami ad hoc i przechowywanymi.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-13 18:52:51
Powody stosowania procedur składowanych:
- Reduce network traffic -- musisz wysłać polecenie SQL przez sieć. Dzięki sprocks możesz wykonywać SQL partiami, co jest również bardziej wydajne.
- buforowanie planu zapytań -- przy pierwszym uruchomieniu sproc, SQL Server tworzy plan wykonania, który jest buforowany do ponownego użycia. Jest to szczególnie wydajne dla małych zapytań często uruchamianych.
- Możliwość użycia parametrów wyjściowych -- jeśli wyślesz inline SQL, który zwróci jeden wiersz, możesz odzyskać tylko zestaw rekordów. Dzięki zębatkom można je odzyskać jako parametry wyjściowe, co jest znacznie szybsze.
- Permissions -- Kiedy wysyłasz inline SQL, musisz przyznać użytkownikowi uprawnienia na tabelach, co daje znacznie więcej dostępu niż tylko pozwolenie na wykonanie sproc
- separacja logiki -- Usuń kod generujący SQL i posegreguj go w baza danych.
- Możliwość edycji bez rekompilacji -- może to być kontrowersyjne. Możesz edytować SQL w sproc bez konieczności rekompilacji aplikacji.
- Znajdź, gdzie używana jest Tabela -- w sprocks, jeśli chcesz znaleźć wszystkie polecenia SQL odnoszące się do konkretnej tabeli, możesz wyeksportować kod sproc i przeszukać go. Jest to o wiele łatwiejsze niż próba znalezienia go w kodzie.
- Optymalizacja -- łatwiej jest DBA zoptymalizować SQL i dostroić baza danych, kiedy używane są koła zębate. Łatwiej jest znaleźć brakujące indeksy i takie tam.
- SQL injection attacks -- poprawnie napisany inline SQL może bronić się przed atakami, ale sprocks są lepsze do tej ochrony.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-08-30 08:51:18
W wielu przypadkach procedury składowane są wolniejsze, ponieważ są bardziej genaralizowane. Chociaż procedury składowane mogą być wysoce dostrojone, z mojego doświadczenia wynika, że jest wystarczająco dużo rozwoju i tarcia instytucjonalnego, że pozostają na swoim miejscu, gdy działają, więc procedury składowane często zwracają wiele kolumn "na wszelki wypadek" - ponieważ nie chcesz wdrażać nowej procedury składowanej za każdym razem, gdy zmieniasz aplikację. An lub / M, z drugiej strony, żąda tylko kolumn, które aplikacja jest korzystanie, co ogranicza ruch sieciowy, niepotrzebne połączenia itp.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 20:38:25
To debata, która trwa i trwa (na przykład tutaj ).
Pisanie błędnych procedur przechowywanych jest tak samo proste, jak pisanie błędnej logiki dostępu do danych w aplikacji.
Moje preferencje dotyczą przechowywanych proc, ale dzieje się tak dlatego, że zazwyczaj pracuję z bardzo dużymi i złożonymi aplikacjami w środowisku korporacyjnym, w którym istnieją dedykowane bazy danych, które są odpowiedzialne za utrzymanie słodkiego działania serwerów bazodanowych.
W innych sytuacjach jestem wystarczająco zadowolony z dostępu do danych technologie takie jak LINQ do dbania o optymalizację.
Czysta wydajność nie jest jednak jedyną kwestią. Aspekty takie jak Bezpieczeństwo i zarządzanie konfiguracją są zazwyczaj co najmniej równie ważne.
Edit: podczas gdy artykuł Fransa Boumy jest rzeczywiście gadatliwy, o milę pomija punkt dotyczący bezpieczeństwa. Fakt, że ma 5 lat, również nie pomaga w jego znaczeniu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:18:10
Nie ma zauważalnej różnicy prędkości dla procedur przechowywanych w porównaniu z parametryzowanymi lub przygotowanymi zapytaniami w większości nowoczesnych baz danych, ponieważ baza danych będzie również buforować plany wykonania tych zapytań.
Zauważ, że parametryzowane zapytanie nie jest takie samo jak ad hoc sql.
Główny powód, dla którego imo nadal faworyzuje procedury przechowywane, ma więcej wspólnego z bezpieczeństwem. Jeśli używasz wyłącznie procedur składowanych , możesz wyłączyć wstawianie, zaznaczanie, aktualizowanie, usuwanie, zmienianie, upuszczanie i Utwórz uprawnienia etc dla użytkownika Twojej aplikacji, pozostawiając ją tylko z EXECUTE.
Zapewnia to dodatkową ochronę przed 2nd order SQL injection. Parametryzowane zapytania chronią tylko przed wstrzyknięciem pierwszego rzędu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 21:07:40
Jedynym tematem, o którym nikt jeszcze nie wspomniał jako o korzyściach związanych z procedurami składowanymi, jest bezpieczeństwo. Jeśli tworzysz aplikację wyłącznie z dostępem do danych za pośrednictwem procedur składowanych, możesz zablokować bazę danych, tak aby dostęp do niej był możliwy tylko za pośrednictwem tych procedur składowanych. W związku z tym, nawet jeśli ktoś otrzyma identyfikator bazy danych i hasło, będzie ograniczony w tym, co może zobaczyć lub zrobić przeciwko tej bazie danych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-13 14:59:28
Oczywiście, rzeczywiste wyniki powinny być mierzone w indywidualnych przypadkach, a nie zakładane. Ale nawet w przypadkach, gdy wydajność jest utrudniona przez procedurę składowaną, istnieją dobre powody, aby z nich korzystać:
Programiści aplikacji nie zawsze są najlepszymi koderami SQL. Procedury przechowywane ukrywają SQL z aplikacji.
Procedury składowane automatycznie używają zmiennych bind. Twórcy aplikacji często unikają zmiennych bind, ponieważ wydają się niepotrzebne kodować i wykazywać niewielkie korzyści w małych systemach testowych. Później niepowodzenie użycia zmiennych bind może ograniczyć wydajność RDBMS.
Procedury przechowywane tworzą warstwę indrection, która może być przydatna później. Istnieje możliwość zmiany szczegółów implementacji (w tym struktury tabeli) po stronie bazy danych bez dotykania kodu aplikacji.
Ćwiczenie tworzenia procedur składowanych może być przydatne do dokumentowania wszystkich interakcji z bazami danych dla systemu. Oraz łatwiej jest zaktualizować dokumentację, gdy coś się zmieni.
To powiedziawszy, Zwykle trzymam surowy SQL w moich aplikacjach, aby móc go kontrolować. To zależy od Twojego zespołu programistów i filozofii.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 20:51:06
W 2007 roku byłem na projekcie, w którym korzystaliśmy z MS SQL Server poprzez ORM. Mieliśmy 2 duże, rosnące tabele, które zajmowały do 7-8 sekund czasu ładowania na serwerze SQL. Po stworzeniu 2 dużych, przechowywanych procedur SQL i optymalizacji ich z planisty zapytań, każdy czas ładowania DB spadł do mniej niż 20 milisekund, więc oczywiście nadal istnieją powody wydajności, aby używać przechowywanych procedur SQL.
Powiedziawszy to, dowiedzieliśmy się, że najważniejszą zaletą procedur składowanych jest dodanie maintaince-łatwość, bezpieczeństwo, integralność danych i oddzielenie business-logic od middleware-logic, korzystając z wszystkich middleware-logic z ponownego użycia 2 procedur.
Nasz dostawca ORM twierdził, że odpalanie wielu małych zapytań SQL będzie bardziej wydajne niż pobieranie dużych, połączonych zestawów danych. Nasze doświadczenie (ku naszemu zaskoczeniu) pokazało coś innego.
Może się to oczywiście różnić między maszynami, sieciami, systemami operacyjnymi, serwerami SQL, frameworkami aplikacji, Frameworki ORM i implementacje językowe, więc zmierz każdą korzyść, myślisz, że możesz uzyskać z robienia czegoś innego.
Dopiero, gdy odkryliśmy, że problem był między ORM a bazą danych biorąc cały ładunek.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-25 14:55:48
Wolę używać SP, gdy ma to sens. W SQL Server i tak nie ma przewagi wydajności SP nad parametryzowanym zapytaniem.
Jednak w mojej obecnej pracy mój szef wspomniał, że jesteśmy zmuszeni do korzystania z SP, ponieważ nasi klienci tego wymagają. Czują, że są bardziej bezpieczne. Nie byłem tu wystarczająco długo, aby sprawdzić, czy wdrażamy zabezpieczenia oparte na rolach, ale mam przeczucie, że tak.
Więc uczucia klienta przewyższają wszystkie inne argumenty w tym case.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 20:45:03
Dla mnie jedną z zalet procedur składowanych jest bycie niezależnym od języka hosta: możesz przełączyć się z C, Pythona, PHP lub innej aplikacji na inny język programowania bez przepisywania kodu. Ponadto niektóre funkcje, takie jak operacje zbiorcze, poprawiają wydajność i nie są łatwo dostępne (wcale nie?) w językach goszczących.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-11 16:20:18
Nie wiem, czy są szybsze. Lubię używać ORM do dostępu do danych (aby nie wymyślać koła), ale zdaję sobie sprawę, że nie zawsze jest to realna opcja.
Frans Bouma ma dobry artykuł na ten temat: http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 20:34:44
Przeczytaj Frans Bouma doskonały post (jeśli trochę stronniczy) na ten temat.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 20:35:26
Mogę rozmawiać tylko z SQL serverem. Na tej platformie procedury przechowywane są piękne, ponieważ serwer przechowuje plan wykonania, co w większości przypadków znacznie przyspiesza wydajność. Mówię "w większości przypadków", ponieważ jeśli SP ma bardzo różne ścieżki wykonania, możesz uzyskać nieoptymalną wydajność. Jednak nawet w tych przypadkach, niektóre oświecone refaktoryzacji SPs może przyspieszyć rzeczy.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 20:39:05
Używanie procedur składowanych dla operacji CRUD jest prawdopodobnie przesadą, ale będzie zależeć od używanych narzędzi i własnych preferencji (lub wymagań). Preferuję inline SQL, ale upewniam się, że używam sparametryzowanych zapytań, aby zapobiec atakom SQL injection. Trzymam wydruk z tego komiksu xkcd jako przypomnienie, co może pójść nie tak, jeśli nie jesteś ostrożny.
Procedury przechowywane mogą mieć realne korzyści z wydajności, gdy pracujesz z wieloma zestawami danych, aby zwrócić jeden zestaw danych. Zwykle bardziej wydajne jest przetwarzanie zestawów danych w procedurze składowanej niż przesyłanie ich przez przewód do przetworzenia na końcu klienta.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 21:01:47
Uświadomienie sobie tego jest nieco poza tematem pytania, ale jeśli używasz wielu procedur składowanych, upewnij się, że istnieje spójny sposób, aby umieścić je pod jakąś kontrolą źródła (np. subversion lub git) i być w stanie przenieść aktualizacje z systemu deweloperskiego do systemu testowego do systemu produkcyjnego.
Kiedy robi się to ręcznie, bez możliwości łatwego sprawdzenia, gdzie jest kod, szybko staje się to koszmarem.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-13 14:51:53
Przechowywane PROCKI są świetne w przypadkach, gdy kod SQL jest często uruchamiany, ponieważ baza danych przechowuje go w pamięci tokenizowanej. Jeśli wielokrotnie uruchamiałeś ten sam kod poza przechowywanym proc, będziesz likey ponieść trafienie wydajności z bazy danych reparsing ten sam kod w kółko.
Zwykle często nazywałem kod jako przechowywany proc lub jako obiekt SqlCommand (. NET) i wykonywałem tyle razy, ile potrzeba.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 20:34:57
Tak, przez większość czasu są szybsze. Skład SQL to również ogromny obszar strojenia wydajności. Jeśli robię aplikację typu back office, mogę je pominąć, ale cokolwiek stoi przed produkcją, używam ich na pewno ze wszystkich powodów, dla których inni też mówili...mianowicie bezpieczeństwo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-12 21:03:08
IMHO...
Ograniczenie operacji "C_UD" do procedur przechowywanych może utrzymać logikę integralności danych w jednym miejscu. Można to również zrobić poprzez ograniczenie operacji "C_UD" do pojedynczej warstwy środkowej ware.
Operacje odczytu mogą być dostarczone do aplikacji, dzięki czemu mogą łączyć się tylko z potrzebnymi tabelami / kolumnami.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-13 16:03:53
Procedury przechowywane mogą być również używane zamiast zapytań parametryzowanych (lub zapytań ad-hoc) dla innych korzyści :
- Jeśli musisz coś poprawić (kolejność sortowania itp.) nie musisz rekompilować aplikacji
- możesz odmówić dostępu do wszystkich tabel dla tego konta użytkownika, przyznać dostęp tylko do procedur przechowywanych i przekierować cały dostęp za pomocą procedur przechowywanych. W ten sposób możesz mieć niestandardową walidację wszystkich danych wejściowych znacznie bardziej elastyczną niż ograniczenia tabeli.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-13 22:50:34
Zmniejszony ruch sieciowy -- SP są na ogół gorsze niż dynamiczny SQL. Ponieważ ludzie nie tworzą nowego SP dla każdego select, jeśli potrzebujesz tylko jednej kolumny, którą powiedziano ci, użyj SP, który ma kolumny, których potrzebują i zignoruj resztę. Uzyskaj dodatkową kolumnę i mniejsze zużycie sieci, które właśnie odeszło. Masz również tendencję do filtrowania klientów, gdy używane są SP.
Buforowanie -- MS-SQL nie traktuje ich inaczej, nie od MS-SQL 2000 może być 7, ale nie pamiętaj.
Uprawnienia -- nie jest to problem, ponieważ prawie wszystko, co robię, jest Internetem lub mam jakąś średnią warstwę aplikacji, która ma cały dostęp do bazy danych. Jedynym oprogramowaniem, z którym pracuję, które mają bezpośredni dostęp Klienta do bazy danych, są produkty innych firm, które są przeznaczone dla użytkowników, aby mieć bezpośredni dostęp i opierają się na nadawaniu użytkownikom uprawnień. I tak MS-SQL permission security model SUCKS!!! (nie spędził czasu na 2008 jeszcze) jako ostatnia część do tego chciałbym zobaczyć badanie jak Wiele osób nadal wykonuje bezpośrednie programowanie klienta / serwera vs web i middle application server programowanie; a jeśli robią duże projekty, dlaczego nie ORM.
Separacja-ludzie zastanawiają się, dlaczego stawiasz logikę biznesową poza średnim poziomem. Również jeśli chcesz oddzielić kod obsługi danych, możesz to zrobić bez umieszczania go w bazie danych.
Możliwość edycji -- co nie masz testowania i kontroli wersji, o którą musisz się martwić? Również tylko a problem z klientem / serwerem, w świecie www nie problem.
Znajdź tabelę -- tylko jeśli możesz zidentyfikować SP, które go używają, zostanie przy narzędziach systemu kontroli wersji, agenta ransacka lub visual studio, aby znaleźć.
Optymalizacja -- Twój DBA powinien używać narzędzi bazy danych, aby znaleźć zapytania, które wymagają optymalizacji. Baza danych może powiedzieć DBA, jakie Oświadczenia mówią najwięcej czasu i zasobów i mogą naprawić stamtąd. Dla złożonych poleceń SQL programiści powinni być poinformowani, aby porozmawiali z DBA, jeśli proste selekcje nie martw się o to.
Ataki SQL injection -- SP nie oferują lepszej ochrony. Jedyną rzeczą, którą dostają, jest to, że większość z nich uczy za pomocą parametrów vs dynamiczny SQL większość przykładów ignoruje parametry.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-07-08 15:42:54