renathy Posted June 7, 2017 Report Share Posted June 7, 2017 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... Quote Link to comment Share on other sites More sharing options...
Sasa Posted June 8, 2017 Report Share Posted June 8, 2017 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. Quote Link to comment Share on other sites More sharing options...
renathy Posted June 8, 2017 Author Report Share Posted June 8, 2017 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. Quote Link to comment Share on other sites More sharing options...
Sasa Posted June 8, 2017 Report Share Posted June 8, 2017 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. Quote Link to comment Share on other sites More sharing options...
briedis Posted June 8, 2017 Report Share Posted June 8, 2017 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. Quote Link to comment Share on other sites More sharing options...
Sasa Posted June 8, 2017 Report Share Posted June 8, 2017 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. Quote Link to comment Share on other sites More sharing options...
briedis Posted June 8, 2017 Report Share Posted June 8, 2017 Nerunāsim nemaz par Oracle sistēmām ;) Brrr, kaut kas baiss! Quote Link to comment Share on other sites More sharing options...
aaxc Posted June 9, 2017 Report Share Posted June 9, 2017 Kāpēc uzreiz baiss. Skaisti! Quote Link to comment Share on other sites More sharing options...
ieleja Posted June 9, 2017 Report Share Posted June 9, 2017 [brīdis, kad vairs nesaproti, kurš ir sarkastiskāks] Quote Link to comment Share on other sites More sharing options...
Roze Posted June 11, 2017 Report Share Posted June 11, 2017 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). Quote Link to comment Share on other sites More sharing options...
l27 Posted June 17, 2017 Report Share Posted June 17, 2017 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.