Jump to content
php.lv forumi

MongoDB iesācējiem/pieredze


Wuu
 Share

Recommended Posts

  • Replies 59
  • Created
  • Last Reply

Top Posters In This Topic

DRY ir princips. Idejiski to var elementāri attiecināt arī uz datubāzēm. Normalizācija ir krietni vien plašāks jēdziens, kas sevī ietver arī DRY.

Datubāzēs darbojas principi denormalizēti un normalizēti dati/shēma. Ne viens ne otrs princips ir labs vai ļauns, un atkarībā no mērķa abi ir pielietojami tai vai citā gadījumā un ir datubāzes shēmas, kurās duplicēti dati ir ne tikai vēlami, bet pat nepieciešami. Piemēram, milzīgas, denormalizētas agregācijas tabulas. 

Link to comment
Share on other sites

Man vairāk patīk SQL daba, kā tāda.

Raksti kodu pierastā formā un tad pēkšņi

Mīļā datubāze, lūdzu atrodi ierakstu tabulā - lietotāji, kuram identifikācijas numurs ir vienāds ar [kaut kāda huņja, a.k. "'., no programmas]666[/kaut kāda huņja, a.k. .'" no programmas], ar cieņu programma.

Vai arī pa virsu, pasists ORM, kas izpildās par 30% lēnāk, nē kā standarta pieprasījums. Nezinu kā ar PHP, bet node, šis pasākums ir loti skumjš. 

Link to comment
Share on other sites

SQL daba, wtf? Parunāsim vēl par dažādu DBMS enerģētiku un auras krāsu? Ja tu nemāki rakstīt SQL, tad tā arī pasaki, nevis runā par kaut kādām pierastajām formām. SQL sintakse man, piemēram, šķiet ļoti pierasta forma, kad runa iet par SQL pieprasījumu rakstīšanu.

 

Punkts divi, ja tu nemāki izmantot ORM (lasīt - izmanto tur, kur vairs nav jāizmanto ORM), tad tā nav ne ORM, ne SQL, ne PHP, ne node.js vaina, bet gan curved_hands.dll/so, ka viss bremzē.

Link to comment
Share on other sites

 

 

Vai arī pa virsu, pasists ORM, kas izpildās par 30% lēnāk, nē kā standarta pieprasījums

 

SQL pieprasījums un tā izpildes ātrums nemainās no tā vai tur ir ORM (uzbildots kverijs) pa virsu vai nav (uzrakstits kverijs). 

Link to comment
Share on other sites

@Kavacky Ko tur nemācēt, gadiem drukāti tie kveriji, bet kad palieto ko jēdzīgāku, atpakaļgaitu negribas slēgt.

 

Tā arī daru, jaunajā projektā kur ir postgres, optimizēju ar tiešiem pieprasījumiem, ignorējot ORM. Pieaugums apmēram 50%.

Link to comment
Share on other sites

SQL daba, wtf? Parunāsim vēl par dažādu DBMS enerģētiku un auras krāsu? Ja tu nemāki rakstīt SQL, tad tā arī pasaki, nevis runā par kaut kādām pierastajām formām. SQL sintakse man, piemēram, šķiet ļoti pierasta forma, kad runa iet par SQL pieprasījumu rakstīšanu.

 

Punkts divi, ja tu nemāki izmantot ORM (lasīt - izmanto tur, kur vairs nav jāizmanto ORM), tad tā nav ne ORM, ne SQL, ne PHP, ne node.js vaina, bet gan curved_hands.dll/so, ka viss bremzē.

This.

 

@Kavacky Ko tur nemācēt, gadiem drukāti tie kveriji, bet kad palieto ko jēdzīgāku, atpakaļgaitu negribas slēgt.

 

Tā arī daru, jaunajā projektā kur ir postgres, optimizēju ar tiešiem pieprasījumiem, ignorējot ORM. Pieaugums apmēram 50%.

Un kādu ORM tad Tu izmantoji, ja ORM-like queries tev pieaugums bija 50%? Un vai tie 50% nebija Object side?

Link to comment
Share on other sites

Un kādu ORM tad Tu izmantoji, ja ORM-like queries tev pieaugums bija 50%? Un vai tie 50% nebija Object side?

Heh, tas pats Eloquents pie jebkura pieprasījuma ģeniali izpilda fetchAll, attiecīgi aizdiršot visu atmiņu, ja rezultāts ir pietiekami liels. Tā vietā, lai dotu normālu single row fetch, kas strādā ievērojami efektīvāk. Protams, ja tādas problēmas rodas, tad prātīgāk bieži vien būtu taisīt jau zemāka līmeņa datu agregāciju, nevis katru rindu lasīt kā veselu modeļa objektu. Un to darīt visām rindām vienlaicīgi. Edited by Kavacky
Link to comment
Share on other sites

Heh, tas pats Eloquents pie jebkura pieprasījuma ģeniali izpilda fetchAll, attiecīgi aizdiršot visu atmiņu, ja rezultāts ir pietiekami liels. Tā vietā, lai dotu normālu single row fetch, kas strādā ievērojami efektīvāk. Protams, ja tādas problēmas rodas, tad prātīgāk bieži vien būtu taisīt jau zemāka līmeņa datu agregāciju, nevis katru rindu lasīt kā veselu modeļa objektu. Un to darīt visām rindām vienlaicīgi.

Doctrine2 relācijas var būt lazy (e.g. ielādē associated objektu tikai kad reāli izmanto) un Iterate, kas ielādē pa vienam rezultātam. By default gan arī ir fetch-all, bet pamatā tāpēc, ka tiek sagaidīts, ka tiks izmantoti realistiski limiti. 

 

Tajā pašā laikā, uz doto brīdi es rakstu batch procesoru kam nāksies nolasīt un agregēt ap 40-50m rakstu darbus no mysql. Šajā gadījumā, custom code obviously un nekāda ORM. ORM tam nav jebkurā gadījumā paredzēts. 

Link to comment
Share on other sites

Doctrine2 relācijas var būt lazy (e.g. ielādē associated objektu tikai kad reāli izmanto) un Iterate, kas ielādē pa vienam rezultātam. By default gan arī ir fetch-all, bet pamatā tāpēc, ka tiek sagaidīts, ka tiks izmantoti realistiski limiti. 

 

Tajā pašā laikā, uz doto brīdi es rakstu batch procesoru kam nāksies nolasīt un agregēt ap 40-50m rakstu darbus no mysql. Šajā gadījumā, custom code obviously un nekāda ORM. ORM tam nav jebkurā gadījumā paredzēts. 

Āmen!

Link to comment
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...
 Share


×
×
  • Create New...