Pendhaftaran wishes kanggo DBMS mangsa, uga kanggo Rosreestr ing syarat-syarat transactionality

Klien sesambungan karo database.
Saka situs web http://corchaosis.ru, dening Jonathan Tiong.

Saliyane kasunyatan sing aku programmer (utamané Delphi + kabeh limo DBMSs beda, bubar ORACLE, + PHP sethitik), Aku duwe hobi - tuku lan ngedol Apartemen. Aku tuku apartemen sajrone tahap konstruksi saka pangembang sing luwih dipercaya kanthi rega sing apik (contone, saiki Samolet dadi pangembang kasebut, apartemen cedhak stasiun metro Nekrasovka didol), ngenteni omah dikirim (asring loro taun mengko, mengkono karo tawaran inexpensive), Aku ndandani lan banjur ngedol kanggo 95-100% saka rega pasar.

Dadi, aku (kaya wong liya) ngadhepi masalah kekurangan transaksi RosReestr.

Masalah kekurangan transaksi transaksional Rosreestr

Ing program iku "Transaksi", lan ing real estate iku "Transaksi karo Alternatif" (lan uga, minangka bagéan saka, "Aman Deposit Box Agreement"), lan iku sethitik liyane rumit. Aku pitutur marang kowe.

Vasya teka kanggo ndeleng apartemen sing didol Petya. Lan Vasya pancene seneng kabeh, kalebu rega, nanging Vasya ora duwe dhuwit. Mangkene crita kita diwiwiti.

Vasya duwe properti dhewe, sing duwe sawetara nilai sing ora perlu kanggo dheweke - Lomonosov manggon ing omah tetanggan, dhuwur langit-langit pitu setengah meter, ana basis woh lan sayuran lan pasar Sadovod. ing cedhak, sampeyan bisa mlaku ing Aeroexpress, ing ngisor apartemen ana ruang paling ngisor kanthi dhuwur 1 meter, ana loteng ing ndhuwur apartemen sing trep kanggo pengamatan astronomi. Vasya ngerti yen fitur-fitur kasebut nambah rega apartemen, nanging ora kanggo awake dhewe. Lan mutusake kanggo tuku apartemen Petya lan ngedol apartemen dhewe. Nanging adol kanthi tepat kanggo tuku apartemen Petya, lan ora mung. Ing basa makelar, iki diarani "Alternatif wis dipilih."

Saiki ayo padha ndeleng kahanan iki saka sisih Petya. Kasunyatane Petya uga ora kasengsem lungguh ing dhuwit nyusut, dheweke ngedol apartemen kanggo tuku apartemen ing kutha elf Valinor, nanging dheweke durung ndeleng sing endi. Ing basa makelar, iki diarani "Deal karo alternatif."

Two elves Middle-earth, Maglor lan Maedhros, wis cocok (kanggo kritéria Petya) real estate ing kutha Valinor, kang urgently didol, lagi arep ngawula Melkor. Ing basa Realtors iki disebut "Free Sale".

Dadi, Vasya nemokake klien, Seryozha. Saiki, Petya nemokake rong pilihan sing cocog kanggo dheweke ing kutha Valinor. Kita bakal ngrampungake kesepakatan kasebut. Ayo kita nganggep kanthi gampang yen ora ana pihak ing transaksi kasebut nggunakake hipotek lan ora duwe bocah cilik minangka pemilik saham. Mangkono, tumindak ing ngisor iki saiki kudu ditindakake:
1. Seryozha menehi dhuwit marang Petya.
2. Vasya menehi apartemen marang Seryozha.
3. Petya menehi apartemen marang Vasya.
4. Maglor utawa Maedhros nransfer apartemen ing Valinor menyang Peta lan nampa dhuwit Seryozha.
5. Malkor lan Maedhros menyang Mordor kanggo ngawula Melkor.

Luwih becik ngirim skrip ing ngisor iki menyang Rosreestr kanggo eksekusi:

MULAI TRANSAKSI
Menehi apartemen Vasya kanggo Seryozha.
Menehi apartemen Petya kanggo Vasya.
miwiti
Menehi apartemen Malkor kanggo Petya
Menehi dhuwit Seryozha kanggo Malkor
IF_ERROR:
Menehi apartemen Maedhros kanggo Petya
Menehi dhuwit Seryozha marang Maedhros
ends
TRANSAKSI KOMITMEN

Iki minangka skrip transaksi sing disederhanakake kanthi alternatif, sing nganggep yen kabeh apartemen duwe siji pemilik sing diwasa (lan nduweni kemampuan), sing nilaine padha, lan sing makelar (yen ana) dibayar preduli saka tahapan transaksi kasebut.

Nanging, Rosreestr ora ndhukung transactionality. Kabeh tumindak bakal dileksanakake sequentially lan independen, siji sawise liyane, tanpa muter maneh transaksi minangka kabèh yen salah siji saka wong-wong mau gagal. Maksimum sing bisa digayuh - yen Rosreestr lan MFC ora bisa nindakake transfer awis - yaiku kanggo nyetop dhuwit ing kothak simpenan aman, kanthi syarat akses menyang Vasya, Petya, Seryozha (yen ora ana transaksi. kadhaptar ing kabeh), lan aktor liyane, nalika presentation saka kontrak kedhaftar dening Rosreestr. (Lan kanthi cara, bank-bank ora independen verifikasi keaslian kontrak, yaiku, padha dipercaya keaslian saka makalah saka pihak kanggo transaksi).

Saliyane risiko transaksi sing ora rampung, masalah liyane yaiku yen peserta liyane bisa pindhah menyang omah anyar tanpa ngenteni registrasi lengkap (halo, masalah kurang mbayar tagihan sarana!), banjur Maglor lan Maedhros ora bakal langsung menyang. ngawula Melkor, lan mbok menawa Maglor ora bakal bisa kanggo dheweke mung ora duwe wektu kanggo terus Silmarils ing tangané. Transaksi real estate ditindakake kanthi urutan, lan eksekusi saben transaksi bakal paling sethithik 9 dina kerja.

Kajaba iku, Rosreestr ora ndhukung encumbrance saka omah kang dibangun ing DDU, nanging bisa, iki tumindak dhasar ing hubungan kanggo berjangka prasaja.

Saiki ayo nerusake menyang kekurangan lan kekarepanku babagan DBMS

1) Kapisan yaiku kekurangan sistem kontrol versi. Yen ing sisih Delphi aku berkembang ing kothak wedhi dhewe, lan owah-owahan aku ora bakal katon kanggo programer liyane nganti padha setya, banjur iki ora cilik karo DBMS. Lan sanajan aku dipercaya karo lengkap (paling ora ing orane katrangan saka apa sing perlu kanggo tugas diutus kanggo kula) akses kanggo database pertempuran, lan mengkono, Aku ora bisa berkembang ing. Nalika aku debugging, kabeh bakal ambruk. Zaman Batu opo iki??? Nggawe kothak wedhi kanggo pangembang.

2) Kapindho yaiku kekurangan tabel standar sing wis ditemtokake sing nggambarake jagad nyata. Saben perusahaan sing aku kerjakake duwe format tabel dhewe sing nggambarake jeneng (ing basa Rusia lan (paling ora) Inggris, ing macem-macem kasus Rusia) rolas wulan!

3) Katelu - lan ing kene aku bakal nggunakake terminologi Oracle - ora ana cara kanggo nelpon Insert utawa Update script prasaja sing nggunakake Returning, kanthi cara sing padha kita nelpon Pilih. Mbok iki ora masalah Oracle, nanging masalah ing antarmuka Delphi + Oracle.

4) Papat - perlu kanggo nemtokake kakuwasan kanggo tata cara lan fungsi aku nggawe ngendi aku ora pengin nindakake iki. Aku ora pengin nyetel banjur ngganti ijin pangguna kanggo prosedur lan fungsi. Apa, yen aku ora tegas nulis Grants, ora bisa sistem dhewe katon ing obyek melu, lan, miturut hak kanggo tumindak karo wong-wong mau, menehi utawa ora kedhaftar tartamtu hak kanggo nelpon fungsi? Aku siyap nulis siji tembung kunci kanggo iki nalika nulis fungsi lan tata cara. Utawa, malah luwih apik, ayo pangguna miwiti eksekusi, lan yen cabang algoritma ndadékaké dheweke menyang panjalukan sing pangguna ora duwe hak, dheweke bakal mbuwang kanthi kesalahan.

Source: www.habr.com