Kunden interagerar med databasen.
FrÄn webbplatsen , mÄlare Jonathan Tiong.
Förutom att jag Àr programmerare (frÀmst inom Delphi och olika databashanteringssystem, senaste tiden ORACLE, samt lite PHP) har jag ett intresse för att köpa och sÀlja lÀgenheter. Jag köper en lÀgenhet under byggprocessen frÄn en relativt pÄlitlig byggherre till ett bra pris (för nÀrvarande Àr en sÄdan byggherre Samoljet, lÀgenheter nÀra m. Nekrasovka sÀljs), vÀntar pÄ att huset ska fÀrdigstÀllas (ofta tvÄ Är senare, nÄgot som hÀnder med billigare erbjudanden), renoverar den och sÀljer sedan till 95-100% av dess marknadspris.
SÄ jag, precis som alla andra, har stött pÄ problemet med att Rosreestr inte har transaktionalitet.
Problemet med att Rosreestr saknar transaktionalitet vid affÀrer
Inom programmering kallas det 'Transaktion', och inom fastigheter Àr det 'AffÀr med alternativ' (och dessutom, som en del av det, 'Avtal om bankfack'), och dÀr Àr allt lite mer komplicerat. Jag förklarar.
Vasya kom för att titta pÄ lÀgenheten som Petya sÀljer. Vasya gillade allt, Àven priset, men han har inga pengar. SÄ börjar vÄr historia.
Vasya Ă€ger en fastighet som har vissa vĂ€rden som inte Ă€r sĂ€rskilt viktiga för honom â i grannhuset bodde Lomonosov, takhöjden Ă€r sju och en halv meter, det ligger en frukt- och grönsaksmarknad nĂ€ra, man kan gĂ„ till Aeroexpress till fots, under lĂ€genheten finns en kĂ€llare som Ă€r en meter hög, och ovanför lĂ€genheten finns en vind som Ă€r lĂ€mplig för astronomiska observationer. Vasya inser att dessa egenskaper ökar vĂ€rdet pĂ„ hans lĂ€genhet, men inte för honom personligen. Och han beslutar sig för att köpa Petyas lĂ€genhet och sĂ€lja sin egen. Men sĂ€ljandet Ă€r just för att kunna köpa Petyas lĂ€genhet, inte bara för att sĂ€lja. PĂ„ mĂ€klarsprĂ„k kallas det för 'Alternativet Ă€r valt'.
Nu ser vi pĂ„ situationen frĂ„n Petyas perspektiv. Faktum Ă€r att Petya heller inte Ă€r intresserad av att ha pengar som tappar i vĂ€rde. Han sĂ€ljer lĂ€genheten för att kunna köpa en lĂ€genhet i den elfiska staden Valinor, men vilken specifikt â har han inte tittat pĂ„ Ă€nnu. PĂ„ mĂ€klarsprĂ„k kallas det för 'AffĂ€r med alternativ'.
TvÄ alver frÄn MidgÄrd, Maglor och Maedros, har ett lÀmpligt (enligt Petes kriterier) fastighet i staden Valinor som de snabbt sÀljer, eftersom de ska tjÀna Melkor. PÄ mÀklarens sprÄk kallas det för - "Fri försÀljning".
SÄ, Vasja hittar sin kund Sergej. Nu hittar Petja tvÄ alternativ i Valinor som passar honom. LÄt oss gÄ vidare till att upprÀtta affÀren. Anta för enkelhetens skull att ingen av parterna i affÀren anvÀnder bolÄn och att det inte finns nÄgra omyndiga delÀgare. SÄ hÀr bör följande ÄtgÀrder genomföras:
1. Sergej ger pengarna till Petja.
2. Vasja ger sin lÀgenhet till Sergej.
3. Petja ger sin lÀgenhet till Vasja.
4. Antingen Maglor eller Maedros ger sin lÀgenhet i Valinor till Petja och fÄr Sergejs pengar.
5. Malcor och Maedros gÄr till Mordor för att tjÀna Melkor.
Det skulle vara idealiskt att överlÀmna följande skript till LantmÀteriet för utförande:
START TRANSACTION
Vasjas lÀgenhet ska överlÀmnas till Sergej.
Petjas lÀgenhet ska överlÀmnas till Vasja.
begin
Malcors lÀgenhet ska överlÀmnas till Petja.
Sergejs pengar ska överlÀmnas till Malcor.
OM_FEL:
Maedros lÀgenhet ska överlÀmnas till Petja.
Sergejs pengar ska överlÀmnas till Maedros.
end
COMMIT TRANSACTION
Detta Àr ett förenklat skript för affÀren med ett alternativ, som förutsÀtter att alla lÀgenheter har en vuxen (och kapabel) Àgare, att deras vÀrden Àr lika, och att provisionsavgifter till mÀklare (om de finns) betalas oberoende av affÀrens steg.
Men, LantmÀteriet stöder inte transaktionshantering. Alla ÄtgÀrder kommer att utföras sekventiellt och oberoende av varandra, utan möjlighet att Äterföra transaktionen om en av dem misslyckas. Det maximala man kan uppnÄ - med tanke pÄ att LantmÀteriet och MFC inte arbetar med överlÀmning av kontanter - Àr att deponera pengar i ett bankfack, med villkor för Ätkomst för Vasja, Petja, Sergej (om ingen affÀr registrerats), och andra berörda parter, pÄ grund av registrerade kontrakt frÄn LantmÀteriet. (Och för övrigt, banker utför inte sjÀlva en autenticitetskontroll av kontrakt, det vill sÀga de litar pÄ Àktheten av dokumenten frÄn affÀrens parter.)
Förutom riskerna med ofullstÀndig genomförande av transaktionen finns det ett annat problem. Om andra deltagare kan flytta in i sina nya bostÀder utan att vÀnta pÄ den fullstÀndiga registreringen (hej, frÄgan om otillrÀcklig betalning av serviceavgifter!), dÄ kommer Maglor och Maedhros inte snart att gÄ för att tjÀna Melkor, och kanske kommer Maglor inte att kunna hÄlla silmarillerna i sina hÀnder, han hinner helt enkelt inte. FastighetsaffÀrer genomförs sekventiellt, och registreringen av varje affÀr kommer att ta minst 9 arbetsdagar.
Dessutom stöder Rosreestr inte belastningen av bostÀder som byggs enligt DDU, men det skulle kunna vara ett enkelt steg i samband med en enkel futures.
Nu gÄr vi vidare till nackdelarna och mina önskemÄl om DBMS.
1) För det första Ă€r det avsaknaden av versionskontrollsystem. Om jag utvecklar i min sandlĂ„da frĂ„n Delphi och de Ă€ndringar jag gör inte kommer att synas för andra programmerare förrĂ€n de Ă€r committade, Ă€r det inte sĂ„ med DBMS. Ăven om jag har full (Ă„tminstone inom ramarna för den uppgift jag har fĂ„tt) tillgĂ„ng till produktionsdatabasen, som faktiskt förekommer, kan jag inte utveckla pĂ„ den. Medan jag felsöker kommer allt att kollapsa. Vad Ă€r det hĂ€r, stenhĂ„rt Ă„lder??? Skapa en sandlĂ„da för utvecklarna.
2) För det andra Àr det avsaknaden av förinstallerade standardiserade tabeller som beskriver den verkliga vÀrlden. I varje företag dÀr jag har arbetat finns det sitt eget format för tabellen som beskriver namnen (pÄ ryska och (Ätminstone) engelska sprÄken, i olika kasus av det ryska sprÄket) för tolv mÄnader!
3) För det tredje - och hÀr anvÀnder jag ordboken frÄn Oracle - finns det ingen möjlighet att anropa ett enkelt Insert- eller Update-skript som anvÀnder Returning, precis som vi anropar Select. Kanske Àr det inte Oracles problem, utan ett problem med kopplingen mellan Delphi och Oracle.
4) Det fjÀrde Àr behovet av att tilldela de procedurer och funktioner jag skapar rÀttigheter dÀr jag inte vill göra det. Jag vill inte behöva specificera och sedan Àndra anvÀndarrÀttigheter för procedurer och funktioner. Varför, om jag inte tydligt har angett behörigheter, kan inte systemet sjÀlvt titta pÄ de involverade objekten och, beroende pÄ rÀttigheterna för ÄtgÀrder med dem, tilldela eller inte tilldela vissa anvÀndare rÀtten att anropa funktionen? Jag Àr beredd att skriva en nyckelord för detta nÀr jag skapar funktioner och procedurer. Eller, Ànnu bÀttre, lÄt anvÀndaren börja utföra ÄtgÀrden, och om algoritmens gren leder dem till en begÀran som anvÀndaren inte har rÀtt till, sÄ avbryts det med ett felmeddelande.
KĂ€lla: habr.com
