Kiedy lepiej napisać "ad hoc sql" vs procedury przechowywane [duplikat]
To pytanie ma już odpowiedź tutaj:
- Jakie są plusy i minusy utrzymywania SQL w przechowywanym Procs kontra Kod [zamknięty] 47 odpowiedzi
Mam 100% ad hoc sql przez moją aplikację. Mój kumpel zalecił mi konwersję na procedury przechowywane dla dodatkowej wydajności i bezpieczeństwa. To wywołało w moim umyśle pytanie, poza szybkość i bezpieczeństwo czy jest jakiś inny powód, aby trzymać się zapytań ad hoc sql?
17 answers
SQL Server buforuje plany wykonywania zapytań ad-hoc, więc (pomijając czas potrzebny na pierwsze wywołanie) dwa podejścia będą identyczne pod względem szybkości.
Ogólnie rzecz biorąc, użycie procedur składowanych oznacza pobranie części kodu potrzebnego przez Twoją aplikację (zapytania T-SQL) i umieszczenie go w miejscu, które nie jest pod kontrolą źródła (it can be, ale zazwyczaj isn ' t ) i gdzie może być zmieniony przez innych bez Twojej zgody. wiedza.
Posiadanie zapytań w centralnym miejscu, takim jak to Może być dobrą rzeczą, w zależności od tego, ile różnych aplikacji potrzebuje dostępu do danych, które reprezentują. Ogólnie rzecz biorąc, znacznie łatwiej jest zachować zapytania używane przez aplikację rezydującą w samym kodzie aplikacji.
W połowie lat 90-tych konwencjonalna mądrość mówi, że procedury przechowywane w SQL Server były drogą do zrobienia w sytuacjach krytycznych dla wydajności, a w tym czasie zdecydowanie byliśmy. Przyczyny tego CW nie były jednak aktualne od dłuższego czasu.
Update: również, często w debatach na temat żywotności procedur składowanych, potrzeba zapobiegania wstrzykiwaniu SQL jest wywoływana w obronie proc. Z pewnością nikt przy zdrowych zmysłach nie uważa, że składanie zapytań ad hoc za pomocą konkatenacji łańcuchów jest właściwą rzeczą do zrobienia(chociaż narazi cię to na atak SQL injection tylko wtedy, gdy połączysz dane wejściowe użytkownika ). Oczywiście zapytania ad hoc powinny być parametryzowane, nie tylko po to, aby zapobiec potwornemu atakowi SQL injection, ale także po to, aby ułatwić Ci życie jako programiście (chyba że lubisz wiedzieć, kiedy używać pojedynczych cudzysłowów wokół swoich wartości).
Update 2: zrobiłem więcej badań. Na podstawie tej białej księgi MSDN , wydaje się, że odpowiedź zależy od tego, co masz na myśli przez "ad-hoc" z zapytaniami, dokładnie. Na przykład prosty zapytanie takie:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 5
... będzie miał buforowany plan wykonania. Co więcej, ponieważ zapytanie nie zawiera pewnych dyskwalifikujących elementów (jak prawie wszystko inne niż prosty wybór z jednej tabeli), SQL Server faktycznie "Auto-parametryzuje" zapytanie i zastąpi literalną stałą "5" parametrem, i buforuje plan wykonania dla sparametryzowanej wersji. Oznacza to, że jeśli wykonasz to zapytanie ad-hoc:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 23
... Informatyka będzie mógł korzystać z buforowanego planu realizacji.
Niestety, lista dyskwalifikujących elementów zapytania do auto-parametryzacji jest długa (np. zapomnij o używaniu DISTINCT, TOP, UNION, GROUP BY, OR itd.), więc naprawdę nie można na to liczyć.
Jeśli masz "super złożone" zapytanie, które nie będzie automatycznie parametryzowane, jak:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 5 OR ITEM_COUNT < 23
... będzie nadal buforowany przez dokładny tekst zapytania, więc jeśli aplikacja wywoła to zapytanie z te same dosłowne "zakodowane na twardo" wartości wielokrotnie, każde zapytanie po pierwszym użyje ponownie buforowanego planu wykonania (i tym samym będzie tak szybkie jak zapisany proc).
Jeśli wartości dosłowne ulegną zmianie (na podstawie działań użytkownika, na przykład filtrowania lub sortowania przeglądanych danych), zapytania nie będą korzystać z buforowania (z wyjątkiem sporadycznych przypadków, gdy przypadkowo dokładnie dopasują Ostatnie zapytanie).
Sposobem na skorzystanie z buforowania za pomocą zapytań "ad-hoc" jest ich parametryzacja. Tworzenie zapytanie w locie w C# Tak:
int itemCount = 5;
string query = "DELETE FROM tblSTUFF WHERE ITEM_COUNT > " +
itemCount.ToString();
Jest niepoprawne. Prawidłowy sposób (za pomocą ADO.Net) byłoby coś takiego:
using (SqlConnection conn = new SqlConnection(connStr))
{
SqlCommand com = new SqlCommand(conn);
com.CommandType = CommandType.Text;
com.CommandText =
"DELETE FROM tblSTUFF WHERE ITEM_COUNT > @ITEM_COUNT";
int itemCount = 5;
com.Parameters.AddWithValue("@ITEM_COUNT", itemCount);
com.Prepare();
com.ExecuteNonQuery();
}
Zapytanie nie zawiera liter i jest już w pełni sparametryzowane, więc kolejne zapytania używając identycznej sparametryzowanej instrukcji użyłyby buforowanego planu (nawet jeśli wywoływane są z różnymi wartościami parametrów). Zauważ, że kod tutaj jest praktycznie taki sam jak kod, którego używasz do wywołania procedury składowanej (jedyna różnica to CommandType i CommandText), więc sprowadza się to nieco do tego, gdzie chcesz, aby tekst tego zapytania był "żywy" (w kodzie aplikacji lub w procedurze składowanej).
Wreszcie, jeśli przez zapytania "ad-hoc" masz na myśli, że dynamicznie konstruujesz zapytania z różnymi kolumnami, tabelami, parametrami filtrowania i tym podobne, jak te:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 5
SELECT ID, FIRSTNAME, LASTNAME FROM tblPEEPS
WHERE AGE >= 18 AND LASTNAME LIKE '%What the`
SELECT ID, FIRSTNAME, LASTNAME FROM tblPEEPS
WHERE AGE >= 18 AND LASTNAME LIKE '%What the`
ORDER BY LASTNAME DESC
... wtedy praktycznie nie można {[16] } zrobić tego z procedurami składowanymi (bez EXEC hack, o którym nie można mówić w uprzejmości społeczeństwa), więc rzecz jest niemowa.
Update 3: oto jedyny naprawdę dobry związany z wydajnością powód (który i tak mogę wymyślić) do używania procedury składowanej. Jeśli Twoje zapytanie jest długotrwałe, w którym proces kompilacji planu realizacji trwa znacznie dłużej niż rzeczywiste wykonanie, a zapytanie jest wywoływane tylko rzadko (na przykład raport miesięczny), umieszczenie go w procedurze składowanej może sprawić, że SQL Server zachowa skompilowany plan w pamięci podręcznej na tyle długo, aby nadal trwał około przyszłego miesiąca. Nie wiem, czy to prawda, czy nie.
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-06-09 17:17:58
Nie ma nic w procedurach składowanych, co czyni je magicznie szybszymi lub bezpieczniejszymi. Istnieją przypadki, w których dobrze zaprojektowany przechowywany proc może być szybszy dla niektórych typów zadań, ale odwrotność jest również prawdziwa dla ad hoc SQL.
Koduj tak, jak uważasz za najbardziej produktywne.
"zrób to, zanim zrobisz to szybciej."--Brian Kernighan
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-04-29 00:25:04
Jeśli nie piszesz procedur składowanych, zbadaj zapytania parametryzowane . Jeśli sam zbudujesz SQL wraz z konkatenacją parametru, zaprosisz atak SQL injection .
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-04-29 00:27:53
Jest kilka mitów związanych z tym tematem, z których powinieneś się pozbyć:
Mit 1: procedury przechowywane są pre-compiled
http://scarydba.wordpress.com/2009/09/30/pre-compiled-stored-procedures-fact-or-myth/
Mit 2: zapytania ad Hoc SQL nie wykorzystują ponownie planów wykonania: http://scarydba.wordpress.com/2009/10/05/ad-hoc-queries-dont-reuse-execution-plans-myth-or-fact/
IMHO PROCKI mają przewagę, kiedy absolutnie musimy zablokować bazę danych. W takich sytuacjach możesz użyć konta, które ma tylko prawa do wykonywania procedur przechowywanych. Ponadto mogą one zapewnić warstwę abstrakcji między aplikacją a bazą danych z perspektywy DBA.
Podobnie dynamiczny SQL jest lepszy w sytuacjach, w których zapytanie może wymagać zmiany niektórych i być... cóż... dynamiczny. Lub jeśli wiesz, że musisz przenieść do wielu baz danych.
Oba są tak samo bezpieczne w odniesieniu do SQL injection tak długo, jak wszystkie wprowadzone przez użytkownika wartości są parametryzowane.
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-04-29 00:56:06
Wiele rzeczy zostało już powiedziane o wydajności, buforowaniu i bezpieczeństwie w tym wątku i nie będę powtarzał tych punktów. Jest kilka rzeczy, których jeszcze nie czytałem w tym wątku, czyli kwestie przenośności i rountrips.
- Jeśli interesuje Cię maksymalna przenośność aplikacji w różnych językach programowania, to procedury przechowywane są dobrym pomysłem: im więcej logiki programu przechowujesz w bazie danych poza aplikacją, tym mniej musisz rekodować, jeśli jesteś przejście do innego frameworka lub języka. Ponadto kod do wywołania procedury składowanej jest znacznie mniejszy niż rzeczywisty surowy SQL, więc interfejs bazy danych w kodzie aplikacji będzie miał mniejszy rozmiar.
- Jeśli potrzebujesz tej samej logiki w wielu aplikacjach, wtedy procedury przechowywane są wygodne, aby mieć jedną definicję tej logiki, która może być ponownie używana przez inne aplikacje. Jednak ta korzyść jest o wiele przesadzona, ponieważ można również wyizolować tę logikę w biblioteka udostępniana w różnych aplikacjach. Oczywiście, jeśli aplikacje są w różnych językach, to istnieje prawdziwa korzyść w procedurach składowanych, ponieważ prawdopodobnie łatwiej jest wywołać procedurę poprzez interfejs db Twojego języka niż połączyć się z biblioteką napisaną w innym języku.
- Jeśli interesuje Cię przenośność RDBMS, procedury przechowywane mogą stać się jednym z twoich największych problemów. Podstawowe cechy wszystkich głównych i mniejszych RDBM-ów są dość podobne. Największe różnice można znaleźć w składni i dostępnych wbudowanych funkcjach procedur składowanych.
Odnośnie przejazdów w obie strony:
- Jeśli w Twojej aplikacji jest wiele transakcji z wieloma instrukcjami lub ogólnie funkcje, które wymagają wielu stanów SQL, wydajność może się poprawić, jeśli umieścisz te wiele poleceń w procedurze składowanej. Powodem jest to, że wywołanie procedury składowanej (i ewentualnie zwrócenie z niej wielu wyników) jest tylko jednym rountrip. Z surowym SQL, masz (co najmniej) jeden roundtrip na polecenie SQL.
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-04-29 02:33:03
Przenośność, gdy trzeba przełączyć się na nowy serwer SQL i nie mieć dostępu do starego.
Pracowałem nad kilkoma projektami, w których pierwotny deweloper nie dawał dostępu do serwera, po zwolnieniu go, więc musieliśmy sami napisać wiele zapytań, ponieważ były zamknięte w procedurach przechowywanych, do których nie mieliśmy uprawnień. Gdyby wszystkie zapytania były w kodzie źródłowym, byłoby to o wiele łatwiejsze.
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-04-29 00:27:25
Nie martwiłbym się o wydajność, dopóki nie pojawią się rzeczywiste punkty bólu. Na przykład ktoś korzysta z Twojej aplikacji i skarży się, że jest ona powolna. Dopóki nie osiągniesz tego punktu, twój czas najlepiej poświęcić na ulepszanie aplikacji.Mam 100% ad hoc sql przez moje podanie. Mój kumpel zalecane, aby przekonwertować do przechowywanych procedury dotyczące dodatkowego wykonania i Ochrona.
W bezpieczeństwie, musisz zrównoważyć wysiłek i ryzyko. Jeśli strona nie przechowuje niczego wartościowego, nawet SQL Injection jest całkowicie akceptowalnym ryzykiem, O czym świadczy duża liczba stron internetowych:)
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-04-29 01:32:19
Nie widzę, kiedy zapytania Ad Hoc dałyby jakieś korzyści. Omawiając z przyjacielem to samo pytanie, stwierdziliśmy, że za procedurami składowanymi (oprócz oczywistych problemów z buforowaniem/SQL Injection) przemawiają następujące rzeczy:
1) czytelność kodu: jeśli masz jakiś owłosiony kod SQL osadzony w aplikacji, staje się znacznie trudniejsze do odczytania/zrozumienia. O wiele prostsze jest posiadanie dobrej konwencji nazewnictwa do procedur składowanych, która mówi dokładnie to, co robi, zamiast dużo kodu. On mniej więcej te same zasady, których staramy się używać podczas refaktoryzacji.
2) możliwość ulepszania aplikacji bez konieczności ponownego wprowadzania: jeśli musisz poprawić logikę z powodu błędów lub słabej wydajności, osadzenie kodu SQL w aplikacji oznacza, że musisz go ponownie wprowadzić (nawet jeśli zestaw danych się nie zmienia). Jeśli masz go w procedurze składowanej, jedyną rzeczą, którą musisz przesunąć, jest procedura. Ponadto daje zmiany w DBA, aby zrobić jego magię, poprawiając ogólny wykonanie zapytania poprzez pracę z procedurą. Byłoby to znacznie trudniejsze, jeśli pracujesz z wersją osadzoną.
3) ruch sieciowy: jeśli przekazujesz dużo kodu SQL wokół siebie, zwiększasz rozmiar wiadomości (lub wywołań RPC) przesyłanych przez sieć, co może prowadzić do słabej wydajności z powodu żądań. Szczególnie, jeśli wielu użytkowników do tych samych połączeń za każdym razem.
Mam nadzieję, że to pomoże.
Zdrówko, Wagner.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-04-29 02:14:01
Moja odpowiedź może być nieco off topic, ale tak czy inaczej:
Może się przydać podczas pracy z widokami. Hibernate (którego nie używasz) na przykład ma dość złe wsparcie dla widoków. Kiedy muszę odpytywać za pomocą niego widok, zawsze używam surowego SQL, ponieważ jest to jedyna rzecz, która działa.
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-04-29 00:25:06
Jedną z zalet procedur składowanych jest to, że dane nie muszą być przesyłane przez sieć do obliczeń pośrednich. Jeśli wiele obliczeń daje jedną wartość, wtedy procedura składowana będzie szybsza.
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-04-29 20:22:25
Mówiąc z mojego doświadczenia, chciałbym umieścić korzystny punkt dla każdej metody.
Punkt dla Ad-Hoc SQL:
Zdarza się, że Ad-Hoc SQL jest mniej bolesny (początkowo), co wiąże się z dużym (i dynamicznym) zakresem parametrów wyszukiwania. Załóżmy na przykład, że masz Wyszukiwanie kont i zaawansowane wyszukiwanie kont towarzyszących, które zawiera 3 razy więcej parametrów. Niektóre pola są łatwe (konto#); inne mogą być bardzo bolesne (wyszukiwanie fragmentu w linii adresu 1!) Oraz za najgorsze, większość parametrów nie są wymagane.
To sprawia, że strojenie wydajności nie jest trywialne. W tym przypadku, mając tak wiele kombinacji parametrów, buforowanie planu wykonania (moje doświadczenie jest na MS SQL) będzie backfire. Plan wykonania, powiedzmy, podania tylko konta # i sprzedawcy #, potencjalnie będzie bardzo zły dla innego zestawu wyszukiwania, zapewniającego wyszukiwanie adresów i marki, które noszą. Ad-Hoc SQL będzie miał efekt uboczny rekompilacji w oparciu o różne zestawy podanych parametrów, a tym samym poruszanie się po problemie buforowania planu wykonania.
Oczywiście powyższe może być wykonane również za pomocą procedury składowanej, ale aby ominąć problem buforowania planu wykonania, będziesz musiał uruchomić polecenie przekompiluj w ramach procedury składowanej. Można również argumentować, że dynamiczna konstrukcja SQL może być umieszczona w procedurze składowanej, ale to tylko przeniesienie Ad-Hoc SQL w inne miejsce; nadal Ad-Hoc SQL.
Punkt dla przechowywanych Procedura:
Można traktować procedury składowane jako API. Jeśli pracowałeś nad środowiskami korporacyjnymi, są szanse, że różne aplikacje będą robić dokładnie to samo. Na przykład tabela zdarzeń może być wstawiana z różnych programów, w tym księgowości,Sprzedaży, audytu, zarządzania relacjami z klientami itp. Programy te mogą nie być utrzymywane przez tę samą grupę osób (np. różne poddziały), ale ostatecznie będą miały dostęp do tych samych podstawowych baza danych.
W tym przypadku byłoby koszmarem zarządzania kodem źródłowym przy użyciu Ad-Hoc SQL, ponieważ skutkowałoby to wieloma wersjami Ad-Hoc SQL wykonującymi tę samą funkcjonalność, w których każda wersja może mieć inne skutki uboczne. Obecnie mam do czynienia z tą sytuacją i to nie jest zabawne. Procedury składowane w tym przypadku mogą być ponownie wykorzystane, dzięki czemu mają centralne zarządzanie kodami baz 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
2010-05-01 05:13:14
Prawdę mówiąc, SQL injection można zapobiec poprzez parametryzację zapytań (spójrz na przykład w ODBCParameters), a Twoje zapytania mogą być skonstruowane w taki sposób, że te parametry nie mogą być SQL Injection. Na przykład...
DECLARE @param varchar(50)
SELECT @param = ?
SELECT * FROM TABLE WHERE NAME = @param
Jest bezpieczną metodą wykonywania zapytań wewnętrznych z parametrami ODBC. Istnieją jednak pewne zalety korzystania z procedur składowanych:
- złożony SQL z wieloma funkcjami lub kursorami może zepsuć się, jeśli jest używany w sposób ad-hoc, jak niektóre sterowniki ODBC Nie wiem, jak obsługiwać wiele zapytań
- oddziela logikę biznesową od wywołań bazy danych. Pozwala to (programista aplikacji) nie wiedzieć nic o strukturze bazy danych i nadal rozwijać swoją aplikację, podczas gdy dedykowany programista DBA lub SQL może dostroić SQL.
- procedury przechowywane są wstępnie skompilowane, więc po wielu powtórzeniach będą szybsze, ale tylko wtedy, gdy będą wywoływane niezwykle często (np. monitorowanie program)
Kiedy wszystko jest powiedziane i zrobione, to decyzja projektowa. Nie bierz pod uwagę przenośności, możesz po prostu mieć dev SQL dać ci skrypty do zastosowania procs sklepu i uruchomić je przy instalacji programu i tak :)
Hope this helps
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-16 17:20:24
Zapytania Ad-hoc zapewniają elastyczność logiki aplikacji, ale prawie zawsze płacisz cenę za wydajność.
Jeśli chodzi o wydajność, prawdopodobnie zgodziłbym się z twoim przyjacielem, że powinieneś zajrzeć do przechowywanych proców lub jakiejś bardziej statycznej formy zapytań, aby umożliwić bazie danych "wstępną optymalizację" zapytania lub zezwolić warstwie buforowania (jeśli taka istnieje) na potencjalnie buforowanie wyników zapytań.
Jeśli za każdym razem generujesz zapytanie w locie, baza danych będzie najbardziej prawdopodobnie nie będzie w stanie pomóc w ogóle z wydajnością.
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-04-29 00:24:37
- nie musisz pisać procedury składowanej
- Ogólnie ad-hoc SQL jest wystarczająco szybki. Możesz użyć parametryzowanych zapytań, aby zwiększyć szybkość.
- możesz skompilować SQL oparty na łańcuchach znaków do "skompilowanego" SQL, a następnie wykonać to, co jest znacznie szybsze.
- Zazwyczaj wąskim gardłem wydajności dla SQL są zapytania Nie żadne z powyższych.
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-04-29 00:26:47
To może zależeć od tego, kto jeszcze używa db. Jeśli tylko jedna aplikacja korzysta z db, to parametryzowane zapytania mają tę zaletę, że znajdują się w źródle.
Jeśli inne aplikacje używają db, to dba powinien umieścić w db wspólne procedury składowane.
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-04-29 02:06:51
Nie ma "właściwej" odpowiedzi. To zależy od każdej sytuacji.
Czy ktoś o tym wspominał? Procedury składowane zazwyczaj zwracają każde pole i nie jest możliwe utworzenie jednego dla każdej wybranej odmiany pól. Ad-hoc pozwala określić tylko te, które chcesz. Jeśli jednak używasz dowolnego rodzaju obiektów (obiekty niestandardowe, EF itp.) pewnie i tak zwrócisz wszystkie pola.
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-04-29 20:26:55
Prawdopodobnie nie będzie korzyści z wydajności, ale dla łatwości utrzymania warto rozważyć użycie czegoś takiego jak LINQ2SQL, aby nie mieć błędów składniowych w SQL.
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-06-09 16:06:06