Apakah ORM masih merupakan anti-pattern?

 (github.com/getlago)
7 poin oleh GN⁺ 2023-06-28 | 1 komentar | Bagikan ke WhatsApp
  • ORM sering dikritik sebagai “mainan untuk startup”, tetapi pokok persoalan sebenarnya lebih dekat pada cara penggunaan yang keliru daripada ORM itu sendiri
  • Grafik objek dan tabel relasional adalah dua model yang berbeda sehingga muncul ketidakselarasan paradigma, tetapi ini saja tidak cukup untuk menyebut ORM sebagai anti-pattern
  • Perdebatan tentang pelanggaran SRP dan SOC tetap valid, namun ORM sejak awal adalah abstraksi yang menghubungkan dua model data, sehingga sulit menilainya hanya dari ada tidaknya pelanggaran prinsip
  • Masalah performa lebih sering muncul dari pola merangkai data di logika bahasa host daripada dari ORM, dan bisa dikurangi dengan fitur mirip SQL milik ORM
  • Alasan utama Lago mengganti kueri Active Record ke SQL mentah bukanlah kecepatan melainkan visibilitas dan debugging, dan untuk kueri besar, beralih ke SQL mentah bisa lebih menguntungkan secara praktis

Sikap dasar dalam melihat kritik terhadap ORM

  • ORM sering diserang sebagai “anti-pattern”, tetapi kesimpulan bahwa ORM itu sendiri buruk cenderung berlebihan
  • Seperti abstraksi lain, ORM juga tidak sempurna, dan dapat menimbulkan sebagian hilangnya visibilitas serta biaya performa
  • Lago mengalami masalah saat bergantung pada Active Record, ORM milik Ruby on Rails, dan dari situ meninjau kembali cara mereka bergantung pada ORM
  • Kesimpulannya bukan bahwa ORM harus dibuang, melainkan bahwa ORM perlu diperlakukan sebagai abstraksi dengan kelebihan dan kekurangan yang jelas

Perbedaan antara model objek dan database relasional

  • Objek yang ditangani ORM lebih dekat ke graf berarah yang menunjuk ke node lain
  • Tabel database relasional lebih dekat ke graf tak berarah di mana data terhubung dua arah melalui kunci bersama
  • ORM bisa meniru graf tak berarah, tetapi konfigurasi dan perilakunya tidak selalu sederhana
    • Objek User bisa saja tidak memiliki array Posts
    • Entitas dalam array Posts bisa saja tidak memiliki referensi balik ke objek User yang sama
    • Sekalipun ada referensi balik, objeknya bisa saja bukan objek yang sama melainkan salinannya
  • Misalnya, ORM dapat mengembalikan posting milik pengguna sebagai array, tetapi setiap posting mungkin tidak menyertakan referensi balik pengguna sebagai penulisnya
  • Ketidakselarasan ini adalah kritik akademis yang baik terhadap ORM, tetapi dalam operasi nyata masalah yang lebih besar biasanya muncul dari cara pemakaian yang spesifik

Perdebatan SRP dan SOC

  • Single Responsibility Principle (SRP)

    • ORM dikritik karena melanggar Single Responsibility Principle (SRP)
    • Karena satu kelas atau lapisan bisa dibuat menangani beberapa peran sekaligus
      • menjalankan database dan transaksi
      • merepresentasikan record
      • mendefinisikan relasi
      • membuat dan menjalankan migrasi
    • Namun tujuan ORM sendiri memang untuk menghubungkan dua paradigma data yang berbeda, sehingga sulit menolak ORM hanya berdasarkan sebagian pelanggaran prinsip

  • Separation of Concerns (SOC)

    • ORM juga dapat mengaburkan prinsip Separation of Concerns (SOC)
    • SOC adalah prinsip bahwa komponen infrastruktur seharusnya hanya memiliki satu concern
    • Karena ORM memindahkan pengelolaan database ke sisi backend, ada ruang untuk melihatnya sebagai pelanggaran SOC
    • Namun saat ini komponen infrastruktur dan pola pengkodean sering menggabungkan beberapa peran demi performa, latensi, dan kerapian kode
      • agregator CPU di dalam database OLAP
      • backend-frontend edge
      • monorepo

Masalah performa lebih sering muncul dari cara penggunaan daripada dari ORM itu sendiri

  • Kritik bahwa ORM selalu tidak efisien pada umumnya keliru
  • Banyak ORM dapat bekerja jauh lebih efisien daripada yang dibayangkan pengembang
  • Masalahnya adalah ORM memudahkan perangkai data dilakukan di logika bahasa host seperti JavaScript atau Ruby
  • Dalam contoh TypeORM, pola buruknya adalah mengambil penulis dari perusahaan tertentu terlebih dahulu, lalu mengambil ulang posting untuk setiap penulis, dan menyimpan setiap posting secara terpisah
  • Cara yang lebih baik adalah menyusun satu kueri update dengan createQueryBuilder() milik TypeORM
  • Dalam refaktorisasi SQL billing Lago juga tidak ada perbedaan performa antara versi Active Record dan versi SQL mentah
    • Karena fitur penggabungan data milik Active Record sudah digunakan cukup banyak, kueri lama sebenarnya sudah dalam keadaan optimal
    • Penulisan ulang ke SQL mentah lebih dekat pada upaya mendapatkan visibilitas daripada peningkatan performa

Kapan ORM benar-benar bisa menjadi lambat

  • ORM tidak selalu seefisien SQL mentah, dan dalam beberapa situasi bisa sangat tidak efisien
  • Masalah pertama adalah ORM dapat menimbulkan overhead komputasi yang besar saat mengubah hasil kueri menjadi objek
    • TypeORM disebut sebagai contoh masalah ini
  • Masalah kedua adalah ketika relasi satu-ke-banyak atau banyak-ke-banyak ditelusuri sambil mengirim banyak permintaan bolak-balik ke database
  • Pola ini disebut masalah N+1
    • kueri awal 1 buah diikuti N subkueri tambahan
    • Dalam contoh Prisma, saat pengguna, posting, dan komentar diambil secara bertingkat, setiap komentar bisa memicu permintaan database baru
  • N+1 sering muncul di ORM, tetapi dengan data loader, N+1 kueri dapat dipadatkan menjadi 2 kueri
  • Cukup banyak masalah umum ORM bisa dihindari jika fitur ORM dimanfaatkan dengan baik

Masalah yang lebih besar adalah visibilitas dan debugging

  • Kelemahan terbesar ORM adalah visibilitas
  • Pada dasarnya ORM adalah pembuat kueri, sehingga selain kasus seperti kesalahan tipe mentah yang sangat jelas, ORM bukan penyampai akhir dari error
  • Saat error SQL dikembalikan, ORM harus menafsirkannya lalu menyampaikannya kembali ke pengguna
  • Active Record mengalami kesulitan di titik ini, dan inilah juga alasan Lago merefaktorisasi kueri langganan billing mereka
  • Ketika hasil yang keluar berbeda dari yang diharapkan, proses berikut harus diulang
    • memeriksa kueri SQL yang dirender
    • menjalankan ulang SQL tersebut
    • memetakan kembali error SQL ke perubahan di Active Record
  • Proses bolak-balik seperti ini melemahkan tujuan awal penggunaan Active Record, yaitu agar tidak perlu berinteraksi langsung dengan database SQL

Penilaian praktis

  • Jika digunakan dengan benar, ORM dapat memberikan efisiensi yang mendekati SQL mentah
  • Banyak masalah muncul ketika fitur ORM yang mirip SQL tidak digunakan dan struktur logika bahasa host terlalu diandalkan
  • Jika kueri besar menyulitkan pengembang dan menghambat debugging, memindahkannya ke kueri SQL mentah bisa menjadi investasi yang baik
  • Sebagian besar ORM menyediakan kemampuan untuk menjalankan kueri SQL dari dalam ORM

Bacaan terkait

1 komentar

 
GN⁺ 2023-06-28
Komentar Hacker News

  • Saya sudah memakai ORM sejak Hibernate baru muncul di Java, tapi rasanya selalu kurang bagus
    Keunggulan katanya bisa “ganti ke database lain” kalau dilihat sekarang hampir seperti omong kosong, dan pada praktiknya tidak ada yang benar-benar memakainya seperti itu
    Pernyataan bahwa “tidak perlu tahu SQL” juga salah, dan aplikasi non-trivial yang berumur panjang pada akhirnya tetap perlu mengutak-atik query individual di level string
    Menurut saya, lapisan data memang paling tepat dibuat dengan menyusun dan menginterpolasi query satu per satu sebagai SQL string, dan makin dekat ke raw JDBC makin baik
    Klaim bahwa ORM mendukung “model domain” juga alasan yang buruk, karena model domain itu pada akhirnya selalu menjadi anemic domain model yang kosong dari logika
    Kalau memikirkan waktu yang terbuang untuk ORM, XML, anotasi, debugging SQL hasil generate, dan sebagainya, rasanya ingin menangis

    • Sangat setuju. Saya ingin menggambarkan ORM sebagai sesuatu yang “membuat bagian yang mudah sedikit lebih mudah, tapi membuat bagian yang sulit menjadi sangat sulit”
      Bagian yang mudah itu memang sudah mudah, jadi saya tidak terlalu peduli; justru di saat terburuk ketika query runtuh saat bertemu skala, saya sering harus melawan ORM itu sendiri sehingga pekerjaan jadi sejuta kali lebih sulit
      Query builder memang tidak sepenuhnya sama dengan ORM, tapi saya suka tulisan https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41... dan menjadi penggemar teknologi seperti Slonik
      Ia memberi 90% fungsi yang saya inginkan, seperti auto-binding hasil ke objek dan pemeriksaan tipe yang kuat, sambil tetap membiarkan kita menulis SQL biasa
      Saya juga tidak paham anggapan bahwa SQL itu bahasa yang secara misterius sulit. Memang tua dan punya kekurangan, tapi tetap lebih baik belajar SQL daripada mempelajari bahasa query buatan alat ORM
    • Sejak pertama kali mencobanya dulu sekali, saya membenci ORM karena alasan yang sama dan menganggapnya sebagai anti-pattern
      Waktu itu kalau mengutarakan kritik seperti ini, pengembang lain sering memandang rendah
      Sampai sekarang pun banyak alat dan teknik yang terpaksa harus dipakai sebagai developer itu anti-pattern, dan kenyataan menyedihkan di industri adalah cukup banyak alat yang dipakai luas itu kurang bagus serta mendorong anti-pattern
      Di industri teknologi ada segelintir developer dan mantan developer yang punya koneksi bagus serta memegang kendali keputusan, dan mereka terasa kurang bagus
    • Kebetulan Anda memulainya dengan salah satu ORM terburuk yang ada
      Ada juga ORM yang rasio kelebihan dan kekurangannya cukup baik, terutama di ekosistem Python
      Django ORM itu kaku dan performanya juga kurang bagus, tapi terintegrasi dengan baik, praktis, produktif, dan enak dipakai
      Peewee menyediakan ORM dalam paket kecil, jadi kalau tidak butuh fitur luar biasa dan sedang malas, ia membuat menulis program kecil terasa menyenangkan
      SQLAlchemy butuh investasi lebih besar, tapi sangat fleksibel, menghasilkan SQL yang rapi, dan bekerja dengan benar
      Ia juga membuka query builder tingkat lebih rendah untuk saat Anda tidak menginginkan paradigma berorientasi objek dan ingin mengekspresikan abstraksi perilaku SQL yang idiomatis lewat Python
      Pada akhirnya ini menjadi keputusan engineering biasa yang menimbang return on investment
    • Pernyataan bahwa “harus menyesuaikan di level string” menurut pengalaman saya adalah omong kosong
      Saya sudah melakukannya lebih dari 10 tahun, tapi belum pernah ada query yang tidak bisa ditangani lebih baik oleh Hibernate jika Anda membaca dokumentasi Hibernate selama 5 menit dan mengikuti yang disarankan untuk situasi itu
      Kelihatannya para fanboy SQL yang percaya semua developer harus menghafal tabel logika tiga nilai dan nama fungsi ala COBOL justru tidak mau repot membaca dokumentasi Hibernate
    • “Tidak perlu tahu SQL” tidak pernah dijadikan keunggulan ORM oleh orang yang punya sedikit saja akal sehat
      ORM itu untuk beban kerja OLTP, bukan untuk OLAP, dan salah satu pendiri Hibernate juga pernah mengatakan demikian
      Manfaat utamanya hanyalah menghindarkan kita dari harus menulis sendiri query INSERT/UPDATE yang panjang dan rawan salah, serta melakukan pemetaan otomatis baris SQL ke objek
      Kalau memilih pendekatan raw, banyak bagian itu pada akhirnya harus diimplementasikan ulang, jadi ini juga bukan permainan zero-sum

  • Dalam aplikasi yang cukup kompleks, pada akhirnya akan muncul sesuatu seperti query builder yang memungkinkan berbagai bagian aplikasi menyusun query secara tertunda bersama-sama
    Strukturnya menjadi seperti menyusun lewat query alih-alih menggabungkan, memfilter, dan mengurutkan data di memori
    ORM adalah alat yang memudahkan hal ini, tetapi juga bisa membuat kita tanpa sadar menembak kaki sendiri karena mudah menghasilkan query N+1
    Seperti semua alat, trade-off harus dipertimbangkan bersama use case nyata, dan memanipulasi string pernyataan SQL secara langsung tidak direkomendasikan dalam keadaan apa pun

    • Pengalaman dengan ORM bisa sangat berbeda tergantung bahasa yang digunakan, tingkat integrasi, dan jenis pekerjaannya
      Meski begitu, selalu ada orang yang mengabaikan perbedaan itu lalu menyatakan secara mutlak bahwa ORM itu baik atau buruk
      Lebih baik anggap itu sebagai sikap provokatif untuk menarik perhatian dan lanjut saja, lalu fokus pada diskusi yang berangkat dari, “ORM punya kelebihan, tetapi kita harus tahu di mana itu berlaku, dan memastikan masalah penggunaannya tidak melampaui manfaatnya”
    • Saya tidak menganggap kebutuhan akan query builder sebagai sesuatu yang wajar dalam aplikasi yang cukup kompleks, dan saya tidak menerimanya di aplikasi saya
      Kalau butuh data, pergilah ke lapisan akses data, dan jika yang dibutuhkan belum tersedia, buat repositori baru atau provider lain yang sesuai dengan pola yang dipakai
      Baik ORM maupun penyusun query buatan sendiri, kalau aplikasi sudah sampai membuat orang keliru merasa “ini perlu karena aplikasinya cukup kompleks”, berarti kondisinya sudah terlalu rumit untuk dipakai secara stabil
      Pada akhirnya kita jadi menilai builder di lapisan yang salah, atau luput menyadari bahwa saat menelusuri hasil kita sedang membuat query N+1
      ORM tidak diperlukan
    • Saya melihat ini mirip dengan apa yang dilakukan LINQ yang keluar pada 2007
      LINQ bukan ORM secara persis; jika kita membuat pernyataan LINQ yang bertipe kuat, itu akan diubah menjadi expression tree, lalu provider query mengubahnya kembali menjadi query
    • Sebagai orang yang memakai ORM dan raw SQL sekaligus, saya paham kedua sisi
      Saat pengembangan, saya lebih menyukai keterbacaan ORM di dalam model, tetapi ketika diperlukan saya memantau dengan saksama N+1 dan inefisiensi lain lalu mengoptimalkannya
      Batas “ketika diperlukan” memang tidak jelas, tetapi saya berusaha untuk tidak mengoptimalkan terlalu dini
      Untuk proyek baru, saya cenderung memulai dari database, lalu sebelum menulis kode saya membangun intuisi model data lewat factory, seeder, dan query raw SQL
      ORM seperti Eloquent di Laravel punya metode yang baik untuk mengatasi N+1 dan melakukan lazy loading, tetapi selalu ada trade-off
    • Ada juga library yang membalik konsep ORM
      Alih-alih library yang mengizinkan penyusunan query tertunda, kita menulis query secara langsung lalu library tersebut menghasilkan kode untuk query itu saat waktu kompilasi
      Misalnya, jika kita menulis query seperti getUser: SELECT * FROM users WHERE id = ?, ia akan membuat kelas GetUserQuery dan metode seperti getUser(id: String): GetUserQueryResult, dan menurut saya model ini jauh lebih baik

  • Alasan utama saya tidak menyukai ORM adalah kecenderungannya memperlakukan mesin SQL modern seperti penyimpanan bit bodoh yang dibesar-besarkan
    CTE, join LATERAL, dan klausa RETURNING bisa sangat menyederhanakan pemrosesan atau menghilangkan kemungkinan inkonsistensi data, tetapi ORM umumnya berhenti pada pemetaan sederhana tabel dasar dan view ke objek yang sudah ditentukan sebelumnya
    Kalau ORM sampai membuat tabelnya juga, itu lebih buruk lagi
    SQL pada dasarnya adalah alat ekstraksi data sekaligus bahasa transformasi, tetapi ORM hampir sepenuhnya mengabaikan sisi ini sehingga banyak developer tidak tahu bahwa SQL punya lebih dari sekadar INSERT/SELECT/UPDATE/DELETE
    Ada pivot table, time query, CUBE/ROLLUP, window function, set-returning function, materialized view, external table, pemrosesan JSON, pemrosesan tanggal, exclusion constraint, tipe seperti range·interval·domain, row-level security, MERGE, dan lain-lain
    Ini seperti punya seluruh gudang alat, tetapi seseorang hanya menyerahkan palu, obeng, dan gergaji besi satu per satu sambil meyakinkan bahwa itu sudah cukup, dan sepanjang karier kita bahkan tidak sadar bahwa beberapa meter di sebelah ada table saw, router, sander, dan set baji

    • Sebagian besar framework ORM punya fitur untuk menjalankan raw SQL, jadi memakai ORM bukan berarti kita tidak bisa memakai fitur-fitur ini
      ORM memang cenderung membuat orang berpikir terutama dalam kalimat CRUD sederhana, tetapi mungkin itu justru lebih baik dan fitur tingkat lanjut seharusnya digunakan dengan hemat
    • Saya merasa beruntung karena kebanyakan mengerjakan proyek tanpa database sama sekali
      Meski begitu, kalau harus memakai DB, saya sengaja berusaha menggunakan hanya subset yang sangat kecil dari fitur DB
      Karena “kode” saya anggap sebagai wilayah yang bisa dikendalikan, sedangkan “database” adalah wilayah yang berbahaya dan sulit dijangkau, tempat error baru muncul belakangan dalam hal-hal seperti integration test yang lambat
      Logika yang terjadi di dalam DB berada di luar cakupan pengujian tingkat rendah sehingga terasa menakutkan, dan sepertinya saya bahkan tidak akan memakai query select-from-select
      Sebagian besar isi gudang alat itu akan dengan senang hati saya tinggalkan
    • Karena itu, tidak mengherankan juga bahwa banyak developer tidak bisa melihat perbedaan antara SQL dan NoSQL
    • Ketika skala membesar, sering kali database sengaja didenormalisasi secara kuat demi performa sehingga dipakai seperti penyimpanan bit bodoh yang dibesar-besarkan
    • Saya pernah beberapa kali mengerjakan proyek yang berkata, “kita tidak butuh fitur database yang mewah seperti itu,” dan menghadapi hasilnya sangat membuat frustrasi
      Sebagian besar waktu akhirnya habis untuk membuat jalan memutar yang rumit demi menemukan kembali pengaman dasar untuk integritas data
      Membuat database versi sendiri mungkin menyenangkan untuk belajar, tetapi bukan untuk aplikasi produksi

  • ActiveRecord selalu terasa bagus bagi saya
    Ada beberapa situasi pengecualian, tetapi ia pas di titik 80/20, memungkinkan kita keluar ke SQL bila perlu, dan lifecycle hook-nya juga sangat bagus untuk merapikan logika domain serta mudah dipahami
    ORM yang praktis itu bagus, selama tidak menyembunyikan semuanya di balik “bundle” atau memperkenalkan bahasa query sendiri
    ORM yang mencoba “menyelesaikan” masalah ORM sepenuhnya justru sulit ditangani

    • ActiveRecord benar-benar menyenangkan untuk dipakai, dan ketika menemui edge case kita selalu bisa kembali ke raw SQL
      ORM seharusnya dibuat seperti ini
    • Sulit membayangkan membangun ulang aplikasi CRUD besar tanpa ActiveRecord, karena keterbacaan dan maintainability-nya akan memburuk
      Namun, untuk memakainya dengan benar dibutuhkan pengetahuan awal yang baik tentang SQL
      Masalah muncul ketika orang tidak belajar SQL dan tidak memahami query yang dihasilkan AR maupun keterbatasannya
    • Saya tidak terlalu memahami keluhan terhadap ORM, tetapi mungkin karena satu-satunya ORM yang pernah saya pakai adalah ActiveRecord

  • Premisnya salah. ORM tidak pernah menjadi “ide yang berbahaya”.
    Memang ada ORM yang mengerikan untuk diajak bekerja, tetapi itu tidak berarti seluruh genrenya adalah gagasan buruk.
    Saya sudah bertahun-tahun senang memakai SQLAlchemy karena ia tidak berusaha menciptakan ulang konsep SQL itu sendiri.
    Sebaliknya, ia menyediakan lapisan yang nyaman untuk membangun dan meneruskan query, serta menangani detail-detail kecil dengan benar sehingga kita tidak perlu mengutak-atiknya sendiri.

    • Pengalaman ORM saya hampir seluruhnya hanya dengan SQLAlchemy, dan sedikit belajar Ecto, jadi melihat thread ini membuat saya bertanya-tanya apakah ORM lain memang semuanya mengerikan.
      Belakangan ini saya belajar Rust, dan menulis sendiri kode boilerplate untuk menangani CRUD sederhana terasa menyakitkan dan seperti buang-buang waktu.
      ORM SQLAlchemy memang bisa sedikit menghalangi untuk query yang lebih kompleks atau yang ingin dioptimalkan, tetapi dalam kasus seperti itu kita selalu bisa turun langsung ke SQL.
    • Sudah lama sekali saya tidak melihat orang memakai ungkapan “begging the question” dengan benar.
    • Saya bisa merekomendasikan SQLAlchemy karena ia membuat orang percaya diri menulis SQL dengan cara yang selaras dengan query-nya.

  • Seperti halnya apa pun, ada situasi yang cocok dan yang tidak, dan teknologi mudah disalahgunakan atau dipakai dengan keliru.
    Misalnya, ORM seperti Entity Framework di .NET bisa menjadi aset besar, terutama saat bekerja dengan pendekatan database-first.
    Jika Anda punya DB dengan ratusan tabel dan relasi foreign key yang benar, ORM membantu menavigasi skema yang rumit dan memberi pemeriksaan saat kompilasi ketika ada perubahan.
    SQL tertanam adalah pedang bermata dua yang tampak seperti keuntungan performa, tetapi sangat sulit dipelihara, terutama untuk SQL panjang yang di-hardcode dengan banyak join.
    Maksud saya ketika tabelnya ratusan, bukan 5~10 tabel.
    Saya tidak berniat meyakinkan siapa pun, tetapi jangan menelan mentah-mentah apa yang Anda baca di internet tentang praktik terbaik.
    Bisa jadi orang-orang sedang membicarakan hal yang sama sekali berbeda, dan akan selalu ada developer buruk apa pun teknologinya.

  • Jika Anda tidak memakai ORM atau antarmuka DB lain, pada akhirnya Anda akan menulis dan memelihara sendiri sesuatu untuk hal-hal seperti CRUD.
    Dan besar kemungkinan di dalamnya akan muncul bug aneh, edge case, dan celah keamanan.
    Ada masalah juga ketika prinsip seperti SOLID diajarkan di kelas universitas sebagai prinsip desain perangkat lunak.
    Di akademia itu masuk akal karena batasan seperti waktu, maintainability, uang, dan usaha kurang penting, tetapi ketika lulusan baru masuk ke dunia kerja, benturannya bisa sangat buruk.
    Soalnya mereka terbiasa menghabiskan sepanjang hari untuk mencukur yak dan menemukan kembali roda demi mencari solusi yang “sempurna”.
    Kalau tidak ada cukup senior/lead developer yang kompeten untuk mengendalikan ini, hasilnya bisa berupa produk yang sangat “menarik”, anggaran membengkak, kebakaran besar, atau kombinasi semuanya.
    Yang lebih buruk adalah ketika sesuatu dibuat di akademia dan dirancang untuk akademia lalu dilepas ke publik.
    Contoh baik/buruk yang representatif adalah OpenStack, yang punya begitu banyak tuas dan titik penyesuaian serta komponen yang dimodularisasi secara gila-gilaan agar bisa mendukung lingkungan khusus CERN dan ratusan universitas, tetapi begitu Byzantium sampai-sampai hampir mustahil untuk mulai memakainya.

    • Ada banyak keluhan di thread ini bahwa ORM tidak sesuai dengan janji vendor, dan itu memang benar.
      ORM tidak akan membuat Anda bisa mengganti database tanpa usaha, tidak menghilangkan kebutuhan untuk mempelajari dan memahami SQL yang dihasilkannya, dan tidak akan membuat skema menjadi mulus.
      Namun orang tetap memakainya karena ini adalah abstraksi standar yang pada akhirnya memang harus diduplikasi.
      ORM memungkinkan caching akses DB, yang dengan SQL manual menjadi sangat sulit secara mengejutkan seiring skala membesar.
      Ia juga menghadirkan alat dan praktik terbaik yang terstandardisasi, sehingga masalah seperti N+1 bisa menjadi tidak relevan.
      Masalah utama ORM adalah ekspektasi yang salah dan ORM yang buruk.
      Kalau ingin tahu nilai ORM, buka proyek yang ditulis tanpa ORM lalu coba ubah apa saja.
    • Pernyataan “pada akhirnya Anda akan membuat sendiri” itu hanya benar jika Anda ngotot menyusun logika berdasarkan objek, bukan baris.
      Lihat https://news.ycombinator.com/item?id=36498583.
    • Beberapa departemen dan banyak perusahaan pernah menderita atau gagal karena satu atau beberapa orang super jenius mengejar kesempurnaan.
      Pekerjaan yang berguna jadi tidak berjalan, atau memakan waktu 20~100 kali lebih lama dibanding pendekatan yang cepat dan kotor.
      Yang paling buruk adalah ketika sebuah tim desainer HTML berpengalaman dipaksa belajar functional programming.
      Penyihir konfigurasi backend itu adalah keajaiban rekayasa modern dan desain elegan, tetapi pembuatannya memakan 10 orang selama 1 tahun.
      Uang VC memang bisa membuat orang jadi aneh.
    • Saya terlalu banyak mendengar hal negatif tentang SQLAlchemy sampai memutuskan membuat query builder ringan sendiri, tetapi 8 bulan kemudian saya tetap memakai SQLAlchemy.
      Bahasa SQL sangat kompleks, dan membuat query builder yang benar-benar lengkap dengan semua fitur yang semestinya jelas bukan hal sepele.
      Itu pun belum menyentuh bagian pemetaan relasional yang sebenarnya.
    • Lebih baik memakai ORM yang bagus, kalau tidak Anda akan menanggung sendiri setengah dari ORM yang buruk.

  • Saya rasa SQL adalah salah satu kasus di mana “program saja sendiri omong kosong itu secara langsung” memang benar
    Tidak banyak gunanya belajar SQL atau library ORM; lebih baik belajar dan menulis SQL langsung
    Akses database kemungkinan adalah pekerjaan fundamental yang akan terus dilakukan sepanjang karier, jadi yang terbaik adalah mempelajari keterampilan nyatanya secara langsung
    CSS juga mirip; alih-alih belajar library CSS, lebih baik belajar dan memakai CSS
    Sebenarnya hampir semua aspek pengembangan frontend juga begitu; alih-alih “library form”, kita bisa langsung menangani API form milik browser
    Secara pribadi, SQL jauh lebih mudah dipelajari daripada ORM mana pun
    Jangan buang biaya untuk mempelajari hal yang keliru

    • Jika belajar SQL dulu, kita juga akan tahu kapan perlu memakai ORM, dan bisa menilainya dengan lebih baik
      CSS juga sama; kalau paham CSS, kita jadi jauh lebih fleksibel dan lebih mengerti saat memilih library demi kemudahan
    • SQL sudah lama disebut sebagai bahasa abadi
      Lewat berbagai platform pengembangan seperti mainframe, desktop, client/server, web, dan beragam bahasa di atasnya, SQL selalu menjadi benang merah yang sama
      Saya sepenuhnya setuju bahwa pengembang yang benar-benar memahami lapisan data dan apa yang terjadi di bawahnya adalah pengembang yang lebih kuat
      Jika mau menghabiskan waktu untuk mempelajari keanehan ORM, pertanyaan klasiknya adalah: kenapa waktu itu tidak diinvestasikan untuk belajar SQL?
      Bunga majemuk dari pengalaman SQL kemungkinan akan lebih bernilai 10~15 tahun kemudian dibanding ORM dari platform atau bahasa tertentu
      Ada alasan untuk mempelajari dan memakai ORM, tetapi jangan condong ke ORM hanya karena tidak mau belajar SQL
    • Intinya lebih dekat ke “pelajari dulu dasar-dasarnya sebelum abstraksinya”
      Dengan begitu kita tahu apa yang harus dibayar untuk abstraksi itu. Tentu, kalau itu “abstraksi tanpa biaya”, ceritanya lain
    • Sejak 1992 saya sudah menulis SQL langsung dengan Pro*Pascal dan CS130
      Tetapi sekarang saya memakai crud dari azer, yang bisa dikategorikan sebagai ORM, karena marshaling/unmarshaling dengan tipe Go
      sql di pustaka standar Go terlalu mendasar, jadi kita praktis harus menulis sendiri marshaling/unmarshaling objek, dan itu benar-benar membosankan
      Kalau sekarang memakai ORM, sepertinya saya akan memakainya hanya untuk tujuan itu

  • Saya suka micro ORM “titik tengah” seperti Dapper atau Diesel
    Query tetap ditulis dalam SQL, tetapi kita mendapat strong typing dan pemetaan otomatis hasil set ke objek
    Jadinya kita memperoleh produktivitas sekaligus bahasa query “sungguhan” yang lengkap fiturnya
    Saya juga jadi suka pendekatan di mana object mapper hanya dipakai untuk query read-only
    Update dilakukan dengan command pattern, yaitu stored procedure, lalu dipetakan agar terlihat seperti metode native

    • Dapper adalah solusi akses data yang paling menyenangkan yang pernah saya pakai sejauh ini
      Pengembang harus berhenti berpura-pura bahwa SQL itu tidak ada dan menerimanya saja
    • Saya suka karena tidak perlu menulis sendiri fungsi model yang pada akhirnya hanya memetakan ke SQL, atau menulis boilerplate PHP untuk menjalankan query terparameterisasi dengan benar
      Eloquent mengabstraksikan pekerjaan remeh semacam itu dengan cukup baik sehingga saya bisa fokus ke logika
      Saya sedang menulis ulang aplikasi PHP “lama” yang hanya berisi array dan query menjadi struktur yang memakai model dan Eloquent, dan rasanya benar-benar mengubah permainan
    • Titik tengah itu bagus. Di TypeScript ada misalnya Kysely atau proyek saya, Zapatos
    • Menurut saya ini titik optimalnya
      Dulu saat memakai SQLite di .NET, saya juga membuat library pembungkus ke arah seperti itu: https://github.com/zmj/sqlite-fast

  • Thread ini menunjukkan dengan jelas dominasi mindshare ORM
    Di hampir semua komentar, alternatif implisit terhadap ORM adalah raw SQL dalam bentuk string literal di dalam kode aplikasi
    Padahal sejak 6 tahun lalu sudah ada alat-alat yang memakai SQL sebagai sebuah bahasa dan menghasilkan wrapper yang mengekspos query ke aplikasi sebagai metode
    Misalnya queryfirst, pgtyped, pugsql, sqlc
    Ini adalah perubahan paradigma, atau setidaknya bisa menjadi itu, dan tampak jelas sebagai cara kerja yang lebih unggul; tetapi ORM dan perdebatan yang tak berubah ini menyedot semua oksigen sehingga pendekatan itu tetap berada di pinggiran

    • Betul. Di Go juga ada sqlc
      SQL adalah sebuah bahasa, dan itu pun bahasa tingkat tinggi
      Mencoba menyambung-nyambungkan SQL dengan bahasa yang lebih rendah tingkatnya adalah contoh klasik dari “kalau pegang palu, semua masalah terlihat seperti paku”
      Misalnya Anda sedang menulis dengan assembly yang tingkatnya rendah sambil berinteraksi dengan sistem besar, lalu dokumentasi sistem itu berkata bahwa input hanya bisa diekspresikan dalam JavaScript; ada pilihan
      Anda bisa membawa library aneh yang memungkinkan merangkai sesuatu dalam assembly murni sehingga tidak perlu meng-commit file xxx.js ke repositori, atau Anda bisa menuliskannya saja sebagai file .js dan memanfaatkan kekuatan bahasa tingkat tinggi itu
    • Setelah memakai sqlc di satu proyek, saya rasa saya tidak bisa kembali lagi
      Muncul satu sumber kebenaran tunggal untuk query SQL yang dipakai, dan karena yang benar-benar ditulis serta dipelihara adalah query itu sendiri, optimisasi seperti membuat indeks baru juga jadi mudah
    • ActiveRecord selalu terasa kurang bagus, tetapi arel, yang menyusun query di dalamnya, selalu saya sukai
      Menaruh abstraksi di atas string raw SQL sangat berguna, tetapi berpura-pura bahwa relasi adalah objek itu pendekatan yang rumit dan berbelit
    • Enterprise Objects Framework dari NeXT sudah mendukung ini lebih dari 25 tahun lalu
      TopLink mungkin juga begitu
      Begitulah cara framework itu menangani pemetaan antara stored procedure dan entitas lokal
    • Saya penasaran alat-alat yang dimaksud itu apa saja