ORM Python mana yang lebih baik antara Django dan SQLAlchemy

Apakah itu ORM?

Sebelum memperkenalkan perbezaan antara rangka kerja ORM Python (Django dan SQLAlchemy), kita mesti terlebih dahulu memastikan kita memahami sepenuhnya tujuan rangka kerja ORM.

ORM ialah singkatan kepada Pemetaan Hubungan Objek. Mari lihat tiga perkataan ini secara bergilir, yang menerangkan dengan tepat betapa bergunanya ORM dalam persekitaran dunia sebenar:

● Objek – Bahagian ini mewakili objek menggunakan rangka kerja dan bahasa pengaturcaraan, seperti Python.

● Perhubungan – Bahagian ini mewakili pangkalan data RDBMS (Relational Database Management System) yang digunakan. Ini termasuk banyak pangkalan data hubungan popular, dan anda mungkin menggunakan pangkalan data berikut — MSSQL, MySQL, Pangkalan Data Oracle, PostgreSQL, MariaDB, PerconaDB, TokuDB. Kesamaan kebanyakan pangkalan data hubungan ialah struktur hubungannya (jadual, lajur, kunci, kekangan, dll.).

● Pemetaan – Bahagian terakhir mewakili jambatan dan sambungan antara objek dan jadual data dalam dua bahagian pertama.

Jadi boleh disimpulkan bahawa ORM direka untuk menyambung bahasa pengaturcaraan dan pangkalan data untuk memudahkan proses mencipta aplikasi yang bergantung pada data.

Perbandingan antara Django dan SQLAlchemy Rakaman Aktiviti lwn Pemetaan Data

Django ORM dilaksanakan menggunakan rekod aktif - pelaksanaan ini boleh dilihat dalam kebanyakan ORM. Pada asasnya boleh dikatakan bahawa setiap baris dalam pangkalan data memetakan terus ke objek dalam kod dan sebaliknya. Rangka kerja ORM (seperti Django) tidak perlu pra-takrif skema untuk menggunakan sifat dalam kod, mereka hanya perlu menggunakannya kerana rangka kerja boleh "memahami" struktur dengan melihat skema pangkalan data. Selain itu, adalah mungkin untuk hanya menyimpan rekod ke pangkalan data kerana ia juga dipetakan ke baris tertentu dalam jadual.

SQLAlchemy dilaksanakan menggunakan pemetaan data — apabila dilaksanakan dengan cara ini, terdapat jurang antara struktur pangkalan data dan struktur objek (ia bukan 1:1 seperti pelaksanaan Rekod Aktif). Dalam kebanyakan kes, lapisan kegigihan tambahan mesti digunakan untuk mengekalkan interaksi dengan pangkalan data (seperti menyimpan objek). Oleh itu, anda tidak boleh hanya memanggil kaedah save() apabila dilaksanakan dengan rekod aktif (pembangkang), tetapi sebaliknya, kod itu tidak perlu tahu tentang operasi keseluruhan struktur hubungan dalam pangkalan data, kerana tidak ada hubungan langsung antara kod dan pangkalan data.

Jadi siapakah yang menang di antara mereka? tiada. Ia bergantung kepada apa yang anda ingin capai. Saya percaya bahawa jika aplikasi anda kebanyakannya adalah program CRUD (Buat, Baca, Kemas Kini, Padam) tanpa menggunakan peraturan yang sukar dan kompleks antara entiti data yang berbeza, maka anda harus menggunakan pelaksanaan Rekod Aktif (Django). Ia akan membantu anda menyediakan MVP untuk produk anda dengan mudah dan cepat tanpa sebarang kesulitan. Jika terdapat banyak "peraturan perniagaan" dan kekangan, lebih baik menggunakan model pemetaan data kerana ia tidak mengikat dan memaksa pematuhan ketat terhadap pertimbangan rekod aktiviti.

Gunakan pertanyaan kompleks

Dalam beberapa kes, Django dan SQLAlchemy boleh digunakan secara serentak. Kes penggunaan utama yang saya lihat banyak kali dalam kehidupan sebenar ialah Django untuk semua operasi CRUD biasa dan SQLAlchemy untuk pertanyaan yang lebih kompleks, biasanya pertanyaan baca sahaja.

Untuk maklumat lanjut dan contoh tentang ini, lihat Blog Kejuruteraan BetterWorks (kami tidak mempunyai sambungan, tetapi kami menyukai blog mereka).

Kunci utama dijana secara automatik

Satu lagi perbezaan antara kedua-dua rangka kerja ialah Django boleh mencipta kunci utama secara automatik untuk jadual, tetapi SQLAlchemy tidak boleh. Kekunci utama mesti dibuat secara manual untuk setiap jadual. Menimbang kebaikan dan keburukan - rangka kerja manakah yang anda fikir paling sesuai dengan kunci utama jadual? Ini boleh ditentukan mengikut budi bicara anda sendiri berdasarkan pengetahuan dan pengalaman pasukan.

Serahan automatik

Secara lalai, Django akan menyerahkan secara automatik, tetapi SQLAlchemy tidak akan. Autocommit mempengaruhi cara anda menggunakan rangka kerja (urus niaga, penarikan balik, dsb.).

Pangkalan data yang disokong

Django dan SQLAlchemy kedua-duanya berfungsi dengan MySQL, PostgreSQL, Oracle dan SQLite. Jika anda menggunakan MSSQL, anda harus menggunakan SQLAlchemy kerana ia menyokong sepenuhnya MSSQL dan anda juga boleh mendapatkan lebih banyak maklumat dan dokumentasi yang berkaitan.

Keluk Pembelajaran

Terdapat pendapat umum dalam talian bahawa Django lebih mudah dipelajari. Ini jelas kerana ia biasanya digunakan untuk kes penggunaan yang tidak begitu rumit. Oleh itu, anda harus mempertimbangkan berapa banyak usaha yang anda sanggup laburkan dalam mempelajari rangka kerja dan pembelajaran silang dengan SQLAlchemy untuk mendapatkan lebih fleksibiliti (dengan andaian anda benar-benar memerlukannya).

Saiz komuniti

Tanpa syak lagi, SQLAlchemy mempunyai komuniti terbesar dalam kalangan rangka kerja Python ORM. Jika komuniti adalah penting kepada anda (dan saya fikir ia sepatutnya), SQLAlchemy harus menjadi pilihan anda. Ini tidak bermakna anda tidak dapat mencari sebarang bantuan untuk rangka kerja lain, seperti Django. Anda juga boleh mendapatkan pembetulan pepijat, jawapan kepada soalan dan bantuan lain yang diperlukan daripada StackOverflow, tetapi kemungkinannya hanya lebih tinggi daripada SQLAlchemy.

Prestasi

Saya rasa adalah tidak bertanggungjawab untuk menulis sahaja (X lebih cepat daripada Y) di sini. Memandangkan ORM mempunyai begitu banyak ciri dan keupayaan, dan ia berbeza dalam setiap rangka kerja, sukar untuk membuat kesimpulan. Mengikut pengalaman saya, cara anda menggunakan ciri rangka kerja boleh memberi kesan yang besar pada prestasi keseluruhan lapisan data dalam aplikasi anda. Oleh itu, saya cadangkan untuk tidak memilih rangka kerja berdasarkan prestasi, tetapi belajar cara menggunakan rangka kerja secara rasional.

Jika anda menggunakan pertanyaan SQL mentah dalam rangka kerja ORM, menggunakan Jooq atau hanya sebahagian daripada pertanyaan tanpa menggunakan ORM, anda boleh mempelajari tentang pengoptimum pertanyaan EverSQL, yang mungkin merupakan cara paling mudah untuk mengoptimumkan sebarang pertanyaan.

Ringkasan

Dalam sebarang perbandingan, saya rasa lebih baik menyerahkan kuasa membuat keputusan kembali kepada pembaca. Setiap kes penggunaan adalah berbeza dan teknologi yang berbeza mungkin lebih sesuai. Lihat perbezaan yang dinyatakan di atas dan beritahu kami keputusan anda.

Atas ialah kandungan terperinci ORM Python mana yang lebih baik antara Django dan SQLAlchemy. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!