Urimet e mia për DBMS të së ardhmes, si dhe për Rosreestr për sa i përket transaksioneve

Klienti ndërvepron me bazën e të dhënave.
Nga faqja http://corchaosis.ru, nga Jonathan Tiong.

Përveç faktit që jam programues (kryesisht Delphi + të gjitha llojet e DBMS-ve të ndryshme, së fundmi ORACLE, + pak PHP), kam një hobi - blerjen dhe shitjen e apartamenteve. Blej një apartament gjatë fazës së ndërtimit nga një zhvillues pak a shumë i besueshëm me një çmim të mirë (për shembull, tani Samolet është një zhvillues i tillë, apartamentet afër stacionit të metrosë Nekrasovka janë në shitje), pres që shtëpia të dorëzohet (shpesh dy vite më vonë, kjo ndodh me oferta të lira), e rinovoj dhe më pas e shes për 95-100% të çmimit të tregut.

Pra, unë (si gjithë të tjerët) u përballa me problemin e mungesës së transaksionit të RosReestr.

Problemi i mungesës së transaksioneve transaksionale të Rosreestr

Në programim është "Transaksion", dhe në pasuri të paluajtshme është "Transaksion me alternativë" (dhe gjithashtu, si pjesë e tij, "Marrëveshja e Safe Deposit Box"), dhe është pak më e ndërlikuar. po ju them.

Vasya erdhi për të parë apartamentin që Petya po shiste. Dhe Vasya me të vërtetë i pëlqeu gjithçka, përfshirë çmimin, por Vasya nuk ka para. Kështu fillon historia jonë.

Vasya ka pronën e tij, e cila ka disa vlera që nuk janë veçanërisht të nevojshme për të - Lomonosov jetonte në shtëpinë fqinje, lartësia e tavanit është shtatë metra e gjysmë, ka një bazë frutash dhe perimesh dhe tregu Sadovod afër, ju mund të ecni në Aeroexpress, nën apartament ka një bodrum me lartësi 1 metër, ka një papafingo sipër apartamentit të përshtatshëm për vëzhgime astronomike. Vasya e kupton që këto karakteristika rrisin çmimin e banesës së tij, por jo për veten e tij. Dhe ai vendos të blejë apartamentin e Petya dhe të shesë apartamentin e tij. Por duke shitur pikërisht për të blerë apartamentin e Petya, dhe jo vetëm. Në gjuhën e sekserëve, kjo quhet "Është zgjedhur një alternativë".

Tani le ta shohim këtë situatë nga ana e Petya. Fakti është se Petya gjithashtu nuk është i interesuar të ulet në zhvlerësimin e parave, ai po shet apartamentin për t'i blerë vetes një apartament në qytetin e kukudhëve të Valinor, por ai ende nuk ka parë se cilin. Në gjuhën e sekserëve, kjo quhet "Marrëveshje me një alternativë".

Dy kukudhët e Tokës së Mesme, Maglor dhe Maedhros, kanë pasuri të paluajtshme të përshtatshme (sipas kritereve të Petya) në qytetin e Valinorit, e cila shitet urgjentisht, pasi do t'i shërbejnë Melkorit. Në gjuhën e sekserëve kjo quhet "Shitje Falas".

Pra, Vasya gjen një klient, Seryozha. Tani, Petya gjen dy opsione të përshtatshme për të në qytetin e Valinor. Ne jemi gati të finalizojmë marrëveshjen. Le të supozojmë për thjeshtësi se asnjë nga palët në transaksion nuk përdor një hipotekë dhe nuk ka të mitur si pronarë aksionesh. Kështu, tani duhet të kryhen veprimet e mëposhtme:
1. Seryozha i jep para Petya.
2. Vasya i jep apartamentin e tij Seryozhës.
3. Petya i jep banesën e tij Vasya.
4. Ose Maglor ose Maedhros transferojnë banesën e tyre në Valinor te Peta dhe marrin paratë e Seryozhës.
5. Malkor dhe Maedhros shkojnë në Mordor për t'i shërbyer Melkorit.

Do të ishte ideale të dorëzoni skriptin e mëposhtëm në Rosreestr për ekzekutim:

FILLO TRANSAKSIONIN
Jepini Seryozhës apartamentin e Vasya.
Jepni banesën e Petya Vasya-s.
filloj
Jepini Petya-s apartamentin e Malkorit
Jepini Malkorit paratë e Seryozhës
IF_GABIM:
Jepni banesën e Maedhros Petya-s
Jepini paratë e Seryozhës Maedhros
fund
KRYERI TRANSAKSIONIN

Ky është një skenar i thjeshtuar transaksioni me një alternativë, e cila supozon se të gjitha apartamentet kanë një pronar të rritur (dhe të aftë), se vlerat e tyre janë të barabarta dhe se sekserët (nëse ka) paguhen pavarësisht nga fazat e transaksionit.

Sidoqoftë, Rosreestr nuk e mbështet transaksionalitetin. Të gjitha veprimet do të kryhen në mënyrë sekuenciale dhe të pavarur, njëri pas tjetrit, pa e rikthyer transaksionin në tërësi nëse njëri prej tyre dështon. Maksimumi që mund të arrihet - duke pasur parasysh që Rosreestr dhe MFC nuk punojnë me transferimin e parave - është depozitimi i parave në një kasafortë, me kushtet për qasje në të nga Vasya, Petya, Seryozha (nëse nuk ka transaksion është i regjistruar fare), dhe aktorë të tjerë, me paraqitjen e kontratave të regjistruara nga Rosreestr. (Dhe nga rruga, bankat nuk e verifikojnë në mënyrë të pavarur vërtetësinë e kontratave, domethënë, ata i besojnë origjinalitetit të letrave të palëve në transaksion).

Përveç rreziqeve të përfundimit jo të plotë të transaksionit, një problem tjetër është se nëse pjesëmarrësit e tjerë mund të zhvendosen në shtëpinë e tyre të re pa pritur regjistrimin e plotë (përshëndetje, çështja e nënpagesës së faturave të shërbimeve!), atëherë Maglor dhe Maedhros nuk do të shkojnë së shpejti në t'i shërbejë Melkorit dhe ndoshta Maglor nuk do të jetë në gjendje, ai thjesht nuk do të ketë kohë të mbajë Silmarilët në duart e tij. Transaksionet e pasurive të paluajtshme kryhen në mënyrë sekuenciale dhe ekzekutimi i çdo transaksioni do të zgjasë të paktën 9 ditë pune.

Për më tepër, Rosreestr nuk e mbështet barrën e banesave që po ndërtohen nën DDU, por mundet, ky është një veprim elementar në lidhje me një të ardhme të thjeshtë.

Tani le të kalojmë te mangësitë dhe dëshirat e mia në lidhje me DBMS

1) E para është mungesa e një sistemi të kontrollit të versionit. Nëse në anën e Delphi-t zhvilloj në sandboxin tim dhe ndryshimet që bëj nuk do t'u shfaqen programuesve të tjerë derisa të angazhohen, atëherë ky nuk është rasti me DBMS. Dhe edhe nëse më besohet aksesi i plotë (të paktën brenda fushës së asaj që është e nevojshme për detyrën që më është caktuar) në bazën e të dhënave luftarake, dhe kjo ndodh, unë nuk mund të zhvilloj në të. Ndërsa unë jam duke korrigjuar, gjithçka do të shembet. Cfare epoke e gurit eshte kjo??? Krijoni një sandbox për zhvilluesit.

2) E dyta është mungesa e tabelave të standardizuara të paracaktuara që përshkruajnë botën reale. Çdo kompani për të cilën kam punuar ka formatin e saj të tabelës që përshkruan emrat (në rusisht dhe (të paktën) anglisht, në raste të ndryshme të rusishtes) të dymbëdhjetë muajve!

3) Së treti - dhe këtu do të përdor terminologjinë e Oracle - nuk ka asnjë mënyrë për të thirrur një skript të thjeshtë Insert ose Update që përdor Returning, në të njëjtën mënyrë si ne e quajmë Select. Ndoshta këto nuk janë probleme të Oracle, por probleme në ndërfaqen e Delphi + Oracle.

4) Së katërti - nevoja për t'u dhënë kompetenca procedurave dhe funksioneve që unë krijoj aty ku nuk dua ta bëj këtë. Nuk dua të vendos dhe më pas të ndryshoj lejet e përdoruesit për procedurat dhe funksionet. Pse, nëse nuk do t'i shkruaja në mënyrë eksplicite Grantet, nuk mund të shikonte vetë sistemi objektet e përfshira dhe, në përputhje me të drejtat për të vepruar me to, t'u jepte ose jo përdoruesve të caktuar të drejtën për të thirrur një funksion? Unë jam gati të shkruaj një fjalë kyçe për këtë kur shkruaj funksione dhe procedura. Ose, edhe më mirë, le të fillojë ekzekutimin përdoruesi dhe nëse dega e algoritmit e çon atë në një kërkesë për të cilën përdoruesi nuk ka të drejta, ai do ta hedhë atë me një gabim.

Burimi: www.habr.com