Unifying programming and database query [ditutup]

Pertimbangkan tutorial umum untuk bahasa pemrograman berorientasi objek seperti C ++ atau Java: buat sistem pemrosesan pesanan sederhana dengan objek yang mewakili akun, pesanan, item, dll (atau sesuatu yang kurang lebih setara). Masuk akal secara intuitif, tetapi gajah di meja makan itu tidak nyata karena ini adalah objek dalam memori; dalam sistem nyata, akun, pesanan dll sebenarnya tidak benar-benar hidup dalam memori , mereka hidup dalam database, dengan representasi memori hanya cermin jangka pendeknya.

Anda dapat menulis banyak kode sendiri untuk membaca dan menulis dari database, tetapi itu sangat membosankan dan rawan kesalahan sehingga tidak ada yang benar-benar melakukannya.

Semua orang pada akhirnya menggunakan ORM, tetapi mereka sendiri sangat bermasalah sehingga sebuah makalah terkenal menyebut mereka 'Vietnam dari industri kami'.

Saya tidak berpikir itu adalah ketidakcocokan antara objek dan hubungan begitu banyak sebagai ketidakcocokan antara bahasa pemrograman dan database menjadi hal-hal terpisah yang tidak saling mengenal . Dugaan: solusinya adalah memiliki satu bahasa yang merupakan bahasa pemograman dan basis data, yang pada gilirannya akan mengharuskan runtime bahasa juga menjadi basis data, dan kompiler JIT juga menjadi pengoptimal kueri.

Jadi itulah ringkasan dari masalah yang saya lihat. Pertanyaan saya adalah, adakah yang belum,

1. Sebenarnya membangun sistem terpadu seperti itu

2. Sudah mencoba tetapi gagal membangun sistem terpadu seperti itu

3. Menulis sesuatu yang substansial dengan topik bagaimana Anda akan membangun seperti itu, atau mengapa atau mengapa tidak

4. Munculkan cara alternatif untuk menyelesaikan masalah?

Ini pendapat saya. Sementara saya melihat dari mana Anda berasal, saya tidak bisa melihatnya dari sudut pandang desain.

Ketekunan data adalah subjek yang sangat kompleks. Demikian juga bahasa pemrograman. Menggabungkan keduanya akan menghasilkan ledakan kompleksitas. Dibutuhkan banyak upaya untuk benar-benar membuat keduanya cukup baik bagi orang yang benar-benar ingin menggunakannya. Saya pikir sudah disebutkan MUMPS adalah contoh yang bagus. Atau Anda bisa melihat berbagai varian SQL yang memiliki bahasa lengkap melesat di atasnya. Mereka mungkin dapat digunakan, tetapi saya tidak berpikir orang mau menggunakannya.

Jadi memisahkan mereka adalah cara yang jelas bagaimana menyelesaikan kompleksitas ini. Juga, dengan tidak mengikat mereka bersama, itu memungkinkan keduanya untuk diubah dan berkembang seiring waktu. Sebagai contoh, SQL sudah tua dan tidak banyak berubah sejak dibuat. Tetapi bahasa yang digunakan untuk menjalankan aplikasi berubah secara drastis pada periode yang sama. Dan sekarang, yang sebaliknya terjadi. Bahasa sebagian besar tetap sama sementara database sedang diubah dan dikembangkan.

Penempatan Runtime adalah masalah lain. Menggabungkan keduanya berarti database dan aplikasi atau server web harus berjalan dalam proses yang sama. Ini sangat membatasi, baik dari perspektif pemeliharaan dan dari kemampuan untuk menjalankannya di komputer yang terpisah atau dalam hubungan banyak-ke-satu.

Membagi dua menjadi modul terpisah dengan API yang jelas di antara mereka adalah cara terbaik untuk menjaga kompleksitas turun dan memberi Anda fleksibilitas dalam teknologi apa yang ingin Anda gunakan dan bagaimana bagian akhir dikerahkan.

Sepertinya Anda membuat beberapa asumsi utama. Misalnya, Anda mengasumsikan bahwa semua orang menulis ke database relasional. Itu tidak terjadi, ada banyak contoh database rasa lain (objek dbs, dokumen dbs, dll) yang menggunakan bahasa pemrograman asli untuk menulis semua kode dan mengelola kegigihan.

Sebagai contoh, Db4O kompatibel dengan Java dan C #, ObjectDB di Java, VelocityDB dalam berbagai bahasa. Semua driver MongoDB pada akhirnya mengharuskan Anda menulis hal-hal dalam bahasa pemrograman asli Anda (bonus jika Anda melakukan JavaScript, karena itu berarti shell menggunakan sintaks yang sama juga), dan seterusnya.

Ada banyak diskusi di berbagai tempat tentang mesin DB mana yang lebih baik dalam konteks apa, dan mengapa, terlalu banyak untuk cakupan jawaban ini, untuk memasukkan pertanyaan tertutup pada situs ini. Hasilnya adalah bahwa mereka masing-masing dioptimalkan untuk hal-hal yang berbeda, dan sampai saat ini SQL dianggap semacam 'penyebut umum terendah' ​​untuk aplikasi bisnis karena Anda mendapatkan banyak gratis dalam hal ACID dan kinerja (meskipun keduanya berubah baru-baru ini karena arsitektur dan persyaratan berubah).

Perlu juga dicatat bahwa sebenarnya ada banyak jenis pendekatan "semua dalam satu" sebelumnya. Bahasa mainframe sering memiliki logika kegigihannya sendiri, dan ada bahasa seperti Smalltalk yang tidak membedakan antara kode dan data sama sekali. Sekali lagi, mereka sering baik untuk beberapa kasus penggunaan tetapi tidak semua.

1. Ya (bukan saya). Itu disebut MUMPS .

2. Menurut pertanyaan SE.SE ini sebelumnya , atau artikel ini , MUMP tidak dirancang dengan baik. Tetapi memang sudah digunakan di industri kesehatan (dan saya kira masih ada sistem yang menggunakannya), jadi bukan kegagalan total.

3. Anda pasti akan menemukan informasi tentang itu sekarang Anda tahu apa yang harus dicari. Mulai dengan tautan Wikipedia di atas.

4. Mencari database Berorientasi Objek, banyak dari mereka yang spesifik bahasa. Mereka mencoba mengatasi ketidakcocokan objek-relasional dengan cara yang lebih sederhana daripada ORM.

Memang ada beberapa sistem yang menyatukan database dan bahasa pemrograman menjadi satu lingkungan.

Smalltalk mungkin yang paling dekat dengan apa yang Anda gambarkan. Objek dalam memori dipertahankan dalam "gambar", sehingga lingkungan bahasa dapat menggunakan database (objek) di luar kotak. Dan sebagian besar bahasa modern memiliki semacam mekanisme persistensi bawaan yang berarti benda-benda di lingkungan bahasa dapat bertahan dan dipertanyakan menggunakan bahasa itu sendiri.

Ini sangat nyaman untuk aplikasi pengguna tunggal. Tetapi pendekatan ini tidak akan menskala ke beberapa pengguna, karena mereka akan membutuhkan berbagi ruang memori yang sama, yang jelas membatasi jumlah pengguna. Solusi terukur membutuhkan server basis data terpisah yang mengelola konkurensi. Bahkan kemudian, ada beberapa basis data NoSql yang terintegrasi dengan lingkungan bahasa tertentu dan memungkinkan Anda untuk bertahan dan menanyakan objek dalam bahasa itu sendiri.

Dari sisi relasional hal-hal yang kita miliki bahasa seperti T-SQL yang merupakan bahasa pemrograman penuh yang merupakan superset dari SQL, sehingga query dan DML dapat dicampur dengan logika prosedural kompleks yang sewenang-wenang. Aplikasi bisnis yang kompleks telah dibangun menggunakan T-SQL jadi ini pasti bisa dilakukan, namun dengan tren saat ini adalah untuk logika bisnis prosedural jauh dari database.

Dalam kasus ini memang sangat elegan dan nyaman untuk memiliki basis data yang terintegrasi dengan bahasa pemrograman dan menghindari "ketidakcocokan impedansi". Jadi mengapa orang masih menggunakan database relasional yang terpisah dari lingkungan pemrograman dan mencoba menjembatani dengan beberapa ORM-kludge?

Ternyata ada sejumlah keuntungan memiliki data dan permintaan yang terpisah dari bahasa dan lingkungan pemrograman tertentu.

• Kemandirian data. Dalam kebanyakan organisasi, data sebenarnya diakses oleh banyak aplikasi. Toko mungkin memiliki basis data yang digunakan oleh frontend web, oleh alat dukungan pelanggan, mesin pelaporan, dan sebagainya. Data itu sendiri sering berumur panjang, sementara aplikasi datang dan pergi. Menggabungkan data ke satu lingkungan pemrograman tertentu akan terkunci pada lingkungan pemrograman tertentu. Tetapi bahasa pemrograman datang dan pergi, sementara data hidup selamanya.
• Permintaan ad hoc. Sangat mudah untuk dapat membuka prompt database dan menulis kueri. Jika kueri digabungkan erat dengan lingkungan pemrograman, ini akan menjadi tugas pemrograman dan hanya pengembang yang dapat melakukannya.
• Hindari penguncian. Karena SQL adalah standar, banyak vendor dapat menyediakan sistem manajemen basis data yang lebih atau kurang dapat dipertukarkan. Ini menghindari vendor-terkunci, dan membuatnya lebih mudah untuk membandingkan produk.
• Kopling longgar. Memiliki antarmuka yang terdefinisi dengan baik antara lapisan aplikasi dan basis data memungkinkan untuk menyempurnakan dan mengoptimalkan basis data secara independen dari logika aplikasi.
• Antarmuka bersama. Karena antarmuka basis data tidak tergantung pada logika aplikasi, alat yang tersedia dapat digunakan untuk pembuatan profil, replikasi, analisis, dan sebagainya.

Ini adalah pertanyaan yang cukup bagus yang saya proses di kepala saya berkali-kali. Salah satu contoh solusi yang ada untuk menyelesaikan masalah Anda adalah database grafik ArangoDB di mana Anda menggunakan JavaScript (berjalan di mesin internal) untuk menulis pengontrol yang dapat menghasilkan seluruh halaman web. Data diteruskan ke / dari penyimpanan menggunakan JSON sehingga dapat diakses secara asli di JavaScript dan kueri dilakukan dalam bahasa kueri tertanam. Jadi kasus ini adalah contoh dari perluasan JavaScript untuk dijalankan dalam database.

Dalam praktiknya pengendali tersebut tidak boleh diekspos kepada publik karena alasan keamanan karena kesalahan dalam konfigurasi basis data atau bug akan mengakibatkan pengungkapan data berharga Anda kepada publik.

Menurut pendapat pribadi saya, ini adalah pendekatan yang baik dan mempertimbangkan jika database mendukung semacam peta / fitur pengurangan yang akan memperbarui data agregat / indeks teks dan data lainnya yang sering ditanyakan secara real time, menambahkan lapisan keamanan tipis di antaranya (sebut saja memuat balancer) akan membuat aplikasi fungsional berjalan dalam database terdistribusi.

1. Sebenarnya membangun sistem terpadu seperti itu

Ya, saya melakukannya di Sciter .

Skrip Sciter adalah " JavaScript ++ " yang memiliki ketekunan bawaan :

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Di mana ndb.rootObyek normal dalam hal JS. Semua properti dan sub-objek yang dapat diakses darinya dapat bertahan - disimpan dan diambil dalam DB saat dibutuhkan - secara transparan untuk kode:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Data disimpan dalam DB baik pada siklus GC, ketika tidak cukup memori, atau pada ndb.commit()panggilan eksplisit .

Storagekelas disertai oleh Indexkelas - koleksi objek yang dapat dipesan dengan kunci unik / non-unik.

Set fitur mirip dengan MongoDB atau database NoSQL lainnya tetapi id tidak memerlukan ORM terpisah - akses db dibuat dengan cara skrip murni.

Saya mutlak untuk itu dan saya tidak tahu harus mulai dari mana. SQL bisa brilian dan saya membayangkan akan bagus untuk memiliki semua kekuatan itu dan jaminan transaksional tepat dalam bahasa pemrograman serba guna Anda (alih-alih harus menulis kueri sebagai kumpulan string atau menggunakan, semoga saja, ORM).

Satu-satunya sistem yang mendekati ide Anda yang saya ketahui disebut aquameta (tag line: "web dev stack built in PostgreSQL"; lihat https://github.com/aquametalabs/aquameta , http://aquameta.org ). Ada beberapa video intro yang tidak kalah gila daripada idenya sendiri (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), dan ketika saya berkata gila, maksud saya mereka menerapkan editor mereka sendiri dan sistem kontrol versi mereka sendiri di dalam Postgres.

Saya pikir ini persis alasan untuk penemuan Microsoft tentang LINQ. Ini telah digunakan dalam produksi skala penuh selama beberapa tahun sehingga mudah untuk menemukan literatur tentang hal itu dan refleksi dari pengalaman dunia nyata, baik positif maupun negatif. (Kebanyakan toko pengembangan .net menerimanya.)

Titik awal yang baik pada linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/