Odpowiedzcie na pytanko: implementować logike aplikacji poprzez procedury składowane, czy nie??
Różnie piszą, że już sam nie wiem - mówią żeby stosować, bo to jednak bezpieczniejsze, upraszcza sprawe,
bo zamiast wysyłać kilka zapytań z PHP, to lepiej z PHP wywołać procedurę (mniej danych transferowanych) itp...,
a inni mówią że tego już się raczej nie stosuje (raczej logika tkwi w aplikacji, a nie po stronie bazy)...
Jestem początkujący i robię stronkę w PHP i MySQL i w sumie to nie wiem jak podejść do tematu - wysyłąć zapytania z phpa
czy napisac procedurki-wiem ze mozna zrobic tak i tak, ale chcialbym wiedzieć jak Waszym zdaniem jest najpoprawniej
i jak to wyglada w praktyce (jak najcześciej jest to implementowane w profesjonalnych projektach).
Dzieki z góry i pozdrawiam

My co prawda stosujemy PostgreSQL i pl/PgSQL - ale to akurat niczego nie zmienia.
Powiem Ci, że bez tego mechanizmu MyCRM nie miałby wielu funkcjonalności - już sama historia rekordów w bazie byłaby awykonalna z logicznego punktu widzenia - nasz system przechowuje całą historię zmian i usunięć na każdym z rekordów każdej z tabel - pisanie tego w PHP nawet dysponujac w miarę zaawansowanym narzędziem DB, jakim jest LightDB DeyV'a byłoby tak obciążające system, że powiesić by się szło.<br>Mój podsystem fakturujący tez w wielu przypadkach bez procedur by stał by się zbyt skomplikowany i zbyt zasobożerny.

Oczywiście nie do wszystkiego się da zaimplementować procedury, ale na pewno są bardzo przydatnym narzędziem - wyzwalacze przed, po... po prostu magia.

Z punktu bezpieczeństwa lepiej oprzeć aplikację o procedury, jednak z ekonomicznego punktu widzenia lepiej oprzeć aplikację o zapytania wywoływane w php. Wiąże się to głównie z tym że poprawa czy zmiana jakiejś logiki zawartej w procedurze jest bardzo kosztowna.

Czym się różni przebudowa kodu PHP od przebudowy procedury, jeśli aplikacja jest dobrze zaprojektowana?

Różni się właściwie tym, że zamiast mieć całość logiki w jednym miejscu, ma się ją rozrzuconą po dwóch aplikacjach.

Inna trudność polega na tym, że aby zmienić kod procedury w MySQL, musisz ją najpierw skasować (i nie można tego zrobić w transakcji). Teoretycznie odstęp w czasie jest minimalny, ale przy obciążonej jest duże prawdopodobieństwo, że pojawią się odwołania do procedury której właśnie nie ma.

Niemniej jednak osobiście używam

Dobrym nawykiem jest wyłączenie aplikacji na czas aktualizacji - szczególnie jeśli aktualizujemy strukturę bazy

~dejw
Ciekawy temat poruszyłeś. Tak naprawdę nie ma złotego środka. Ja jestem zwolennikiem procedur w bazie danych. Jak wiadomo każde rozwiązanie ma swoje wady i zalety. Do wad można zaliczyć konieczność przepisywania dużej ilośći kodu w przypadku częstych modyfikacji bazy danych. Taka sytuacja ma miejsce, jeśli projekt, nad którym się pracuje, dopiero rodzi się w głowie klienta.
Główną zaletą tego rozwiązania jest przeniesienie ciężaru kosztownych operacji na serwer bazodanowy, czyli na maszynę, która do tego została kupiona. Jakoś nie wyobrażam sobie pisania kodu do obsługi drzew nested set w php/c#. O orzydatności triggerów chyba pisać nie muszę.

Jakoś nie mogę znaleźć różnicy w kosztach. W obu przypadkach trzeba ten kod przepisać. Różnią się tylko narzędzia.

W dużych systemach logikę masz rozrzuconą nie w dwa, a w dwadzieścia miejsc.

Po pierwsze: A po drugie. Jeśli podmieniasz pliki na serwerze, czy to przez ftp/sftp, czy przy użyciu systemu kontroli wersji, to jest taki moment, gdy pliku nie ma (lub jest częściowo nadpisany). Przy dużym obciążeniu maszyny, ta chwila może trwać długo, a co za tym idzie, pokaże się biała strona.

Zawsze można najpierw plik wgrać, a potem zmienić mu nazwę. Jest to oczywiście partyzantka, ale teoretyczna możliwość jest.

To co mnie boli w procedurach składowanych MySQL to właściwie ułomności samej implementacji języka. Np jeżeli chcę mieć procedurę, która wrzuci mi dane do tabeli tymczasowej o identyfikatorze wskazanym w parametrze, muszę zapytania składać w stringach i robić z nich zapytania przygotowane. W związku z czym w edytorze kolorowania składni nie mam, pomylić się łatwiej itp, itd.

W zasadzie problem sprowadza się do doboru odpowiedniego narzędzia. Nie pisałem zbyt dużo pod MySQL, ale nie pamiętam bym musiał kombinować coś z zapytaniami. Jeśli pojawia się taki problem, to zazwyczaj problemem jest nie kod, a błędne założenia projektowe.

No niestety, u mnie założeniem jest "nazwa tabeli wynikowej podawana jest w parametrze do procedury". Inaczej musiałbym sobie dublować procedury z takim samym kodem. Z tego co wiem w MySQLu nie da się tego na razie zrobić inaczej, jak przez skonstruowanie zapytania przygotowanego.

Dzięki wielkie za odpowiedzi.
Powiedzcie jeszcze czy znajdę hosting oferujący obsługę procedurek składowanych w MySQL,
bo z tego co się zorientowałem, to może być problem...
Z góry dzięki za odpowiedź.
i Wesołych Świąt wszystkim forumowiczom

To jest akurat zaleta chociażby w przypadku o którym wspomniał scanner. Ty zlecasz bazie danych pewne zadania, a skoro ona sama może zadbać o spójność pewnych danych to jest to jak najbardziej na plus. Oddzielasz od siebie logiki, które niekoniecznie muszą mieć ze sobą coś wspólnego.

Prosty przykład niekoniecznie ze świata phpowego.

Tworzysz interfejs i masz taki kod

Kod wywołujący nie musi teraz dbać aby ten button był odpowiednio szeroki, wysoki, żeby czcionka była odpowiednia bo o to dla Button.
Tak samo z bazą. Zlecasz jej zmianę rekordu, a że w założeniu aplikacji jest by była przechowywana historia zmian to już nie tworzy jej php tylko sama baza. Takie zachowania są wręcz zalecane.

To może być zaletą nie przeczę. Ale równie dobrze może być wadą, jeżeli w tym samym projekcie raz o to dba aplikacja, a raz baza danych. W idealnym świecie wszędzie jest porządek, w rzeczywistości zawsze ktoś zrobi bajzel.