waduh" bang tolong di bantu, abang kan educator nih, mungkin ketika bikin video edukasi tentang query di banntu me wanti" muritnya bahwa jangan pernah query SELECT * apa pun situasinya. Karena membuat good habits itu lebih mudah dari pada menyembuhkan bad habits, hanya query kolom yang kalian butuh ya teman" apalagi kalo sudah main Join table, karena bukan hanya berpengaruh terhadap performa query teman" karena kemungkinan banyak data yang redundant, tapi juga tidak baik untuk keamanan sistem karena bisa saja data sensitif ikut ter query, meskipun table isinya cuma 2=3 kolom dan datanya tidak senitif tetap query nama kolomnya langsung ya, untuk menimbulkan kebiasaan yang baik.
mantap pak, smlm saya baru belajar laravel eloquent, trs disebutin masalah N+1 query, hri ini lgsng ada video pembahasannya, untung sblm-sblmnya saya lgsng join, jadi ga pernah kena trouble ini😂
Sekedar berbagi. Kalo dalam ORM N+1 itu fitur, kalo gak pake ORM itu masalah skill SQL. Fitur ORM ini jadi problem kalo salah pakenya. Biasa terjadi kalo pake relasi tipe XToMany yang sebenernya bisa diganti dengan Unidirectional XToOne. Jika memakai tipe relasi XToOne, secara default ORM akan otomatis pake JOIN query. Di sisi lain seringkali requirements itu tidak memperhatikan performance. Sebagai contoh, pada kasus layar kursus tadi kita bisa memilih untuk menghilangkan nama trainer dan fokus ke atribute kursus seperti Nama, Detail, Durasi, dll. Karena pada umumnya orang akan tertarik dengan kursus bukan karena trainernya (fokus terhadap subjek Kursus). Detail Trainer bisa ditampilkan pada layar "Detail Kursus" dimana bisa saja selain trainer ditampilkan siapa saja peserta kursus tadi. TIPS: Sebelum kamu menggunakan tipe relasi XToMany pikir dulu apakah bisa diganti dengan XToOne?
menurut saya, query sekecil apapun pantang dimasukan dalam loop dengan kompleksitas n. maybe dalam bbrp kasus tertentu masih diperbolehkan jika jumlah loopnya fix, walaupun belum pernah dapat problem tersebut.
wah, bagus ini... ijin share ya bang eko... saya sendiri ga tau kalau nama nya ini masalah N+1.. tapi pernah ngalamin hal ini saat masih pake query manual... setelah make laravel, saya belajar banyak soal query (in query, exists query, dll). saya juga jadi lebih perhatian sama query sebenarnya, termasuk optimalin join, entah pake inner join, outer join, left right join... ternyata banyak banget. dan selain tantangan, optimasi query itu menarik banget. makasih bang ilmunya
Mantap pak, terimakasih banyak, jadi paham cara menjelaskan dan penamaannya. Di kerjaan saya (SAP - ABAP) yang hampir full query SQL, join & in query menjadi hal yang harus diberikan perhatian khusus 😂
tergantung jumlah data dan apakah aplikasinya concern ke memory usage atau tidak. Kalau join akan cenderung consume memory lebih banyak karena ada banyak data yg harus di hold di memory, padahal datanya sama hanya berulang.
Teknik kedua akan lebih mudah diambil kalau output nya menggunakan resolver seperti gql atau digunakan untuk paging by parent. Meskipun paging by parent akan lebih mudah pakai sub query sih
pak mau tanya, di laravel controller yang saya miliki itu full query builder apakah berpengaruh untuk kecepatan aplikasi? dan data nya merupakan inject dari db, apakah ada solusi lain?
kalo masih 1 db saya selalu usahakan untuk pake join, tp kalo sudah mainan microservice trus butuh data reference dari service lain, ya pake yg ke 2, jadi nanti unique ids itu yg di kirim ke service terkait, nanti service terkait handle pakai where in apakah saya masih dijalan yg benar? wkwkw
kalau pake function relasi di laravel kayak belongsto, hasmany dll itu juga ada kemungkinan kena n+1? apa mending pakai join aja buat dapat data relasi antar tabel??
sebenernya N+1 itu bukan masalah spesifik ke masalah query sih, tapi penulisan algoritma secara dasar, gw cukup kaget karena kayanya jarang banget edukator indonesia yang ngebahas 'Big O' padahal ini fundamental sekali terhadap performa algoritma yang kita tulis, mungkin ini hanya anecdotal evidence aja ya tapi saya lihat jawaban" technical interview di perusahaan" yang saya pernah kerja itu rata" masih bayak yang make algoritma O(n log n) atau bahkann O(n^2) yang mana atau algoritma brute force (yang penting fuctionya Jalan)
Itu knp sy ngk pernah mau pkai orm, ribet, logikanya ngk dapet. Kyk ngerjain sesuatu tp ngk pk logika. Jauh lebih nyaman pk sql query, lsg to the point😊
@@Like_crafthomade ORM lebih cocok buat menerapkan clean code jadi biar kodenya bersih dan mudah di maintance tapi wajib memahami sql dulu sebelum query
Saya justru kebalikan lebih suka ORM bait ga cape ketik2 query wkwkwk apalagi klw ganti database kadang Ada yg ga work klw ORM biasanya akan Ada update dri pengembangnya.. tpi kadang Masih pake juga native query klw udah komplek.
@@Like_crafthomade Sebenarnya sih tergantung. Yaa, mungkin bisa berbeda sih. Ane pakai Eloquent malah lebih nyaman. Masalah N+1 query tinggal pakai "with()", atur relation di model, dan kelar. Intinya sih, ribet karena belum biasa. Yaa, ane justru belum biasa sql langsung, makanya ane pakai Eloquent.
Hmmmm baru tau ternyata join dkk ngefix problem n+1 😅 secara gk sadar krn emng sy gk tau n+1, tp emng aneh sih ngeloop sql, gk pernah kepikiran walaupun kepikir pun pasti lnsg tau bikin masalah, masih belum pernah ketemu org yg ngeloop sql gitu buat narik data 😂
@@saluran1733 saya pakai Laravel dan pas mau ambil data relasi antar tabel pakai belongsto dll, itu rawan kena n+1 pas mau nampilin data nya di looping
waduh" bang tolong di bantu, abang kan educator nih, mungkin ketika bikin video edukasi tentang query di banntu me wanti" muritnya bahwa jangan pernah query SELECT * apa pun situasinya. Karena membuat good habits itu lebih mudah dari pada menyembuhkan bad habits, hanya query kolom yang kalian butuh ya teman" apalagi kalo sudah main Join table, karena bukan hanya berpengaruh terhadap performa query teman" karena kemungkinan banyak data yang redundant, tapi juga tidak baik untuk keamanan sistem karena bisa saja data sensitif ikut ter query, meskipun table isinya cuma 2=3 kolom dan datanya tidak senitif tetap query nama kolomnya langsung ya, untuk menimbulkan kebiasaan yang baik.
mantap pak, smlm saya baru belajar laravel eloquent, trs disebutin masalah N+1 query, hri ini lgsng ada video pembahasannya, untung sblm-sblmnya saya lgsng join, jadi ga pernah kena trouble ini😂
Sekedar berbagi. Kalo dalam ORM N+1 itu fitur, kalo gak pake ORM itu masalah skill SQL.
Fitur ORM ini jadi problem kalo salah pakenya. Biasa terjadi kalo pake relasi tipe XToMany yang sebenernya bisa diganti dengan Unidirectional XToOne. Jika memakai tipe relasi XToOne, secara default ORM akan otomatis pake JOIN query.
Di sisi lain seringkali requirements itu tidak memperhatikan performance.
Sebagai contoh, pada kasus layar kursus tadi kita bisa memilih untuk menghilangkan nama trainer dan fokus ke atribute kursus seperti Nama, Detail, Durasi, dll. Karena pada umumnya orang akan tertarik dengan kursus bukan karena trainernya (fokus terhadap subjek Kursus). Detail Trainer bisa ditampilkan pada layar "Detail Kursus" dimana bisa saja selain trainer ditampilkan siapa saja peserta kursus tadi.
TIPS: Sebelum kamu menggunakan tipe relasi XToMany pikir dulu apakah bisa diganti dengan XToOne?
udah di rational database kok gak di operasio join , malah bikin 2 query
menurut saya, query sekecil apapun pantang dimasukan dalam loop dengan kompleksitas n. maybe dalam bbrp kasus tertentu masih diperbolehkan jika jumlah loopnya fix, walaupun belum pernah dapat problem tersebut.
Karena query ke db itu mahal guys, jadi sebisa mukin minimalisir query ke db, cari cara yg lebih efisien dan efektif
wah, bagus ini... ijin share ya bang eko...
saya sendiri ga tau kalau nama nya ini masalah N+1.. tapi pernah ngalamin hal ini saat masih pake query manual...
setelah make laravel, saya belajar banyak soal query (in query, exists query, dll). saya juga jadi lebih perhatian sama query sebenarnya, termasuk optimalin join, entah pake inner join, outer join, left right join... ternyata banyak banget. dan selain tantangan, optimasi query itu menarik banget.
makasih bang ilmunya
Yang jadi masalah begitu ditanya terms ginian ternyata ga tau namany, lantas dianggap interviewer ga bisa solve, padahal sebenarnya bisa
Alhamdulillah dapat manfaat setelah scroll Facebook, makasih pak Eko
pake join ... sekali jalan aja query nya.. 😁
Mantap pak, terimakasih banyak, jadi paham cara menjelaskan dan penamaannya. Di kerjaan saya (SAP - ABAP) yang hampir full query SQL, join & in query menjadi hal yang harus diberikan perhatian khusus 😂
@@babygold_id gimana biar bisa kerja di bidang SAP ya bang?
@@babygold_id info pak web atau kursus buat belajar SAP ABAP?🙏
Keren Pak, pegang apa kalau boleh tahu Pak?
saya lebih prefer join table biar satu round trip request ke database.
tergantung jumlah data dan apakah aplikasinya concern ke memory usage atau tidak.
Kalau join akan cenderung consume memory lebih banyak karena ada banyak data yg harus di hold di memory, padahal datanya sama hanya berulang.
Teknik kedua akan lebih mudah diambil kalau output nya menggunakan resolver seperti gql atau digunakan untuk paging by parent. Meskipun paging by parent akan lebih mudah pakai sub query sih
pak mau tanya, di laravel controller yang saya miliki itu full query builder apakah berpengaruh untuk kecepatan aplikasi? dan data nya merupakan inject dari db, apakah ada solusi lain?
Punten kang, amatiran pengen tanya, gimana kalo ditable itu dibikin colom trainers relasi ke table lain??, jadi querynya ke table courses aja
Baru tau dan untung saja selalu pake join. Tinggal coba2 nerapin in query aja sih ini.
Mending pake cte querynya, kalo ada yg duplikat tinggal pakai cara distinct atau row number
Mantap pak tapi bagaimana dengan case jika mengharuskan join lebih dari 5 tabel?
Buat video bahas database migration. Very critical
Mantap pak, materinya daging semua
Nice
udah di rational database kok gak di operasio join malah bikin 2 query
Kalau N+1 insert gimana? Apakah jadi malalah?
Sy ada kendala dalam merekap data cuti di kahir tahun
kalo masih 1 db saya selalu usahakan untuk pake join, tp kalo sudah mainan microservice trus butuh data reference dari service lain, ya pake yg ke 2, jadi nanti unique ids itu yg di kirim ke service terkait, nanti service terkait handle pakai where in
apakah saya masih dijalan yg benar? wkwkw
Kalau di laravel pakai "with".
Kalau pengalaman saya, kalau tabel joinnya jarang/tidak berubah, contoh: agama, itu querynya saya cache.
mau tanya kang, maksudnya tabel joinnya jarang teh berarti jarang di join dengan tabel lain atau jarang di insert karna perubahan datanya sedikit?
@edricgalentino contoh tabel agama. Isinya kan ya cuma2 itu aja, datanya mungkin berubah beberapa tahun sekali.
kalau pake function relasi di laravel kayak belongsto, hasmany dll itu juga ada kemungkinan kena n+1? apa mending pakai join aja buat dapat data relasi antar tabel??
@@SalmanAlfarisi-iy4jt pakai with di awal. Ntar jadinya di query pakai where In.
jangan lupa bulk insert, sama bulk delete harus di manfaatkan
suwun mas eko
In query bikin kebanyakan for di aplikasi gak pak eko?
Eager loading dan join mungkin bisa jadi jawabannya?
nguwantuk poll aku pak
bagaimana jika kita pakai sub Query ? apakah itu sama saja atau lebih baik ?
Lebih suka pake teknik CTE kalau untuk query yang butuh join ke beberapa table
Strukturnya Inquery tapi pake join sama subquery
waduh ilmu mahal nih, dulu saya juga sering bikin kaya gini dan biasanya saya bikin view sih kang. ternyata ini namanya wkwkwkwk
sebenernya N+1 itu bukan masalah spesifik ke masalah query sih, tapi penulisan algoritma secara dasar, gw cukup kaget karena kayanya jarang banget edukator indonesia yang ngebahas 'Big O'
padahal ini fundamental sekali terhadap performa algoritma yang kita tulis, mungkin ini hanya anecdotal evidence aja ya tapi saya lihat jawaban" technical interview di perusahaan" yang saya pernah kerja itu rata" masih bayak yang make algoritma O(n log n) atau bahkann O(n^2) yang mana atau algoritma brute force (yang penting fuctionya Jalan)
pakai limit 1 gimana pak?
Saya pake left join kak biasanya
Kalo di go prepare dlu brrti ?
pake gorm jg bisa, pake fungsi preload atau joins.. yg preload itu mirip solusi ke-2 yg pake IN query
Itu knp sy ngk pernah mau pkai orm, ribet, logikanya ngk dapet. Kyk ngerjain sesuatu tp ngk pk logika.
Jauh lebih nyaman pk sql query, lsg to the point😊
@@Like_crafthomade ORM lebih cocok buat menerapkan clean code jadi biar kodenya bersih dan mudah di maintance tapi wajib memahami sql dulu sebelum query
Saya justru kebalikan lebih suka ORM bait ga cape ketik2 query wkwkwk apalagi klw ganti database kadang Ada yg ga work klw ORM biasanya akan Ada update dri pengembangnya.. tpi kadang Masih pake juga native query klw udah komplek.
yang pake laravel eloquent relationships jangan lupa eager load
Eloquent bikin pusing...hehe. enakan sql lsg, setuju ngk?😊
@@Like_crafthomade kalau setauku sql query malah gak di sarankan karna rawan, dia query mentah ke sql langsung ga kata eloquent
@@fazlmausoofh6668 terus juga udah otomatis mencegah sql injection juga seingetku, kalau sql biasa ada cara sendiri
@@Like_crafthomade Sebenarnya sih tergantung. Yaa, mungkin bisa berbeda sih.
Ane pakai Eloquent malah lebih nyaman. Masalah N+1 query tinggal pakai "with()", atur relation di model, dan kelar.
Intinya sih, ribet karena belum biasa. Yaa, ane justru belum biasa sql langsung, makanya ane pakai Eloquent.
@@rainfog_mzb
Kl cuma update atau select table yg gampang2 sih, masih oke. Tp kl select data yg table byk dan kusut, sy nyerah pk eloquent. Ngk sanggup😅
terbaik
10:43
kalau saya ditanya n+1, waduh maaf sekali saya sudah melupakannya karena ada prisma 😅
Bang nanya dong, kalo in query isinya ada ratusan ribu id atau jutaan bisa jdi problem gk? Makasih...
query simple juga kalo narik raturan ribu atau jutaan data, ya masalah
done
Kalo pake Store Procedure gimana pak?
SP mah cmn fungsi yang isinya query jg, biar lebih mudah manggilnya di codenya dibanding harus ngetik select berkali" dan juga mudah di maintenance.
@@sbtsnseth SP nya ditambahkan cursor dan di return json atau string dibuat 1 row makin lebih cepat lagi.
@@herufredi9696 terima kasih atas masukannya pak, kalo boleh tau ada refrensinya kayak gmntuh bang biar bisa di pelajari lgi.
Hmmmm baru tau ternyata join dkk ngefix problem n+1 😅 secara gk sadar krn emng sy gk tau n+1, tp emng aneh sih ngeloop sql, gk pernah kepikiran walaupun kepikir pun pasti lnsg tau bikin masalah, masih belum pernah ketemu org yg ngeloop sql gitu buat narik data 😂
Ada biasanya bersyarat (if) jadi dilakukan pemeriksaan dulu baru yg memenuhi syarat diquery lagi
@@saluran1733 saya pakai Laravel dan pas mau ambil data relasi antar tabel pakai belongsto dll, itu rawan kena n+1 pas mau nampilin data nya di looping
Siapa yang pake belongAs ? 😅
kwkwkwkw ini yang biasa gua lakuin
Kalo relasi one-to-one, prefer yg JOIN query.. kalo one-to-many atau many-to-many baru yg IN query kalo saya 😅
Halah istilah kekinian tho, nek saya ngandalin tableview, kalo berat ya materialized view.