Sebuah survei cepat terhadap rekan-rekan di proyek saya saat ini menunjukkan bahwa dengan kata-kata "ORM dan bekerja dengan database" dalam sebagian besar kasus kata-kata "Alchemy" dan "Django ORM" terdengar. Pengetahuan tentang dua kata ini, secara umum, cukup untuk menulis kode yang bersih, rapi dan bekerja. Namun memperluas cakrawala teknik tidak membahayakan siapa pun sejauh ini, jadi hari ini kita akan menambah beberapa gambar dunia (mungkin sampai hari ini tidak dikenal) untuk bekerja dengan database.
Yoyo
Saat ini, ORM apa pun hadir dengan sistem migrasi basis data internal. Pendekatan yang sederhana dan keren, ketika ORM memantau struktur tabel, secara umum, cocok untuk semua orang. Tetapi solusi ini memiliki kasus di mana tidak nyaman untuk menggunakannya:
Ada orang yang figuat permintaan dalam database, melewati ORM. Ini menggunakan sesuatu seperti asyncpg dan blotch kecil yang ditulis sendiri untuk menyederhanakan kompilasi permintaan.
Mengapa orang-orang ini memberikan fasilitas ORM? Ya, karena pembungkus apa pun untuk basis data memakan sumber daya sistem dalam jumlah tertentu, dan orang-orang ini perlu menulis kode kinerja tinggi. Mereka membuang ORM, dan entah bagaimana mereka perlu bermigrasi ke pangkalan.
- Migran internal mungkin memiliki pandangan spesifik mereka sendiri tentang penautan dan pengindeksan catatan. Kadang-kadang tidak mungkin untuk mengalahkan pandangan ORM ini pada struktur tabel, Anda harus memperbaiki sendiri koreksi kueri.
Dalam kedua kasus ini, lebih nyaman menggunakan migrasi manual - kami tidak bergantung pada model ORM, tetapi dengan tangan kami, kami mengetikkan instruksi SQL yang diperlukan dan memasukkannya ke dalam migrator sederhana yang secara berurutan menerapkan perubahan struktural pada database.
Outputnya adalah struktur tabel yang bersih, mudah dimengerti, dan dapat diatur sepenuhnya, disusun dengan bijak.
Untuk pendekatan manual semacam itu, ada migrator skema basis data yoyo .
pip install yoyo-migrations
Selanjutnya, semua pekerjaan manajemen migrasi dilakukan menggunakan yoyo yang dapat dieksekusi
yoyo new ./migrations -m "Add column to foo"
Perintah membuat file di mana Anda dapat memasukkan satu atau lebih instruksi untuk memigrasi skema
from yoyo import step steps = [ step("CREATE TABLE foo (id INT, bar VARCHAR(20), PRIMARY KEY (id))", "DROP TABLE foo"), ]
Setelah migrasi ini, Anda dapat bergulir ke pangkalan
yoyo apply --database postgresql://scott:tiger@localhost/db ./migrations
Semuanya sederhana, seperti log. Dan pada saat yang sama Anda memiliki kendali penuh atas bagaimana tampilan database.
Ada dua kelemahan dari pendekatan ini.
- Set bidang dalam tabel dan parameternya harus diikuti oleh pegangan. Setiap perubahan mengarah pada kebutuhan untuk menulis ALTER TABLE sendiri, kemampuan untuk memigrasi semuanya dalam satu klik hilang.
- Penggabungan migrasi semacam itu juga harus selalu dengan tangan dan kepala. Ini, tentu saja, adalah pekerjaan yang berlebihan. Namun dalam praktiknya, konflik dan gabungan migrasi yang kompleks jarang terjadi.
Peewee
ORM kecil dan bukan yang paling populer (walaupun telah ditulis di sini lebih dari satu kali), yang, bagaimanapun, memiliki pemirsa sendiri.
Peewee dirancang untuk menjadi pembungkus yang paling bodoh dan sederhana untuk database, dengan mekanisme eksekusi permintaan yang paling dapat dipahami dan kode yang mudah dibaca.
Users.select().where( Users.user_id == user_id ).get()
Terlepas dari kesederhanaannya, minimalis dan sejumlah kecil kode, peewee memiliki segala yang dibutuhkan untuk pekerjaan yang waras.
- Kinerja yang memadai (meskipun bukan kecepatan eksekusi permintaan tercepat)
- Semua barang yang diperlukan - berbagai set bidang, hubungan antar entitas, kumpulan koneksi, set plugin dan ekstensi.
- Bahkan ada lebih banyak atau lebih sedikit asinkronisasi yang ditambahkan oleh modul peewee_async pihak ketiga .
Pony orm
Pony adalah bungkus legendaris. Lapisan basis data yang ditulis menggunakan ORM ini dapat mempercepat bagian belakang solusi lain. Tidak ada keajaiban dalam kecepatannya, ada kebijakan caching permintaan yang sangat kompeten ke database, banyak optimisasi dan trik dengan kode. Secara total, ini mengarah pada fakta bahwa Kuda Poni goreng dengan kecepatan kuda.
Yang minus bisa disebut sintaks kueri dalam ORM ini - sangat spesifik, menggunakan generator, lambdas, dan roti bahasa Python lainnya.
query = select(c for c in Customer if sum(o.total_price for o in c.orders) > 1000) Product.select().order_by(lambda p: desc(sum(p.order_items.quantity))).first()
Pendekatan ini membutuhkan kerusakan otak tertentu.
Kura-kura orm
Menggali berbagai repo ramah hewan peliharaan, saya menemukan koleksi tes ORM berbeda dengan pengukuran kecepatan. Selain ORM Pony yang telah disebutkan, ORM Kura - kura tertentu muncul dalam daftar tercepat. Jelas bahwa hasil tes tergantung pada siapa yang menulis tes dan bagaimana mereka menjalankannya, tetapi Anda perlu melihat lebih dekat pada hal ini.
Tortoise adalah proyek yang relatif muda, yang masih dalam pengembangan aktif. Kinerja yang baik dari perpustakaan ini dijelaskan oleh fakta bahwa ORM tidak mengandung sesuatu yang berlebihan dan berada di luar kotak yang dipenjara karena operasi asinkron. Dan itu juga mengasumsikan penggunaan uvloop , yang bekerja lebih cepat daripada siklus peristiwa piton asli.
ORM ini masih terlalu mentah untuk digunakan dalam pertempuran (misalnya, hingga pool koneksi bahkan diimplementasikan), tetapi Anda harus melihat pengembangan lib ini. Jika semuanya berjalan baik dengan pengembang, di tahun mendatang kita akan mendapatkan pembungkus yang sangat cepat untuk database dengan kecepatan yang baik dan tanpa sintaks aneh dalam gaya Pony.