Abstraksi basis data - apakah ini berlebihan?


18

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?


2
Masalah terbesar dengan SQL standar adalah bahwa ada sejumlah pertanyaan yang spesifik untuk basis data. Sintaks gabungan luar sangat bervariasi, seperti halnya proses mendapatkan kueri "berjendela". Itulah perlunya DAL untuk memulai. Sekarang, jika ada varian standar SQL yang digunakan oleh DAL yang tahu bagaimana menangani idiotsyncrasi dari berbagai vendor SQL, saya akan menyambut baik itu.
Berin Loritsch

Jawaban:


10

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.


3
"RDBMSs tidak cocok dengan OOP" - Apakah semua yang ada dalam perangkat lunak harus OO?
quant_dev

@quant_dev: Tidak. Tapi lapisan 'abstraksi' secara inheren setidaknya 'berorientasi abstraksi'. Cuplikan kode yang diberikan menyarankan, bahwa kita berbicara tentang kode-OO.
back2dos

Saya selalu berpikir bahwa menanamkan SQL ke dalam C atau apa pun hanya hal paling bodoh yang bisa dibayangkan. Ketika saya harus melakukan sesuatu seperti itu, saya menciptakan cara mendefinisikan hubungan antara tabel dan menyimpannya dalam database dan kemudian menggunakan hubungan di sana untuk membuat SQL pada saat run time untuk berbicara dengan database. Kode C saya hanya: "Temukan entitas ini menggunakan kunci ini", "Simpan perubahannya".

9

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.


3
@Catatan - Tapi kemudian DAL harus memiliki parser SQL lengkap dan harus memiliki dialek yang didukung sendiri yang akan berbeda dari database tertentu. Dan kemudian ia akan memiliki semua kompleksitas yang dimilikinya saat ini untuk menghasilkan pernyataan SQL spesifik-database yang sesuai. Kata kunci LIMIT dalam contoh Anda, misalnya, valid di MySQL tetapi tidak di Oracle atau SQL Server.
Justin Cave

2
Sekarang kita sampai pada pertanyaan. Apa yang membuat seperangkat nama metode dan overload operator yang tidak standar lebih unggul daripada dialek SQL non-standar? Menggunakan SQL setidaknya akan memberi sang pembuat kode suatu dasar yang akrab untuk mulai mempelajari kerangka kerja dari.
Catatan untuk diri sendiri - pikirkan nama

3
@Catatan untuk diri sendiri: mungkin karena lebih mudah untuk menulis API gaya lancar daripada menulis parser SQL dalam beberapa dialek SQL dan kemudian menerjemahkannya ke beberapa dialek SQL lainnya.
Dean Harding

1
Sebagai catatan, saya juga lebih suka menggunakan SQL "asli". Sebagian besar proyek saya tidak pernah diperlukan untuk mendukung lebih dari satu database, jadi itu tidak pernah menjadi masalah bagi saya.
Dean Harding

3
"Anda mengabaikan fakta yang jelas bahwa tidak semua platform basis data menerima sintaks SQL yang sama" - ya, tetapi seberapa sering Anda menulis kode untuk dijalankan terhadap basis data apa pun ? Biasanya platform DB adalah investasi yang signifikan dan tidak sering diubah. Juga, ada keuntungan efisiensi yang signifikan yang dihasilkan dari pengoptimalan permintaan Anda terhadap jenis basis data yang diketahui.
quant_dev

5

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.


4

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.


Ya, perusahaan tempat saya bekerja dulu mulai menggunakan Hibernate dengan antusias. Kemudian mereka menemukan betapa mengejutkan (dengan cara yang aneh) pertanyaan yang dihasilkan oleh framework bisa.
quant_dev

@quant_dev Ya, itulah jebakan - mudah untuk mulai melakukan hal-hal sederhana dengan Hibernate atau JPA.
m5ba
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.