good explanations as always, sebagai pengguna ORM saya jg mau share bbrp advantage menggunakan orm dibanding raw query: 1. universal : kode jadi lebih seragam antara logic business dan query 2. automatic optimization: cache, pooling dll 3. rapid development 4. migration & versioning 5. extra tools, contoh saya pengguna django orm dan sqlalchemy, sangat mudah untuk switch db server (mysql, postgre, mongo, cassandra), sharding scr effortless, tinggal ganti config, selesai. handle error ( integrity, validation) pun lebih mudah karena exception udah built in
kalo di python orm memang berguna buat bantu coding. Tp consnya jauh lebih lambat dibanding raw query. Beda dng nodejs, ormnya ya gitu, query builder jatohnya. Klw buat aplikasi web pake orm masih ga keliatan lambat klw concurrent request nya masih dikit. Akan lebih keliatan ketika proses query bulk, baru keliatan lemot. Ya di pilah aja peruntukannya.
Saya agak kesusahan pas nge get data dari database. Soalnya biasanya quey nya nested. Jadi di dalam select ada select nya. Tapi pas yang edit sama delete atau lainnya enak banget. Hihihi
untuk query2 basic ORM sangat membantu, tapi untuk beberapa query yg advance, raw SQL perlu untuk dicoba. ORM mempermudah kerjaan, tp basic SQL harus tetap dikuasai, karena mau gak mau pasti suatu saat butuh untuk run raw SQL.
nice share... kalau saya pake ORM kalau query sql nya ga terlalu complex. tapi klo projectnya perkiraan bakal banyak query complex (contoh ERP), saya prefer call pake stored procedure, alasannya biar lebih fleksibel nge query di DB, easy to read, dan mudah di maintenance, misal pake CTE, subquery, dan function/expression bawaan databasenya.
Kalo dari pengalaman saya pakai ORM Node JS kayak sequelize atau TypeORM itu kalo query atau execution simple kayak insert doang atau query select biasa itu ga gitu kerasa. - ORM bakal kerasa kalo misalkan udah pake JOIN yang bener2 dalem atau panjang karena querynya bener2 belibet banget dibanding kalo kita buat JOIN sendiri sesuai kebutuhan (kayak yg mas Eko jelasin). - Kedua karena ORM ada fungsi mapping ke objectnya, pas query kalau data yang di ambil banyak banget sampe ribuan. Itu delaynya sangat berasa. Jadi lamanya bukan di query DB tp lamanya kena di fungsi mappingnya. Alternatifnya bisa di query tapi hasilnya dibuat RAW jadi field di object hasilnya nyesuain kolom database dan ga ngejalanin mappingnya. Atau ya raw query. Tapi emang ORM itu sangat membuat programmer produktif sih tapi emang musti peka kapan jangan dipake biar performancenya ga kena dampak yg parah
@@dontama kan mereka pake pagination atau dibuat per halaman, jadi ya yg dibalikin sama databasenya cuman mungkin 10-20 hasil aja yg dibutuhin user. nanti kalo usernya ke halaman selanjutnya ya dikasih lagi halaman berikutnya. Kalo pake ORM apa ngga sih gatau, tapi kemungkinan besar sih ya gapake ORM karena querynya pasti kompleks banget, dan mungkin databasenya udh NoSQL kayak mongoDB, elastic, dll. Kalo dibalikin semua data google mah, pake ORM atau ngga server mereka bisa meledak kali ngeproses jutaan request dan hasil query db tiap detik
@@RinggaGustavino ya gak semua data juga yang dibalikin, dan gak mungkin juga. point utama nya adalah proses filter datanya. pake gak pake ORM, alasannya sama seperti kita develop aplikasi mau native atau pake framework. lama tidaknya query biasa atau ORM sebenarnya bukan disini masalahnya,, tapi masalah sebenarnya di database itu sendiri. mau pake query biasa tapi tidak di-index dll. ketika datanya udah banyak juga bakal lama juga hasilnya.
@@dontama betul saya setuju. Ya poin saya jg lebih ke hasil querynya ORM biasanya musti di mapping dulu ke entity si ORM makanya jauh lebih berasa untuk data yang hasil querynya ribuan. Kalo searching di ribuan data mah ya pasti tergantung query, indexing dan skema DBnya saya setuju. Makanya saya ngasih tau mapping ini bisa di bypass pakai option RAW dari 2 ORM yg saya pake itu.
Ambil yg bagus dari orm aja ges. Orm biasanya punya mekanisme pooling yg bagus. Bisa dipakai buat migration. Kalau mau plain query toh juga tinggal comot cursor yg di expose si orm. Db access lifecycle juga penting lho kapan pool mau di initiate / release
Pengalaman saya di JS pake ORM enak" aja (typeORM, Prisma) query yg dihasilkan jelas (di docs nya udah tertera), paging dan relasi juga bisa di kontrol dengan mudah
dengan ORM sudah tidak perlu memikirkan bagaimana membuat SQL atau querynya. selain itu ada beberapa ORM yang bisa men-generate bentuk raw SQLnya. ketika kita bingung membuat query yang kompleks ternyata dengan ORM begitu simple, kita bisa mempelajari query yang dibuat oleh ORM. dan dengan ORM ketika gonta ganti engine database, gak perlu repot2 ubah codingan query. dan lagi kita bisa belajar query rawnya, karena ORM bisa menyesuaikan bentuk query sesuai database engine yang kita gunakan.
untuk crud dan select yang tidak terlalu rumit orm masih worth it. tapi untuk beberapa case query yg kompleks seperti membuat report yg biasanya banyak kondisi dan join ke banyak table, raw query jadi lebih optimal dan lebih mudah untuk developernya itu sendiri.
Setuju banget dengan penjelasanya, sesuaikan kondisi.. contoh : 1. Misal Pengecekan data input baru agar tidak duplikat yang mana data lama ada puluhan ribu ato lebih, nah ini pake SQL langsung biar lebih cepet prosessnya seleksi nya. 2. Kalo datanya masih belum terlalu banyak harusnya masih aman pake ORM.
itu semua tergantung jumlah request. kalau request 1000/ detik. ORM udah gak cocok, misalnya selisih tiap request 1ms, terjadi delay 1 detik itu terasa.
salah sih kalo bilang selisih tiap request di akumulasi, misal kalo sql butuh 1 ms, orm butuh 3 ms.. jika ada 1000 request ya waktunya tetap 1 dan 3 tadi.. dari sisi aplikasi pasti sudah ada concurrency request dan didatabase juga terdapat concurrency connection. cepat atau tidaknya query dipengaruhi juga dari sisi indexing, partition table, master-slave dan lainnya. kalo jumlah data masih dibawah 1juta row waktu proses tidak signifikan.
ORM enak kalau cuma CRUD, simple JOIN, atau simple query saja.. . kalau query nya kompleks akan susah untuk implementasi dan maintenance nya. . berdasarkan pengalaman saya lebih enak pake stored procedure, jadi bahasa pemrograman tinggal call aja, jadi program lebih simple dan gampang maintenance nya..
Sedikit sharing kalo case data udah sampe ratusan ribu kalo pake ORM tidak mampu meload data tersebut. Jadi bener banget kalo query harus dikuasi dulu. 🙌
dulu semenjak pake laravel selalu pakai ORM eloquent, pas disuruh implement raw query ga ngerti gimana caranya wkwk. jadi kesimpulannya harus ngerti dulu gimana cara raw query baru coba nyentuh ORM, berasa banget keliatannya
nahh ini adalah contoh dari perkataan pak Echo tadi heheheh mantaps Bang intinya semangats terus belajar dan mengenal apapun itu ilmu dalam dunia Software engginer ;)
why not both?kalo gw pake query kalo input /proseslebih dari 10k -1m data dalam 1 tombol ngga pake orm, tapi kalo dibawah itu pake orm aja udh aman. khusus reporting kalo bentuknya rekap pake query, tapi kalo tampilan single report pake orm aja. ngga bakal masalah dalam 1 aplikasi terdapat orm dan query.
{ "id": 1, "name": "John", "products": ["Product A", "Product B"] } kalo pake express js dan mysql tanpa orm. cara buat format kayak gini gimana ya supaya ada array products disana.
Malah terbalik. Orm enak dipakai kalo size aplikasinya kecil - sedang. Kalo besar - sangat besar lebih baik dikombinasikan dengan raw sql dan stored procedure. Ato lebih bagus lagi kalo cuman pake raw sql dan stored procedure aja.
terbalik... justru orm enak dipake kalo db schema nya sederhana. kalo sudah complex, high volume, harus pake raw sql & stored procedure ya. jangan pernah pake orm.
ini adalah jawaban palin adem yang selama ini saya dengar :) dimana di grup2 telegram pada berdebat panas adu mekanik , perang dunia ke 5 yang ini kekeh paling mantaps No ORM yang satunya Team Pake ORM , dua kubu saling adu kuat wkwkwk .. Kalo Pak eko jawab dengan mengambil kedua pandangan ORM Dan No ORM di lihat sudut pandang nya .. .Mantaps Pak Echo ( Framework Go lang ) . heheheheheh
Kalo udah level enterprise pasti pake ORM lah, deadline ketat. Tapi ya tetep untuk fx yg spesifik tetep harus dg raw Query. Kecuali elu develop ORM sendiri , hahahaha
Mas Eko khusus bagian "lazy", ada pertanyaan gini bang? Misal pas findById di tabel A, tapi saya butuh beberapa data dari tabel B, apakah bisa diprovide via ORM Mas? Soalnya klo saya liat ketika dia manggil dari table B dia akan manggil semua kolom, sedangkan saya pengennya beberapa field aja yang dipanggil. Kalo lazy itukan sebuah mekanisme yang dimana data dari table B akan diquery klo emang dipanggil di via ORMnya, cuman giamna bang klo misal kita pengen ngambil beberapa field aja?
@@davidstephen7070 ohh itu ngefeknya di unit testing ya? Jadi untuk memastikan data yang dibalikin harus instance dari suatu object, kalo pas ditest ternyata ada data yang salah langsung nge throw error begitu?
ga tau kenapa kalau saya lebih gampang pake raw query, apalagi kalau table relationnya banyak. Kalau pake orm enakan pake orm yg bisa nulis raw query juga. Jadi kalau untuk read data pake raw sql, untuk write kayak create update lebih gampang pake orm.
