Jump to content
php.lv forumi
renathy

stored procedure

Recommended Posts

Radies vispārīgas dabas jautājums - vai mūsdienās vispār izmanto stored procedure kombinācijā PHP + MySQL.

Ja jā, tad vai varētu  minēt kādus gadījumus, kad stored procedure izmantošana varētu sevi attaisnot  / būtu lietderīga ?

Jautājums radies tādā kontekstā, ka palīdzu kādam draugam uzrakstīt kursa darbu, kura ietvaros ir jāuztaisa vienkārša PHP + MySQL. Un kā viens no punktiem ir minēta prasība - izveidot sotred procedure (saglabātās funkcijas / procedūras) un pamatot to izmantošanas nepieciešamību... 

Aplikācija būtībā vienkārša - ir lietotāji ar dažādām lomām; lietotāji postē materiālus vai lasa citu postētos materiālus; daži materiāli ir maksas; tiek imitēta apmaksas sistēma...

 

Share this post


Link to post
Share on other sites

Ja loģiku saliek DB tad klienta daļa (PHP; .NET) pa lielam var būt jebkas un nodrošina datu transportu no UI uz DB un otrādi.

Pa lielam visu ko mēs apstrādājam tie ir dati un kāpēc datu apstrādi vajadzētu iznest ārpus DB. Nākamais apsvērums ir tas, ka laika gaitā platformas var mainīties un stored procedūras var pasargāt no lielām pārmaiņām, PHP te īsti nebūs labākais piemērs, jo to var gan uz Windows, gan kā uz Linux darbināt.

Nezinu kā ir MySQL ar storētām procedūrām, bet PostgreSQL vai Oracle ir ok.

Share this post


Link to post
Share on other sites

Kā mīnusus es saskatu - stored procedure testējamība un versionēšana. Tāpat, ja izmantojam ORM, tad visas CRUD operācijas jau tāpat ir kodā, tad kāpēc dalīt kodu divās daļās (CRUD kodā, bet mistiskos selectus? DB līmenī). Ja .NETu skatamies, tad populārs tagad ir code first approach, kad vispār visa loģika ir kodā, arī DB loģika.

Un Sasa pirmais pluss, manuprāt, ir nosacīts, jo arī kodā var veikt datu apstrādi, kāpēc ne? Var izveidot gana labu un drošu arhitektūru.

Share this post


Link to post
Share on other sites

ORM'u ar nākamo versiju var samainīt tā ka migrācija uz jauno versiju var būt laikietilpīga, ko tad palikt pie vecās versijas?

Jā piekrītu par testējamību un versionēšanu bet tam arī ir risinājumi.

Kā vēl iemeslu var minēt stored procedūras izpildīsies ātrāk kā ORM'a ģenerētais SQL's, tā vajadzētu būt.

 

Share this post


Link to post
Share on other sites

Kas tad ir store procedūra? Tas ir kvērijs principā. Ja kvērijs ir pakaļā, nav indeksu utt, tad tas tevi arī nepasargās. Kaut kā pagaidām normāli iztiekam bez procedūrām, vajadzību toč nejūt.

Es kā lielāko mīnusu uzskatītu loģikas nodalīšanu, kas pēc tam apgrūtina koda uztveramību, jo jālēkā starp IDE'i un ģenerēto kvēriju. Kodā noteikti arī vieglāk ir veikt izmaiņas, versionēt, deployot.

Anyway, procedūras tāda niša vien ir, kaut kādos gadījumos noteikti nepieciešamas, bet ikdienā - nez vai.

Share this post


Link to post
Share on other sites

MySQL gadījumā storētās procedūras varbūt arī nebūtu piemērotas, bet datubāzēs kurās ir sava programmēšanas valoda storētās procedūras var noderēt.

Share this post


Link to post
Share on other sites
Quote

Ja jā, tad vai varētu  minēt kādus gadījumus, kad stored procedure izmantošana varētu sevi attaisnot  / būtu lietderīga ?


Storētās procedūras ir vienkārši papildus "slānis" (layer), kas ļauj izveidot interfeisu/API sistēmām un risinājumiem, kur tas ir nepieciešams (lai nodrošinātos kaut vai pret tiem pašiem programmētājiem) :)

Proti, piemēram, lasot komentāru "Kodā noteikti arī vieglāk ir veikt izmaiņas, versionēt, deployot." .. ir skaidrs, ka ik pārdienu ir vēlme (vai nu vienkārši tāds darba/organizācijas stils) mainīt kaut kādus pieprasījumus (SQL), kas reizēm rada ļoti neprognozējamas sekas un citas ķeskas.

Ar procedūrām ir iespējams panākt konkrētu API / prognozējuma risinājuma, produkta darbību un un DBA nav jāsatraucas un jānodarbojas ar zinātnisko pētniecību, ja pēkšņi DB serveris deg zilām liesmām tikai tāpēc, ka kaut kur kodā iesprausts pieprasījums, kas neizmanto indeksus, atgriež miljoniem ierakstu vai ko tamlīdzīgu .

Arī no drošības viedokļa, pretēji tam lai dotu pilnas piekļuves visiem (izstrādātājiem / aplikācijai), standarta SQL vietā var definēt konkrētas procedūras/funkcijas datu apmaiņai. tāpat iespējams "neuzticēties" aplikācijai ar ievad/izvaddatu apstrādi (izvairīties no SQL "injectiem").

Tīri no tehniska viedokļa - iespējams ietaupīt nedaudz resursus.(cpu/trafiks) proti, pretēji tam lai aplikācija katru reizi sūtītu gigantisku kveriju, kas SQL serverim ir jāsaņem / jāpārsē utt, var veikt procedūras izsaukumu ar parametriem un viss pārējais notiek servera pusē (protams, tas reizē arī ir mīnuss - DB serveri/risinājumi parasti skeilojas sliktāk nekā aplikāciju frontendi). 

Share this post


Link to post
Share on other sites

Parasti trigerus izmantoju audittrailam, lai automātiski logotu visas izmaiņas atsevišķā tabulā.

SP un trigerus ieteicams izmantot ātrdarbības uzlabošanai samazinot pieprasījumu skaitu uz DB. Piemēram audittrail gadījumā, ja izmanto trigerus, pietiek ar vienu griešanos pie DB, bet ja PHP pusē realizē audittrailu, nepieciešams papildus pieprasījumi katra lauka update gadījumā (var arī apvienot vienā).

No drošības viedokļa arī ir labāk izmantot SP, jo SP var izdarīt tikai to, kas tajā rakstīts, bet ja ir pilna pieeja DB, tad var darīt ko grib.

Ja nav nepieciešams security un ātrums, tad var iztikt bez trigeriem un SP.

 

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...