Klien berinteraksi dengan database.
Dari situs , oleh Jonathan Tiong.
Selain fakta bahwa saya seorang programmer (kebanyakan Delphi + semua jenis DBMS yang berbeda, baru-baru ini ORACLE, + sedikit PHP), saya memiliki hobi - jual beli apartemen. Saya membeli apartemen pada tahap konstruksi dari pengembang yang kurang lebih andal dengan harga yang enak (misalnya, sekarang Samolet adalah pengembang seperti itu, apartemen di dekat stasiun metro Nekrasovka sedang dijual), saya menunggu rumah diserahkan (seringkali dua tahun kemudian, ini terjadi dengan penawaran murah), saya melakukannya untuk memperbaikinya dan kemudian menjualnya dengan harga 95-100% dari harga pasarnya.
Jadi, saya (seperti orang lain) mengalami masalah kurangnya transaksionalitas RosReestr.
Masalah kurangnya sifat transaksional Rosreestr dari transaksi
Dalam memprogram "Transaksi" dan dalam real estat, ini adalah "Berurusan dengan alternatif" (dan juga, sebagai bagian darinya, "Perjanjian kotak penyimpanan"), dan ada hal-hal yang sedikit lebih rumit. saya memberitahu.
Vasya datang untuk melihat apartemen yang dijual Petya. Dan Vasya sangat menyukai semuanya, termasuk harganya, tapi Vasya tidak punya uang. Beginilah kisah kami dimulai.
Vasya memiliki propertinya sendiri, yang memiliki beberapa nilai yang tidak terlalu diperlukan baginya - Lomonosov tinggal di rumah tetangga, ketinggian langit-langit tujuh setengah meter, ada pangkalan buah dan pasar Sadovod di dekatnya , Anda bisa jalan kaki ke Aeroexpress, ada basement di bawah apartemen 1 meter, di atas apartemen ada loteng yang nyaman untuk observasi astronomi. Vasya memahami bahwa fitur ini menaikkan harga apartemennya, tetapi tidak untuk dirinya sendiri. Dan dia memutuskan untuk membeli apartemen Petya, dan menjual apartemennya. Tapi menjualnya untuk membeli apartemen Petya, dan bukan hanya. Dalam bahasa makelar, ini disebut - "Alternatif dipilih."
Sekarang mari kita lihat situasi ini dari sisi Petya. Faktanya Petya juga tidak tertarik untuk duduk di atas uang yang terdepresiasi, dia menjual apartemen untuk membeli apartemen di kota elf Valinor, tetapi dia belum melihat yang mana. Dalam bahasa makelar, ini disebut - "Berurusan dengan alternatif."
Dua elf Middle-earth, Maglor dan Maedhros, memiliki real estat yang sesuai (kriteria Petit) di kota Valinor, yang segera dijual, karena mereka dikirim untuk melayani Melkor. Dalam bahasa agen penjual, ini disebut - "Penjualan gratis".
Jadi, Vasya menemukan klien Serezha. Kini, Petya menemukan dua opsi yang cocok untuknya di kota Valinor. Kita akan membuat kesepakatan. Asumsikan untuk kesederhanaan bahwa tidak ada peserta dalam transaksi yang menggunakan hipotek dan tidak memiliki pemilik saham kecil. Dengan demikian, tindakan berikut sekarang harus dilakukan:
1. Seryozha memberikan uang kepada Petya.
2. Vasya memberikan apartemennya kepada Seryozha.
3. Petya memberikan apartemennya kepada Vasya.
4. Maglor atau Maedhros menyerahkan apartemen mereka di Valinor kepada Petya dan menerima uang Seryozha.
5. Malkor dan Maedhros pergi ke Mordor untuk melayani Melkor.
Sebaiknya transfer skrip berikut ke Rosreestr untuk dieksekusi:
MULAI TRANSAKSI
Berikan apartemen Vasya ke Seryozha.
Berikan apartemen Petit ke Vasya.
mulai
Berikan apartemen Malkor ke Petya
Berikan uang Seryozha ke Malkor
JIKA_ERROR:
Berikan apartemen Maedhros ke Petya
Berikan uang Seryozha kepada Maedhros
akhir
KOMIT TRANSAKSI
Ini adalah skrip transaksi yang disederhanakan dengan alternatif, dengan asumsi bahwa semua apartemen memiliki satu pemilik dewasa (dan mampu), bahwa harganya sama, dan bahwa agen penjual (jika ada) dibayar terlepas dari tahapan transaksi.
Namun, Rosreestr tidak mendukung transaksionalitas. Semua tindakan akan dilakukan secara berurutan dan mandiri, satu demi satu, tanpa membatalkan transaksi secara keseluruhan jika salah satunya belum diselesaikan. Maksimal yang dapat dicapai - mengingat Rosreestr dan MFC tidak bekerja dengan transfer uang tunai - adalah dengan memasukkan uang ke dalam sel bank, dengan syarat akses ke mereka oleh Vasya, Petya, Serezha (jika tidak ada transaksi yang terdaftar sama sekali), dan aktor lain, setelah presentasi perjanjian yang didaftarkan oleh Rosreestr. (Dan omong-omong, bank tidak memverifikasi keaslian kontrak secara independen, yaitu, mereka mempercayai keaslian surat-surat peserta dalam transaksi).
Selain risiko tidak menyelesaikan transaksi secara penuh, masalah lainnya adalah jika peserta lain dapat pindah ke perumahan barunya tanpa menunggu pendaftaran penuh (halo, soal kurang bayar tagihan listrik!), Maglor dan Maedhros tidak akan segera pergi untuk melayani Melkor, dan mungkin Maglor tidak akan bisa memegang Silmaril di tangannya, dia tidak akan punya waktu. Transaksi real estat dilakukan secara berurutan, dan pemrosesan setiap transaksi akan memakan waktu setidaknya 9 hari kerja.
Selain itu, Rosreestr tidak mendukung pembebanan perumahan yang sedang dibangun di bawah DDU, tetapi bisa saja, ini merupakan tindakan dasar sehubungan dengan masa depan yang sederhana.
Sekarang mari beralih ke kekurangan dan Daftar Keinginan saya tentang DBMS
1) Yang pertama adalah kurangnya sistem kontrol versi. Jika dari sisi Delphi saya mengembangkan di kotak pasir saya, dan perubahan yang saya buat tidak akan terlihat oleh programmer lain sampai mereka berkomitmen, maka tidak demikian halnya dengan DBMS. Dan bahkan jika saya dipercaya dengan akses penuh (setidaknya dalam kerangka tugas yang diberikan kepada saya) ke database pertempuran, dan ini terjadi, saya tidak dapat mengembangkannya. Saat saya men-debug, semuanya akan runtuh. Apakah zaman batu ini? Buat kotak pasir untuk pengembang.
2) Yang kedua adalah kurangnya tabel standar pra-instal yang menggambarkan dunia nyata. Setiap perusahaan tempat saya bekerja memiliki format tabelnya sendiri yang menjelaskan nama-nama (dalam bahasa Rusia dan (setidaknya) bahasa Inggris, dalam berbagai kasus bahasa Rusia) dari dua belas bulan!
3) Ketiga - dan di sini saya akan menggunakan terminologi Oracle - tidak ada cara untuk memanggil skrip Sisipkan atau Perbarui sederhana yang menggunakan Pengembalian, cara kami memanggil Pilih. Mungkin ini bukan masalah Oracle, tetapi masalah antarmuka Delphi + Oracle.
4) Keempat, kebutuhan untuk menetapkan kekuatan pada prosedur dan fungsi yang saya buat di mana saya tidak ingin melakukan ini. Saya tidak ingin menyetel, lalu mengubah, izin pengguna untuk prosedur dan fungsi. Mengapa, jika saya tidak secara eksplisit menulis Hibah, dapatkah sistem itu sendiri melihat objek yang terlibat, dan, sesuai dengan hak untuk bertindak dengannya, memberi atau tidak kepada pengguna tertentu hak untuk memanggil fungsi tersebut? Saya siap menulis satu kata kunci untuk ini saat menulis fungsi dan prosedur. Atau, lebih baik lagi, biarkan pengguna memulai eksekusi, dan jika cabang algoritme mengarahkannya ke permintaan yang haknya tidak dimiliki pengguna, dia akan membuangnya dengan kesalahan.
Sumber: www.habr.com