De klant ynteraksje mei de databank.
Fan de side , troch Jonathan Tiong.
Neist it feit dat ik bin in programmeur (benammen Delphi + allerhanne ferskillende DBMSs, koartlyn ORACLE, + in bytsje PHP), Ik haw in hobby - keapje en ferkeapje apparteminten. Ik keapje in appartemint yn 'e boufaze fan in min of mear betroubere ûntwikkelder foar in goede priis (bygelyks, no is Samolet sa'n ûntwikkelder, apparteminten tichtby Nekrasovka metrostasjon binne te keap), wachtsje oant it hûs wurdt levere (faak twa jierren letter, dit bart mei goedkeape oanbiedingen), Ik renovearje it en dan ferkeapje it foar 95-100% fan syn merk priis.
Dat, ik (lykas elkenien) waard konfrontearre mei it probleem fan RosReestr's gebrek oan transaksjonaliteit.
It probleem fan Rosreestr syn gebrek oan transaksje transaksjes
Yn programmearring is it "Transaksje", en yn ûnreplik guod is it "Transaksje mei Alternative" (en ek, as ûnderdiel fan it, "Safe Deposit Box Agreement"), en it is in bytsje mear yngewikkelder. Ik sis dy.
Vasya kaam om it appartemint te besjen dat Petya ferkocht. En Vasya echt leuk alles, ynklusyf de priis, mar Vasya hat gjin jild. Dit is hoe't ús ferhaal begjint.
Vasya hat syn eigen eigendom, dat hat wat wearden dy't net bysûnder nedich foar him - Lomonosov wenne yn it oanbuorjende hûs, plafond hichte is sân en in heale meter, der is in fruit en griente basis en de Sadovod merk tichtby, kinne jo rinne op 'e Aeroexpress, ûnder it appartemint is d'r in kelder mei in hichte fan 1 meter, d'r is in souder boppe it appartemint handich foar astronomyske observaasjes. Vasya begrypt dat dizze funksjes de priis fan syn appartemint ferheegje, mar net foar himsels. En hy beslút om Petya's appartemint te keapjen en syn eigen appartemint te ferkeapjen. Mar ferkeapjen krekt om Petya's appartemint te keapjen, en net allinich. Yn 'e taal fan realtors wurdt dit "In alternatyf is selektearre."
Litte wy no nei dizze situaasje fan Petya's kant sjen. It feit is dat Petya ek net ynteressearre is om te sitten op ôfskriuwing fan jild, hy ferkeapet it appartemint om sels in appartemint te keapjen yn 'e alvestêd Valinor, mar hy hat noch net sjoen hokker. Yn 'e taal fan realtors wurdt dit in "Deal mei in alternatyf" neamd.
Twa elven fan Midden-ierde, Maglor en Maedhros, hawwe geskikt (nei Petya's kritearia) ûnreplik guod yn 'e stêd Valinor, dat driuwend ferkocht wurdt, om't se Melkor sille tsjinje. Yn 'e taal fan realtors wurdt dit "Free Sale" neamd.
Sa, Vasya fynt in klant, Seryozha. No fynt Petya twa geskikte opsjes foar him yn 'e stêd Valinor. Wy steane op it punt om de deal te finalisearjen. Lit ús foar de ienfâld oannimme dat gjin fan 'e partijen by de transaksje in hypoteek brûkt en gjin minderjierrigen as oandielhâlders hat. Sa moatte de folgjende aksjes no wurde útfierd:
1. Seryozha jout jild oan Petya.
2. Vasya jout syn appartemint oan Seryozha.
3. Petya jout syn appartemint oan Vasya.
4. Of Maglor of Maedhros oerdrage harren appartemint yn Valinor nei Peta en ûntfange Seryozha syn jild.
5. Malkor en Maedhros geane nei Mordor om Melkor te tsjinjen.
It soe ideaal wêze om it folgjende skript oan Rosreestr yn te tsjinjen foar útfiering:
START TRANSAKJE
Jou it appartemint fan Vasya oan Seryozha.
Jou it appartemint fan Petya oan Vasya.
begjinne
Jou it appartemint fan Malkor oan Petya
Jou Seryozha's jild oan Malkor
IF_ERROR:
Jou it appartemint fan Maedhros oan Petya
Jou Seryozha's jild oan Maedhros
ein
COMMIT TRANSAKJE
Dit is in ferienfâldige transaksjeskript mei in alternatyf, dat oannimt dat alle apparteminten ien folwoeksen (en bekwame) eigner hawwe, dat har wearden lykweardich binne, en dat realtors (as der binne) wurde betelle nettsjinsteande de stadia fan 'e transaksje.
Rosreestr stipet lykwols gjin transaksjonaliteit. Alle aksjes sille opienfolgjend en ûnôfhinklik wurde útfierd, ien nei de oare, sûnder de transaksje as gehiel werom te rôljen as ien fan har mislearret. It maksimum dat kin wurde berikt - jûn dat Rosreestr en de MFC net wurkje mei de oerdracht fan cash - is it jild yn in feilige boarch te deponearje, mei de betingsten foar tagong ta it troch Vasya, Petya, Seryozha (as gjin transaksje is hielendal registrearre), en oare akteurs, op presintaasje fan kontrakten registrearre troch Rosreestr. (En trouwens, banken ferifiearje net selsstannich de echtheid fan kontrakten, dat is, se fertrouwe de echtheid fan 'e papieren fan' e partijen by de transaksje).
Njonken de risiko's fan ûnfolsleine foltôging fan 'e transaksje, is in oar probleem dat as oare dielnimmers yn har nije hûs kinne ferhúzje sûnder te wachtsjen op folsleine registraasje (hallo, it probleem fan ûnderbetelling fan nutsbedriuwen!), Dan sille Maglor en Maedhros net gau nei Melkor tsjinje, en miskien sil Maglor net by steat wêze, hy sil gewoan gjin tiid hawwe om de Silmarils yn 'e hannen te hâlden. Transaksjes foar unreplik guod wurde sequentially útfierd, en de útfiering fan elke transaksje sil op syn minst 9 wurkdagen duorje.
Dêrneist Rosreestr net stipet de besuniging fan wenningbou wurdt boud ûnder de DDU, mar it koe, dit is in elemintêre aksje yn relaasje ta in ienfâldige futures.
Litte wy no oergean nei de tekoarten en myn winsken oer de DBMS
1) De earste is it ûntbrekken fan in ferzjekontrôlesysteem. As ik oan 'e Delphi-kant ûntwikkelje yn myn eigen sânbak, en de wizigingen dy't ik meitsje sille net ferskine foar oare programmeurs oant se ynsette, dan is dit net it gefal mei de DBMS. En sels as ik fertroud bin mei folsleine (op syn minst binnen it berik fan wat nedich is foar de taak dy't my tawiisd is) tagong ta de bestridingsdatabank, en dit bart, kin ik der net op ûntwikkelje. Wylst ik debuggen bin, sil alles ynstoarte. Wat is dit foar stientiid??? Meitsje in sânbak foar ûntwikkelders.
2) De twadde is it gebrek oan foarôf definieare standerdisearre tabellen dy't de echte wrâld beskriuwe. Elk bedriuw dêr't ik foar wurke haw, hat in eigen tabelformaat dy't de nammen (yn Russysk en (op syn minst) Ingelsk, yn ferskate gefallen fan Russysk) beskriuwt fan tolve moannen!
3) Tredde - en hjir sil ik Oracle-terminology brûke - d'r is gjin manier om in ienfâldich Insert- of Update-skript te neamen dat Returning brûkt, deselde manier as wy Select neame. Miskien binne dit gjin Oracle-problemen, mar problemen by de ynterface fan Delphi + Oracle.
4) Fjirde - de needsaak om foegen ta te jaan oan de prosedueres en funksjes dy't ik meitsje wêr't ik dit net dwaan wol. Ik wol gjin brûkersrjochten ynstelle en dan feroarje foar prosedueres en funksjes. Wêrom, as ik net eksplisyt skreaun Subsydzjes, koe it systeem sels net sjen op de belutsen objekten, en, yn oerienstimming mei de rjochten om te hanneljen mei harren, jaan of net bepaalde brûkers it rjocht om te neamen in funksje? Ik bin ree om hjir ien kaaiwurd foar te skriuwen by it skriuwen fan funksjes en prosedueres. Of, noch better, lit de brûker de útfiering begjinne, en as de algoritme-tûke him liedt ta in fersyk dêr't de brûker gjin rjochten foar hat, sil hy it útsmite mei in flater.
Boarne: www.habr.com