Nakikipag-ugnayan ang kliyente sa database.
Mula sa site , ni Jonathan Tiong.
Bukod sa katotohanan na ako ay isang programmer (karamihan sa Delphi + lahat ng uri ng iba't ibang mga DBMS, kamakailang ORACLE, + isang maliit na PHP), mayroon akong libangan - bumili at magbenta ng mga apartment. Bumili ako ng isang apartment sa yugto ng konstruksiyon mula sa isang mas marami o hindi gaanong maaasahang developer sa isang masarap na presyo (halimbawa, ngayon si Samolet ay tulad ng isang developer, ang mga apartment na malapit sa Nekrasovka metro station ay ibinebenta), naghihintay ako na maibigay ang bahay (madalas makalipas ang dalawang taon, nangyayari ito sa mga murang alok), ginagawa ko ito sa pag-aayos at pagkatapos ay ibinebenta ito para sa 95-100% ng presyo nito sa merkado.
Kaya, ako (tulad ng iba) ay nakatagpo ng problema ng kawalan ng transaksyon ng RosReestr.
Ang problema ng kawalan ng transaksyon ng Rosreestr ng mga transaksyon
Sa programming na "Transaction" at sa real estate ito ay "Deal with alternative" (at gayundin, bilang bahagi nito, "Deposit box agreement"), at may mga bagay na medyo mas kumplikado. Sasabihin ko.
Dumating si Vasya upang tingnan ang apartment na ibinebenta ni Petya. At nagustuhan ni Vasya ang lahat, kasama ang presyo, ngunit walang pera si Vasya. Dito na magsisimula ang ating kwento.
Si Vasya ay may sariling pag-aari, na may ilang mga halaga na hindi partikular na kinakailangan para sa kanya - Si Lomonosov ay nanirahan sa isang kalapit na bahay, ang taas ng kisame ay pito at kalahating metro, mayroong isang base ng prutas at malapit na merkado ng Sadovod. , maaari kang maglakad sa Aeroexpress, mayroong isang basement sa ilalim ng apartment na 1 metro, sa itaas ng apartment ay may isang attic na maginhawa para sa mga obserbasyon ng astronomya. Naiintindihan ni Vasya na ang mga tampok na ito ay nagpapataas ng presyo ng kanyang apartment, ngunit hindi para sa kanyang sarili. At nagpasya siyang bilhin ang apartment ni Petya, at ibenta ang kanyang apartment. Ngunit upang ibenta ito upang makabili ng apartment ni Petya, at hindi lamang. Sa wika ng mga rieltor, ito ay tinatawag na - "Ang kahalili ay napili."
Ngayon tingnan natin ang sitwasyong ito mula sa panig ni Petya. Ang katotohanan ay hindi rin interesado si Petya na umupo sa pagpapababa ng pera, nagbebenta siya ng apartment upang makabili ng apartment sa elven city ng Valinor, ngunit hindi pa niya tinitingnan kung alin. Sa wika ng mga rieltor, ito ay tinatawag na - "Deal with an alternative."
Dalawang duwende ng Middle-earth, Maglor at Maedhros, ay may angkop (pamantayan ng Petit) na real estate sa lungsod ng Valinor, na agarang ibinebenta, dahil ipinadala sila upang maglingkod sa Melkor. Sa wika ng mga rieltor, ito ay tinatawag na - "Libreng pagbebenta".
Kaya, nakahanap si Vasya ng isang kliyente na si Serezha. Ngayon, nakahanap si Petya ng dalawang angkop na pagpipilian para sa kanya sa lungsod ng Valinor. Magkakaroon kami ng deal. Ipagpalagay para sa pagiging simple na wala sa mga kalahok sa transaksyon ang gumagamit ng isang mortgage at walang menor de edad na may-ari ng bahagi. Kaya, ang mga sumusunod na aksyon ay dapat maganap na ngayon:
1. Nagbibigay ng pera si Seryozha kay Petya.
2. Ibinigay ni Vasya ang kanyang apartment kay Seryozha.
3. Ibinigay ni Petya ang kanyang apartment kay Vasya.
4. Ibigay ni Maglor o Maedhros ang kanilang apartment sa Valinor kay Petya at tanggapin ang pera ni Seryozha.
5. Sina Malkor at Maedhros ay pumunta sa Mordor upang pagsilbihan si Melkor.
Mainam na ilipat ang sumusunod na script sa Rosreestr para sa pagpapatupad:
SIMULAN ANG TRANSAKSIYON
Ibigay ang apartment ni Vasya kay Seryozha.
Ibigay ang apartment ni Petit kay Vasya.
simulan
Ibigay ang apartment ni Malkor kay Petya
Ibigay ang pera ni Seryozha kay Malkor
IF_ERROR:
Ibigay ang apartment ni Maedhros kay Petya
Ibigay ang pera ni Seryozha kay Maedhros
dulo
KOMUNIDAD NG COMMIT
Ito ay isang pinasimpleng script ng transaksyon na may alternatibo, sa pag-aakalang ang lahat ng apartment ay may isang may-ari ng nasa hustong gulang (at may kakayahan), na ang kanilang mga presyo ay pantay, at ang mga rieltor (kung mayroon man) ay binabayaran anuman ang mga yugto ng transaksyon.
Gayunpaman, hindi sinusuportahan ng Rosreestr ang transactionality. Ang lahat ng mga aksyon ay isasagawa nang sunud-sunod at independiyente, isa-isa, nang hindi ibabalik ang transaksyon sa kabuuan kung ang isa sa mga ito ay hindi pa nakumpleto. Ang maximum na maaaring makamit - dahil ang Rosreestr at ang MFC ay hindi gumagana sa paglipat ng cash - ay ang paglalagay ng pera sa isang bank cell, na may mga kondisyon para sa pag-access sa kanila ng Vasya, Petya, Serezha (kung walang nakarehistrong transaksyon sa lahat), at iba pang mga aktor, sa pagtatanghal ng mga kasunduan na inirehistro ng Rosreestr. (At sa pamamagitan ng paraan, ang mga bangko ay hindi nakapag-iisa na nagpapatunay sa pagiging tunay ng mga kontrata, iyon ay, pinagkakatiwalaan nila ang pagiging tunay ng mga papeles ng mga kalahok sa transaksyon).
Bilang karagdagan sa mga panganib na hindi makumpleto ang transaksyon nang buo, ang isa pang problema ay kung ang ibang mga kalahok ay maaaring lumipat sa kanilang bagong pabahay nang hindi naghihintay ng buong pagpaparehistro (hello, ang tanong ng kulang sa pagbabayad ng mga bill ng utility!), kung gayon ang Maglor at Maedhros ay hindi sa lalong madaling panahon pumunta upang maglingkod Melkor, at marahil Maglor ay hindi magagawang upang hawakan ang Silmarils sa kanyang mga kamay, siya lamang ay hindi magkakaroon ng oras. Ang mga transaksyon sa real estate ay isinasagawa nang sunud-sunod, at ang pagproseso ng bawat transaksyon ay tatagal ng hindi bababa sa 9 na araw ng trabaho.
Bilang karagdagan, hindi sinusuportahan ng Rosreestr ang encumbrance ng housing under construction sa ilalim ng DDU, ngunit maaari itong, ito ay isang elementarya na aksyon na may kaugnayan sa isang simpleng futures.
Ngayon ay lumipat tayo sa mga pagkukulang at ang aking Wishlist tungkol sa DBMS
1) Ang una ay ang kakulangan ng isang version control system. Kung mula sa Delphi side ako ay nabubuo sa aking sandbox, at ang mga pagbabagong ginawa ko ay hindi lilitaw sa ibang mga programmer hanggang sa sila ay nakatuon, kung gayon ito ay hindi ganoon sa DBMS. At kahit na pinagkakatiwalaan ako ng buong (hindi bababa sa loob ng balangkas ng gawaing itinalaga sa akin) na pag-access sa database ng labanan, at nangyari ito, hindi ako makakabuo dito. Habang nagde-debug ako, babagsak ang lahat. Ano ang stone age na ito? Gumawa ng sandbox para sa mga developer.
2) Ang pangalawa ay ang kakulangan ng mga paunang naka-install na standardized na mga talahanayan na naglalarawan sa totoong mundo. Ang bawat kumpanyang pinagtrabahuan ko ay may sariling format ng talahanayan na naglalarawan sa mga pangalan (sa Russian at (hindi bababa sa) English, sa iba't ibang kaso ng Russian) ng labindalawang buwan!
3) Pangatlo - at dito gagamitin ko ang terminolohiya ng Oracle - walang paraan upang tumawag ng isang simpleng Insert o Update script na gumagamit ng Returning, ang paraan ng pagtawag natin sa Select. Marahil hindi ito mga problema sa Oracle, ngunit mga problema sa interface ng Delphi + Oracle.
4) Pang-apat, ang pangangailangang magtalaga ng mga kapangyarihan sa mga pamamaraan at pag-andar na nilikha ko kung saan hindi ko gustong gawin ito. Hindi ko gustong itakda, at pagkatapos ay baguhin, ang mga pahintulot ng user para sa mga pamamaraan at pag-andar. Bakit, kung hindi ko tahasang isinulat ang Grants, hindi ba maaaring tingnan ng system mismo ang mga kasangkot na bagay, at, alinsunod sa mga karapatang kumilos sa kanila, bigyan o hindi ang ilang partikular na user ng karapatang tumawag sa function? Handa akong magsulat ng isang keyword para dito kapag nagsusulat ng mga function at procedure. O, kahit na mas mabuti, hayaan ang user na simulan ang pagpapatupad, at kung ang sangay ng algorithm ay humahantong sa kanya sa isang kahilingan kung saan ang user ay walang mga karapatan, itatapon niya ito nang may error.
Pinagmulan: www.habr.com