Miaj deziroj al la DBMS de la estonteco, same kiel al Rosreestr laŭ transakco

Miaj deziroj al la DBMS de la estonteco, same kiel al Rosreestr laŭ transakco
La kliento interagas kun la datumbazo.
De la retejo http://corchaosis.ru, de Jonathan Tiong.

Krom tio, ke mi estas programisto (ĉefe Delphi + ĉiaj diversaj DBMS-oj, lastatempe ORACLE, + iom PHP), mi havas ŝatokupon - aĉeti kaj vendi apartamentojn. Mi aĉetas apartamenton dum la konstrustadio de pli-malpli fidinda programisto je bona prezo (ekzemple, nun Samolet estas tia programisto, apartamentoj proksime de la metrostacio Nekrasovka estas vendataj), atendas la liveradon de la domo (ofte du jarojn poste, tio okazas kun malmultekostaj ofertoj), mi renovigas ĝin kaj poste vendas ĝin kontraŭ 95-100% de ĝia merkata prezo.

Do, mi (kiel ĉiuj aliaj) alfrontis la problemon de la manko de transakco de RosReestr.

La problemo de la manko de transakciaj transakcioj de Rosreestr

En programado ĝi estas "Transakcio", kaj en nemoveblaĵoj estas "Transakcio kun Alternativo" (kaj ankaŭ, kiel parto de ĝi, "Interkonsento pri Sekura Deponejo"), kaj ĝi estas iom pli komplika. Mi diras al vi.

Vasja venis por rigardi la apartamenton, kiun Petja vendis. Kaj Vasja tre ŝatis ĉion, inkluzive de la prezo, sed Vasja ne havas monon. Tiel komenciĝas nia rakonto.

Vasja havas sian propran posedaĵon, kiu havas iujn valorojn, kiuj ne estas precipe necesaj por li - Lomonosov loĝis en la najbara domo, la plafono estas sep metroj kaj duono, estas bazo de fruktoj kaj legomoj kaj la Sadovod-merkato. proksime, vi povas promeni sur la Aeroexpress, sub la apartamento estas kelo kun alteco de 1 metro, estas subtegmento super la apartamento oportuna por astronomiaj observoj. Vasja komprenas, ke ĉi tiuj trajtoj pliigas la prezon de sia loĝejo, sed ne por li mem. Kaj li decidas aĉeti la loĝejon de Petya kaj vendi sian propran loĝejon. Sed vendi ĝuste por aĉeti la loĝejon de Petya, kaj ne nur. En la lingvo de nemoveblaĵoj, ĉi tio nomiĝas "Alternativo estis elektita."

Nun ni rigardu ĉi tiun situacion de la flanko de Petya. La fakto estas, ke Petja ankaŭ ne interesiĝas pri sidado sur malplivalorigo de mono, li vendas la loĝejon por aĉeti al si loĝejon en la elfa urbo Valinor, sed li ankoraŭ ne rigardis kiun. En la lingvo de nemoveblaĵoj, tio estas nomita "Interkonsento kun alternativo".

Du elfoj de Mez-Tero, Maglor kaj Maedhros, havas taŭgajn (laŭ la kriterioj de Petya) nemoveblaĵojn en la grandurbo de Valinor, kiu estas urĝe vendita, ĉar ili servos Melkor. En la lingvo de nemoveblistoj ĉi tio nomiĝas "Senpaga Vendo".

Do, Vasja trovas klienton, Seryozha. Nun, Petya trovas du taŭgajn opciojn por li en la grandurbo de Valinor. Ni estas finontaj la interkonsenton. Ni supozu por simpleco, ke neniu el la partioj al la transakcio uzas hipotekon kaj ne havas neplenaĝulojn kiel akciajn posedantojn. Tiel, la sekvaj agoj nun devas esti faritaj:
1. Seriozha donas monon al Petja.
2. Vasja donas sian loĝejon al Serjoĵa.
3. Petja donas sian loĝejon al Vasja.
4. Aŭ Maglor aŭ Maedhros transdonas sian loĝejon en Valinor al Peta kaj ricevas la monon de Seryozha.
5. Malkor kaj Maedhros iras al Mordor por servi Melkor.

Estus ideale sendi la sekvan skripton al Rosreestr por ekzekuto:

KOMENCU TRANSAKCIO
Donu la loĝejon de Vasja al Serjoĵa.
Donu la loĝejon de Petja al Vasja.
komenci
Donu la loĝejon de Malkor al Petja
Donu la monon de Seryozha al Malkor
IF_ERROR:
Donu la loĝejon de Maedhros al Petja
Donu la monon de Seryozha al Maedhros
fino
FIGAS TRANSAKTON

Ĉi tio estas simpligita transakcia skripto kun alternativo, kiu supozas, ke ĉiuj apartamentoj havas unu plenkreskan (kaj kapablan) posedanton, ke iliaj valoroj estas egalaj, kaj ke nemoveblistoj (se ekzistas) estas pagataj sendepende de la stadioj de la transakcio.

Tamen, Rosreestr ne subtenas transakciecon. Ĉiuj agoj estos faritaj sinsekve kaj sendepende, unu post la alia, sen retrorigi la transakcion entute se unu el ili malsukcesos. La maksimumo, kiu povas esti atingita - ĉar Rosreestr kaj la MFC ne funkcias kun la translokigo de kontantmono - estas deponi la monon en sekura deponejo, kun la kondiĉoj por aliro al ĝi de Vasya, Petya, Seryozha (se neniu transakcio). estas registrita entute), kaj aliaj aktoroj, sur prezento de kontraktoj registritaj de Rosreestr. (Kaj cetere, bankoj ne sendepende kontrolas la aŭtentikecon de kontraktoj, tio estas, ili fidas la aŭtentecon de la paperoj de la partioj al la transakcio).

Krom la riskoj de nekompleta kompletiĝo de la transakcio, alia problemo estas, ke se aliaj partoprenantoj povas translokiĝi en sian novan hejmon sen atendi plenan registriĝon (saluton, la afero de subpago de servaĵoj!), tiam Maglor kaj Maedhros ne baldaŭ iros al. servi Melkor, kaj eble Maglor ne povos li simple ne havos tempon por teni la Silmarils en siaj manoj. Transakcioj pri nemoveblaĵoj estas faritaj sinsekve, kaj la plenumo de ĉiu transakcio daŭros almenaŭ 9 labortagojn.

Krome, Rosreestr ne subtenas la ŝarĝon de loĝejoj konstruita sub la DDU, sed ĝi povus, ĉi tio estas elementa ago rilate al simpla estonteco.

Nun ni transiru al la mankoj kaj miaj deziroj pri la DBMS

1) La unua estas la manko de versio-kontrolsistemo. Se flanke de Delphi mi disvolviĝas en mia propra sablokesto, kaj la ŝanĝoj, kiujn mi faras, ne aperos al aliaj programistoj ĝis ili estos faritaj, tiam ĉi tio ne estas la kazo kun la DBMS. Kaj eĉ se mi estas fidata kun plena (almenaŭ en la amplekso de kio estas necesa por la tasko atribuita al mi) aliro al la batala datumbazo, kaj tio okazas, mi ne povas disvolvi sur ĝi. Dum mi elpurigas, ĉio disfalos. Kia ŝtonepoko ĉi tio estas??? Faru sablokeston por programistoj.

2) La dua estas la manko de antaŭdifinitaj normigitaj tabeloj priskribantaj la realan mondon. Ĉiu firmao, por kiu mi laboris, havas sian propran tabelformaton priskribantan la nomojn (en la rusa kaj (almenaŭ) la angla, en malsamaj kazoj de la rusa) de dek du monatoj!

3) Trie - kaj ĉi tie mi uzos Oracle-terminologion - ne estas maniero voki simplan Enmeti aŭ Ĝisdatigi skripton kiu uzas Returning, same kiel ni nomas Elektu. Eble ĉi tiuj ne estas Oracle-problemoj, sed problemoj ĉe la interfaco de Delphi + Oracle.

4) Kvara - la bezono atribui potencojn al la proceduroj kaj funkcioj, kiujn mi kreas, kie mi ne volas fari tion. Mi ne volas agordi kaj poste ŝanĝi uzantpermesojn por proceduroj kaj funkcioj. Kial, se mi ne eksplicite skribis Subvenciojn, la sistemo mem ne povus rigardi la koncernajn objektojn, kaj, konforme al la rajtoj agi kun ili, doni aŭ ne al certaj uzantoj la rajton voki funkcion? Mi pretas skribi unu ŝlosilvorton por ĉi tio kiam mi verkas funkciojn kaj procedurojn. Aŭ, eĉ pli bone, lasu la uzanton komenci ekzekuton, kaj se la algoritmobranĉo kondukas lin al peto, pri kiu la uzanto ne havas rajtojn, li forĵetos ĝin kun eraro.

fonto: www.habr.com

Aldoni komenton