Setelah terkena banyak lapisan abstraksi database, saya mulai bertanya-tanya apa gunanya setiap perpustakaan menciptakan paradigma mereka sendiri yang berbeda untuk mengakses data. Mengambil DAL baru terasa seperti mempelajari bahasa baru lagi, ketika biasanya yang ingin saya lakukan hanyalah meyakinkan layer untuk menampilkan query SQL yang sudah saya tulis di kepala saya.
Dan itu bahkan tanpa menyentuh keterbacaan setelah fakta:
# Exhibit A: A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
.inner_join(db.ips_x_users.user_id == db.users.id)
.select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)
# Exhibit B: Another typical DAL
rows = db.ips_x_users
.join(db.users, on=db.ips_x_users.user_id == db.users.id)
.filter(db.ips_x_users.ip_addr == '127.0.0.1')
.select(sort=~db.ips_x_users, limit=10)
# Exhibit C: A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
INNER JOIN users ON
(ips_x_users.user_id = users.id)
WHERE ips_x_users.ip_addr = ip
ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')Apa yang salah dengan sintaks SQL standar? Itu diciptakan untuk tujuan tertentu, dan itu cocok dengan tujuan itu dengan indah. Mungkin hanya aku, tapi aku mengerti potongan C jauh lebih mudah daripada dua yang pertama. Kata kunci yang diubah namanya dan trik sintaksinya lucu, tetapi IMO, ketika sampai pada itu, mereka tidak membuat mengambil baris lebih mudah bagi pembuat kode.
Ini mungkin tampak seperti kata-kata kasar yang panjang, tapi ada adalah pertanyaan yang nyata di sini. Karena setiap DAL tampaknya menciptakan DSL baru untuk kueri daripada hanya menguraikan SQL yang coba-dan-benar, pasti ada manfaat menggunakan sintaks yang berbeda, atau kekurangan dalam sintaks SQL standar yang saya tidak sadari ada di sana. Adakah yang bisa menunjukkan apa yang saya lihat di sini?
sumber
Jawaban:
Masalah paling mendasar dari penggunaan SQL yang umum adalah, bahwa query SQL adalah string, yang entah bagaimana disusun dari bahasa lain. Di sinilah injeksi SQL dan kerentanan lainnya dan WTF berasal (contoh Anda dipilih dengan buruk, karena kueri Anda sebenarnya tidak memiliki parameter apa pun).
Masalah selanjutnya sebenarnya adalah akibat wajar: jika Anda hanya memiliki beberapa SQL yang ditulis dalam kode Anda, kompilator tidak dapat berbuat apa-apa. Kesalahan seperti kesalahan ketik pada nama kolom hanya akan muncul saat runtime. Ini pada dasarnya, mengapa Anda tidak ingin hanya representasi string dari kueri Anda dalam kode sumber Anda, tetapi sesuatu yang dapat dianalisis secara kompiler untuk mencegah 95% dari semua bug facepalm.
Dan masalah terakhir terjadi, ketika Anda mencoba memetakan basis data relasional ke semantik bahasa Anda dan model pemrograman: RDBMS tidak cocok dengan OOP (atau pengambilan data navigasi). Sebenarnya, ini adalah ide yang cukup mengerikan menggabungkan keduanya, tapi itu semua berorientasi objek DAL untuk database SQL (yaitu ORM) tentang. Tetapi semua lapisan abstraksi ini dikutuk untuk bocor. Saya pikir ini pada dasarnya mengapa ada begitu banyak dari mereka: Karena Anda bekerja dengan mereka, Anda melihat mereka cacat, Anda mulai menulis DAL yang melakukannya dengan benar dan akhirnya gagal.
Jadi, sementara masalah satu dan dua menyarankan untuk memiliki DAL yang menghilangkan SQL, masalah tiga menyiratkan tidak ada solusi langsung untuk memiliki satu (setidaknya untuk OOP) dan dengan demikian akan selalu ada lautan DAL dengan kekuatan dan keterbatasan yang berbeda. Pada akhirnya, yang dapat Anda lakukan adalah memilih beberapa dengan hati-hati dan tetap menggunakannya.
sumber
Anda mengabaikan fakta yang jelas bahwa tidak semua platform database menerima sintaks SQL yang sama, jadi menanamkan pernyataan SQL di seluruh aplikasi Anda tidak akan bekerja untuk setiap platform database. Jika Anda perlu mendukung beberapa platform basis data, Anda harus memikirkan kembali sebagian besar (jika tidak semua) pernyataan SQL ini.
sumber
Saya merasa seperti SQL mengalami perubahan besar yang sama dengan pointer 10 tahun yang lalu. Ada upaya berkelanjutan untuk menghilangkan pekerjaan manual dengan SQL dan membawanya ke tingkat abstraksi yang lebih tinggi. Hal yang sama terjadi dengan pointer dan manajemen memori manual bertahun-tahun yang lalu.
Karena pekerjaan saat ini sedang berlangsung, Anda menikmati melihat berbagai pendekatan yang disarankan, dicoba, diabaikan, dan diintegrasikan. Saya yakin kita akan melihatnya lebih banyak sebelum semacam pendekatan umum atau standar industri jika Anda ingin mewujudkannya.
Ini tentu memberi Anda keunggulan ketika Anda dapat memanipulasi kode akses data pada tingkat yang sama dan dengan paradigma yang sama Anda terapkan ketika pekerjaan Anda dengan kode aplikasi Anda.
Dalam beberapa kata - penyederhanaan, kelincahan, kecepatan, ini adalah tujuannya.
sumber
Joel telah menulis artikel yang bagus 10 tahun yang lalu: Jangan Biarkan Astronot Arsitektur Menakutkan Anda
Saya pikir itulah masalahnya. Saya menggunakan lapisan abstraksi dalam aplikasi saya sendiri karena saya menemukan pola dan mudah bagi saya untuk melakukan cara ini. Tapi itu DAL saya, saya tahu setiap baris dalam kode sumber => kontrol penuh. Tetapi saya tidak akan menyarankan untuk menggunakan kerangka kerja itu kepada siapa pun di luar tim / proyek saya.
Ketika Anda menggunakan sesuatu seperti itu, penting untuk mengetahui bagaimana penerapannya, itu berarti Anda harus menghabiskan banyak waktu mempelajari perpustakaan / alat. Jika Anda tidak punya waktu untuk mempelajarinya - jangan gunakan. Bahkan jika terlihat sangat mudah dari awal.
sumber