MongoDB iesācējiem/pieredze

[jurchiks]

LOL :D Top komentārs arī labs.

[F3llony]

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. 

[jurchiks]

Turpinam strīdēties?

[aaxc]

Turpinam strīdēties?

Droši, mēs vēl tikai lemsim, vai pāriet uz Mogo vai pārstrukturizēt MySQL, tākā papildus viedokļi vēl noderēs ;)

[Wuu]

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š. 

[Kavacky]

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ē.

[Blitz]

 

 

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). 

[Wuu]

@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%.

[F3llony]

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?

[Blitz]

aaxc: https://www.percona.com/blog/2016/05/24/looking-inside-the-mysql-5-7-document-store/?utm_campaign=2016%20Q2%20Blogs%20--%204.5.16&utm_content=31004098&utm_medium=social&utm_source=linkedin

[Kavacky]

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 May 26, 2016 by Kavacky

[jurchiks]

Droši, mēs vēl tikai lemsim, vai pāriet uz Mogo vai pārstrukturizēt MySQL, tākā papildus viedokļi vēl noderēs ;)

That's not what I meant, but oh well.

[F3llony]

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. 

[Zefirs]

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!