Harapan saya untuk DBMS di masa depan, juga untuk Rosreestr dalam hal transaksionalitas



Klien berinteraksi dengan database.

Dari situs http://corchaosis.ru , penulis gambar Jonathan Tiong.



Selain menjadi programmer (terutama Delphi + semua jenis DBMS yang berbeda, baru-baru ini ORAKL, + sedikit PHP), saya punya hobi - jual beli apartemen. Saya membeli apartemen pada tahap konstruksi dari pengembang yang kurang lebih dapat diandalkan dengan harga yang enak (misalnya, sekarang pengembang seperti itu adalah Pesawat Terbang, apartemen di dekat metro Nekrasovka sedang dijual), menunggu pengiriman rumah (seringkali dua tahun kemudian, dengan penawaran murah ini terjadi), saya melakukannya di direnovasi dan kemudian dijual dengan harga 95-100% dari harga pasarnya.



Jadi, saya (seperti orang lain) mengalami masalah kurangnya transaksionalitas RosReestr.



Masalah kurangnya transaksi transaksional Rosreestr



Dalam pemrograman "Transaksi", dan dalam real estat itu adalah "Berurusan dengan alternatif" (dan juga, sebagai bagian darinya, "Perjanjian tentang safe deposit box"), dan semuanya sedikit lebih rumit di sana. Aku beritahu padamu.



Vasya datang untuk melihat apartemen yang dijual Petya. Dan Vasya sangat menyukai semuanya, termasuk harganya, tapi Vasya tidak punya uang. Beginilah cerita kita dimulai.



Vasya memiliki propertinya sendiri, yang memiliki beberapa nilai yang tidak terlalu diperlukan baginya - Lomonosov tinggal di rumah sebelah, ketinggian langit-langit tujuh setengah meter, ada pangkalan penanaman buah dan pasar Tukang Kebun di dekatnya, Anda dapat berjalan ke Aeroexpress, ada ruang bawah tanah dengan ketinggian 1 meteran, di atas apartemen ada loteng yang nyaman untuk pengamatan astronomi. Vasya memahami bahwa fitur-fitur ini menaikkan harga apartemennya, tetapi tidak untuk dirinya sendiri. Dan dia memutuskan untuk membeli apartemen Petya, dan menjual apartemennya. Tetapi untuk menjualnya untuk membeli apartemen Petit, dan bukan hanya. Dalam bahasa Realtors, ini disebut - "Alternatif dipilih."



Sekarang mari kita lihat situasi ini dari sudut pandang Petya. Faktanya adalah bahwa Petya juga tidak tertarik untuk duduk dengan uang depresiasi, dia menjual apartemen untuk membeli apartemen di kota elf Valinor, tetapi dia belum melihat yang mana. Dalam bahasa Realtors, ini disebut "Menangani alternatif".



Dua elf dari Middle-earth, Maglor dan Maedhros, memiliki real estat yang sesuai (menurut kriteria Petit) di kota Valinor, yang segera dijual, karena mereka dikirim untuk melayani Melkor. Dalam bahasa Realtors, ini disebut "Penjualan Gratis".



Jadi, Vasya menemukan klien Seryozha. Sekarang, Petya menemukan dua opsi yang cocok untuknya di kota Valinor. Kami pergi ke pendaftaran transaksi. Demi kesederhanaan, katakanlah tidak ada pihak dalam transaksi yang menggunakan hipotek dan tidak memiliki pemegang saham minoritas. Jadi, tindakan berikut sekarang harus dilakukan:

1. Seryozha memberikan uang kepada Petya.

2. Vasya menyerahkan apartemennya kepada Seryozha.

3. Petya menyerahkan apartemennya kepada Vasya.

4. Baik Maglor, atau Maedhros, serahkan apartemen mereka di Valinor kepada Pete dan terima uang Seryozha.

5. Malkor dan Maedhros pergi ke Mordor untuk melayani Melkor.



Akan ideal untuk mengirim skrip berikut ke Rosreestr untuk dieksekusi:

MULAI TRANSAKSI

Berikan apartemen Vasya ke Seryozha.

Berikan apartemen Petya ke Vasya.

mulai

Berikan Apartemen Malkor ke Petya Berikan

Uang Seryozha ke Malkor IF_

ERROR: Berikan

Apartemen Maedhros ke Petya

Berikan Uang Seryozha ke Maedhros

akhiri

TRANSAKSI KOMIT



Ini adalah skrip transaksi yang disederhanakan dengan alternatif, dengan asumsi bahwa semua apartemen memiliki satu pemilik dewasa (dan mampu), bahwa harga mereka sama, dan pembayaran Realtors (jika ada) dibayarkan di luar tahapan transaksi.



Namun, Rosreestr tidak mendukung transaksionalitas. Semua tindakan akan dilakukan secara berurutan dan independen, satu demi satu, tanpa membatalkan seluruh transaksi jika salah satunya belum diselesaikan. Maksimal yang dapat dicapai - mengingat Rosreestr dan MFC tidak bekerja dengan transfer uang tunai - adalah memasukkan uang ke dalam safe deposit box, dengan syarat akses ke sana untuk Vasya, Petit, Seryozha (jika tidak ada transaksi yang didaftarkan sama sekali), dan pelaku lainnya, setelah mereka mempresentasikan kontrak yang didaftarkan oleh Rosreestr. (Dan omong-omong, bank tidak secara independen memverifikasi keaslian kontrak, yaitu, mereka mempercayai keaslian sekuritas peserta dalam transaksi).



Selain risiko pelaksanaan transaksi yang tidak tuntas, masalah lain adalah jika peserta lain dapat pindah ke perumahan baru mereka tanpa menunggu pendaftaran penuh (halo, masalah pembayaran tagihan listrik yang kurang!), Maka Maglor dan Maedhros tidak akan segera melayani Melkor, dan mungkin Maglor tidak akan dapat memegang Silmarils di tangannya, dia tidak akan punya waktu. Transaksi real estat dilakukan secara berurutan, dan setiap transaksi akan memakan waktu setidaknya 9 hari kerja untuk diselesaikan.



Selain itu, Rosreestr tidak mendukung beban perumahan yang sedang dibangun di bawah DDU, tetapi bisa, ini adalah tindakan dasar dalam kaitannya dengan kontrak berjangka sederhana.



Sekarang mari kita beralih ke kekurangan dan keinginan saya tentang DBMS



1) Yang pertama adalah tidak adanya sistem kontrol versi. Jika dari sisi Delphi saya melakukan pengembangan di kotak pasir saya, dan perubahan yang saya buat tidak muncul di programmer lain sampai saat mereka komit, maka tidak demikian halnya dengan DBMS. Dan bahkan jika mereka mempercayai saya dengan akses penuh (setidaknya dalam kerangka yang diperlukan untuk tugas yang diberikan kepada saya) ke database pertempuran, dan ini terjadi, saya tidak dapat mengembangkannya. Saat saya men-debug semuanya akan macet. Apa Zaman Batu ini ??? Sandbox pengembangnya.



2) Yang kedua adalah tidak adanya tabel standar yang telah ditentukan sebelumnya yang menggambarkan dunia nyata. Setiap perusahaan tempat saya bekerja memiliki format tabelnya sendiri yang menjelaskan nama-nama (dalam bahasa Rusia dan (setidaknya) Inggris, dalam kasus Rusia yang berbeda) selama dua belas bulan!



3) Ketiga - dan di sini saya akan menggunakan terminologi Orakl - tidak ada cara untuk memanggil skrip Sisipkan atau Perbarui sederhana menggunakan Kembali, seperti yang kita sebut Select. Mungkin ini bukan masalah Orakl, tetapi masalah persimpangan Delphi + Oracle.



4) Keempat - kebutuhan untuk menetapkan otoritas pada prosedur dan fungsi yang saya buat di mana saya tidak ingin melakukan ini. Saya tidak ingin mengatur, dan kemudian mengubah, otoritas pengguna dari prosedur dan fungsi. Mengapa, jika saya tidak secara eksplisit menulis Hibah, sistem tidak dapat melihat sendiri objek yang terlibat, dan, sesuai dengan hak untuk bertindak dengannya, memberikan atau tidak hak kepada pengguna tertentu untuk memanggil fungsi tersebut? Saya siap untuk menulis satu kata kunci untuk ini saat menulis fungsi dan prosedur. Atau, lebih baik lagi, biarkan pengguna memulai eksekusi, dan jika cabang algoritme menuntunnya ke permintaan yang tidak memiliki izin oleh pengguna, maka itu akan membuangnya dengan kesalahan.



All Articles