Pros dan Cons Menggunakan ORM

[@ttaqinmu707]

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

[@dev_rupi]

Django enak asli :)

[@muharief3885]

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.

[@bimzzz8612]

@@muharief3885 brrti ga selalu hrus pake ORM ya?

[@oji.satriani]

Pengalaman awal2 dulu beralih dari sql manual ke ORM, cuma bisa komentar "Lah kok enak" 😅

[@rainhardvidiansyah6968]

Awalnya coba-coba, lha kok enak 😂😃🙏

[@kriskurniawan2561]

akhirnya kterusan dan ketagihan...

[@iseplutpinur]

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

[@youraccountissuspended]

@@kriskurniawan2561 besoknya saya pun kembali datang ke rumah tante..

[@manggalawiryawan3242]

saya pake dua2nya, depend on case kalo saya...utk query simple pake orm aja, kalo sudah query yg ribet baru pake raw query

[@darielpratama647]

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.

[@fvze1]

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.

[@mocharasa17]

Senior pake ORM no prob. Tapi jangan sampe anak junior di biasain pake ORM 😁. Always use RAW SQL untuk anak junior

[@dya9981]

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

[@RinggaGustavino]

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

[@iseplutpinur]

Iya mas pas pertama pake ORM kesulitan banget soalnya biasanya. Buat quey nested. pas ber urusan sama edit delete jadi gampang banget.

[@dontama]

berarti sekelas google yang datanya udah banyak, mereka gak make ORM sama sekali dong?

[@RinggaGustavino]

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

[@dontama]

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

[@RinggaGustavino]

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

[@z-aru]

Saya lebih prefer query builder

[@falahisnan4582]

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

[@dontama]

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.

[@badarnento3000]

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.

[@naufal_farras]

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.

[@davidstephen7070]

itu semua tergantung jumlah request. kalau request 1000/ detik. ORM udah gak cocok, misalnya selisih tiap request 1ms, terjadi delay 1 detik itu terasa.

[@dontama]

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.

[@deniswarsidin9402]

Mas blibli di video aja ngomong sampe skrg masih pake ORM kok. XD. Hajar aja ORM dah. Worst case ya padukan ORM sama Raw.

[@naranyala_dev]

Thanks bang atas insight-nya, masih banyak fundamental yang perlu dipelajari ternyata

[@bimadeantoro22]

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

[@IndraPrasetya154]

Penjelasan yang lengkap sekali, mantap. Sehat sehat selalu Kang Eko

[@foobarbazz]

Sangat masuk. terima kasih pak eko.

[@mrizkimaulidan]

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

[@ramdoni3935]

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

[@ronierone]

I think my mentor must be known this. Nice share pak

[@aryajaya6685]

Tutorial golang orm dong pak eko, temen2 pada make orm merasa beda sendiri pak

[@afcreative-id]

Totally agree mas, kadang pakai plain sql kalo pakai formula dan pakai pgsql

[@ariumboroseno]

Pak eko, request pak content terkait buku rekomendasi untuk senior developer

[@ProgrammerZamanNow]

masukin ke github qna, biar gak lupa

[@ariumboroseno]

@@ProgrammerZamanNow siap pak eko

[@nurdinyusuf8876]

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.

[@belajarwebmedan]

Mantap penjelasannya.. terima kasih pak Eko.

[@wahyusantoso7419]

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

[@iopyrb]

RoR active record ❤

[@codeyzx]

Keren pak sangat berguna, terimakasih

[@zekayara9320]

ORM sangat membantu banget ketika relational table sudah komplek Bayangin relational table nya komplek pake query , beh ndak kebayang deh

[@awikwok212]

ga kebalik ini? bayangin bikin report pake ORM mantap

[@123tgh]

query builder lebih baik kalo buat banyak relasi utk report.

[@zekayara9320]

@@awikwok212 LAZY COLLECTION ?

[@rayvid7979]

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.

[@rayvid7979]

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.

[@akudia9136]

Bener banget nih mas eko, enakan pake ORM daripada sql langsung.

[@gustiarya7009]

pakai orm memang enak, tapi klo query sudah compleks banget lebih prefer ke sql sih

[@nolep5555]

{ "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.

[@rayvid7979]

lebih suka pake cara tradisional. jdbc + sql/stored procedure. kenceng abiss...

[@fajarislami581]

klo di gorm juga enak, klo konek ke master slave, gampang

[@zhakimel]

alternative ORM bagusnya mapper kayak iBatis sih

[@mengisi]

Alat dibuat untuk kegunaan masing-masing. Stop bandingkan tools. Tinggal pake aja kok kita ini., :D

[@wisnupw]

Om Eko. Reflection ring lightnya cukup eye catching. 😅

[@ProgrammerZamanNow]

mungkin karena saya nya emang ganteng #eh

[@rickydamarsaputra8033]

@@ProgrammerZamanNow bisa2 aja pak eko ini wkwkk 🤣🤣

[@rainhardvidiansyah6968]

Jpa hibernate ❤❤❤

[@adultzbgtz]

Punten bang, orm dengan query lngsung jauh bedanya bang, bisa 1 bnding 3 detik klo datanya besar, dan query nya bnyak join dan where clause🙏

[@GrezArifiyan]

nah, untuk dev sebetulnya gak masalah, tapi kalo datanya udah besar sepertinya lebih baik menggunakan sql.

[@deniswarsidin9402]

Wah pinter bgt ini. Di branch staging kodenya pake ORM, di branch prod pake raw. Ajaran sapa pak?

[@mikha2880]

​@@deniswarsidin9402 hahahhaa mungkin yg di maksud si bapak untuk skala ukuran projek 😆 atau belum sruput ☕

[@rdimas7445]

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?

[@DandiFermeko]

Kalau di laravel bisa di define field2 yg mau di select, misal User::with('user_profiles:user_id,phone,birthdate')->first();

[@rdimas7445]

@@DandiFermeko makasi Mas jawabannya. Saya belum nemu kalo di Java wkwk

[@deniswarsidin9402]

Gorm golang juga bisa omit select. Harusnya setiap ORM provide feature ini.

[@unangrioda]

Bisa di setiap orm

[@m5a1stuart83]

Semua ORM pasti punya kok, mgkn elu blm explore aja, sebagai pengguna Mormon dan EF/EFCore.

[@faridrizkywijaya2702]

pak nanti di kelas laravel dibahas tuntas ga mengenai ORM

[@ProgrammerZamanNow]

ada pembahasan soal Laravel Eloquent

[@fhlazdrwals]

kalo di golang ORM yang recommended apa ya mas eko ?

[@dispinser548]

Linq 👍💯

[@mirzaputra64]

nanya mas,kalo gak pake orm kenapa ya balikannya bentuknya harus instance of object? padahal dari resultset sudah bisa diolah langsung?

[@davidstephen7070]

type checking. prinsip bahasa statik. semua harus type check. biar apa? biar test unit bisa di prediksi.

[@mirzaputra64]

@@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?

[@dndhndn]

@@mirzaputra64 data yang salah juga di test.

[@rezihardiansyah1082]

di sb ada object mapping named mybatis

[@ZAcharyIndy]

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

[@ramdoni3935]

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

[@nomoretaqiyah]

Ditunggu tutor orm nya mas 😀

[@karuniaawalramadhan9627]

ngedit kolom nambah kolom, auto ngubah kode program

[@nanto-x]

bisa pake db driver

[@muhammadfitrahramadhan6487]

kalo pake ORM masih perlu layer repository gak ya, sejak ORM kan sudah mengabstraksi tiap-tiap table

[@kiizuha]

Bisa pake 4 layer clean arch, bisa gak pake juga. Tapi lebih baik pake sih

[@ytef9398]

orm & active record itu sama kah?

[@ainunabdullah2140]

pak eko, aplikasi buat coret2nya namanya apa pak hehe ?

[@arfankurnianto9781]

Saya pakai orm cuma buat manipulasi

[@mindyaus3429]

Kekmana itu mas eko klok mau buat bahasa pemrograman sendiri

[@davidstephen7070]

belajar bahasa assembly. terus belajar read and write file. dilanjut regex. tujuan regex untuk parse code lalu di ubah ke assembly.

[@oktapascal4348]

Pake ORM itu berarti relasi tablenya juga harus bener ya ?

[@unangrioda]

Ya, benerin dlu relasinya

[@munawirulhadi2864]

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.

[@masmmaw]

ORM itu apa ?

[@danilsyah4108]

Object Relational Mapping

[@akbarmaulana6390]

mongodb engga pakai orm haha hihi

[@CakRama01]

Ada orm nya juga, namanya mongoose

[@bagashananto4672]

mongoose?

[@davidstephen7070]

mongodb defaultnya sudah orm. cuman gak ada schema.

[@fajarislami581]

klo mongodb namanya odm

[@lukmanharun890]

Main aggregate mantap