Nah, satu hal yang penting untuk dilakukan setiap kali kita berdiskusi seperti ini adalah dengan jelas membedakan antara obyek pemetaan relasional ("ORM") dan lapisan abstraksi basis data . ORM adalah sejenis lapisan abstraksi basis data, tetapi tidak semua lapisan abstraksi basis data adalah ORM. Salah satu alat yang baik untuk belajar memahami hal ini adalah pustaka SQLAlchemy populer Python , yang menyebut dirinya sebagai "toolkit SQL dan Object Relational Mapper" (huruf tebal saya), dengan gagasan bahwa ini adalah hal yang berbeda. Ketika mereka meletakkannya di halaman fitur utama mereka :
Tidak diperlukan ORM
SQLAlchemy terdiri dari dua komponen berbeda, yang dikenal sebagai Core dan ORM . Core sendiri merupakan toolkit abstraksi SQL berfitur lengkap, memberikan lapisan abstraksi yang halus atas beragam implementasi dan perilaku DBAPI, serta Bahasa Ekspresi SQL yang memungkinkan ekspresi bahasa SQL melalui ekspresi Python generatif. Sistem representasi skema yang dapat memancarkan pernyataan DDL serta mengintrospeksi skema yang ada, dan sistem tipe yang memungkinkan pemetaan tipe Python ke tipe basis data, melengkapi sistem. Object Relational Mapper kemudian merupakan paket opsional yang dibangun di atas Core.
Halaman depan menggambarkan ORM seperti ini:
SQLAlchemy paling terkenal dengan objek-relational mapper (ORM), komponen opsional yang menyediakan pola data mapper, di mana kelas-kelas dapat dipetakan ke database secara terbuka, berbagai cara - memungkinkan model objek dan skema database untuk berkembang dalam suatu cara dipisahkan bersih dari awal.
Gagasan kunci ORM adalah mencoba dan menjembatani ketidakcocokan impedansi objek-relasional yang terkenal . Ini berarti mendefinisikan hubungan antara kelas yang ditentukan pengguna ke tabel dalam skema database dan menyediakan operasi "simpan" dan "muat" otomatis untuk kelas aplikasi Anda.
Sebaliknya, lapisan abstraksi database non-ORM cenderung lebih berkomitmen pada model data relasional dan SQL, dan sama sekali tidak berorientasi objek. Jadi alih-alih menampilkan "pemetaan" antara tabel dan kelas dan menyembunyikan skema database dari programmer, mereka cenderung mengekspos database ke programmer tetapi dengan API dan abstraksi yang lebih baik. Misalnya, pembangun kueri SQL memungkinkan Anda untuk menghasilkan kueri SQL kompleks secara terprogram, tanpa manipulasi string, seperti ini ( contoh dari perpustakaan jOOQ untuk Java ):
// Typesafely execute the SQL statement directly with jOOQ
Result<Record3<String, String, String>> result =
create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
.from(BOOK)
.join(AUTHOR)
.on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
.where(BOOK.PUBLISHED_IN.equal(1948))
.fetch();
Sekarang, kerangka bermain tampaknya tidak 100% sesuai dengan apa yang saya jelaskan , tetapi argumen mereka tampaknya berada di ruang umum ini: bekerja dengan model relasional secara langsung alih-alih menerjemahkannya ke kelas dan kembali dari mereka.
The jOOQ perpustakaan bernilai belajar sebagai tandingan ke ORMs. Mereka juga memiliki beberapa entri blog yang relevan yang patut dibaca: