Klienten interagerar med databasen.
Från sajten , av Jonathan Tiong.
Förutom att jag är programmerare (främst Delphi + alla möjliga olika DBMS, nyligen ORACLE, + lite PHP) har jag en hobby - att köpa och sälja lägenheter. Jag köper en lägenhet under byggskedet från en mer eller mindre pålitlig utvecklare till ett bra pris (till exempel nu är Samolet en sådan utvecklare, lägenheter nära Nekrasovka tunnelbanestation är till salu), väntar på att huset ska levereras (ofta två år senare, detta händer med billiga erbjudanden), jag renoverar den och säljer den sedan för 95-100% av marknadspriset.
Så jag (som alla andra) ställdes inför problemet med RosReestrs brist på transaktionalitet.
Problemet med Rosreestrs brist på transaktionstransaktioner
I programmering är det "Transaktion", och i fastigheter är det "Transaktion med alternativ" (och även, som en del av det, "Safe Deposit Box Agreement"), och det är lite mer komplicerat. Jag säger det.
Vasya kom för att titta på lägenheten som Petya sålde. Och Vasya gillade verkligen allt, inklusive priset, men Vasya har inga pengar. Så här börjar vår historia.
Vasya har sin egen fastighet, som har några värden som inte är särskilt nödvändiga för honom - Lomonosov bodde i grannhuset, takhöjden är sju och en halv meter, det finns en frukt- och grönsaksbas och Sadovod-marknaden i närheten kan du gå på Aeroexpress, under lägenheten finns en källare med en höjd av 1 meter, det finns en vind ovanför lägenheten bekvämt för astronomiska observationer. Vasya förstår att dessa funktioner ökar priset på hans lägenhet, men inte för honom själv. Och han bestämmer sig för att köpa Petyas lägenhet och sälja sin egen lägenhet. Men att sälja just för att köpa Petyas lägenhet, och inte bara. På mäklarens språk kallas detta "Ett alternativ har valts."
Låt oss nu titta på den här situationen från Petyas sida. Faktum är att Petya inte heller är intresserad av att sitta på värdeminskning, han säljer lägenheten för att köpa sig en lägenhet i alvstaden Valinor, men han har ännu inte tittat på vilken. På fastighetsmäklares språk kallas detta en "Deal with a alternative."
Två alver från Midgård, Maglor och Maedhros, har lämpliga (enligt Petyas kriterier) fastigheter i staden Valinor, som säljs omgående, eftersom de ska tjäna Melkor. På mäklares språk kallas detta "Fri försäljning".
Så, Vasya hittar en klient, Seryozha. Nu hittar Petya två lämpliga alternativ för honom i staden Valinor. Vi håller på att slutföra affären. Låt oss för enkelhetens skull anta att ingen av parterna i transaktionen använder ett inteckningslån och inte har minderåriga som aktieägare. Därför måste följande åtgärder nu utföras:
1. Seryozha ger pengar till Petya.
2. Vasya ger sin lägenhet till Seryozha.
3. Petya ger sin lägenhet till Vasya.
4. Antingen Maglor eller Maedhros överför sin lägenhet i Valinor till Peta och får Seryozhas pengar.
5. Malkor och Maedhros åker till Mordor för att tjäna Melkor.
Det skulle vara idealiskt att skicka in följande skript till Rosreestr för exekvering:
STARTA TRANSAKTIONEN
Ge Vasyas lägenhet till Seryozha.
Ge Petyas lägenhet till Vasya.
börja
Ge Malkors lägenhet till Petya
Ge Seryozhas pengar till Malkor
IF_ERROR:
Ge Maedhros lägenhet till Petya
Ge Seryozhas pengar till Maedhros
änden
BEGÅ TRANSAKTION
Detta är ett förenklat transaktionsskript 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 fastighetsmäklare (om några) får betalt oavsett stadierna i transaktionen.
Rosreestr stöder dock inte transaktionalitet. Alla åtgärder kommer att utföras sekventiellt och oberoende, en efter en, utan att rulla tillbaka transaktionen som helhet om en av dem misslyckas. Det maximala som kan uppnås - med tanke på att Rosreestr och MFC inte arbetar med överföring av kontanter - är att sätta in pengarna i ett kassaskåp, med villkoren för tillgång till dem av Vasya, Petya, Seryozha (om ingen transaktion är registrerad överhuvudtaget), och andra aktörer, mot uppvisande av kontrakt registrerade av Rosreestr. (Och förresten, banker verifierar inte självständigt äktheten av kontrakt, det vill säga de litar på äktheten av papper från parterna i transaktionen).
Förutom riskerna för ofullständigt slutförande av transaktionen, är ett annat problem att om andra deltagare kan flytta in i sitt nya hem utan att vänta på fullständig registrering (hej, frågan om underbetalning av elräkningar!), så kommer Maglor och Maedhros inte snart att gå till tjäna Melkor, och kanske Maglor inte kommer att kunna han kommer helt enkelt inte att ha tid att hålla Silmarils i sina händer. Fastighetstransaktioner genomförs sekventiellt och genomförandet av varje transaktion kommer att ta minst 9 arbetsdagar.
Dessutom stöder Rosreestr inte belastningen av bostäder som byggs under DDU, men det skulle kunna, detta är en elementär åtgärd i förhållande till en enkel framtid.
Låt oss nu gå vidare till bristerna och mina önskemål om DBMS
1) Den första är avsaknaden av ett versionskontrollsystem. Om jag på Delphi-sidan utvecklar i min egen sandlåda, och ändringarna jag gör inte kommer att visas för andra programmerare förrän de är engagerade, så är det inte fallet med DBMS. Och även om jag är betrodd med full (åtminstone inom ramen för vad som är nödvändigt för den uppgift som tilldelats mig) tillgång till stridsdatabasen, och detta händer, kan jag inte utveckla den. Medan jag felsöker kommer allt att kollapsa. Vad är detta för stenålder??? Gör en sandlåda för utvecklare.
2) Det andra är bristen på fördefinierade standardiserade tabeller som beskriver den verkliga världen. Varje företag jag har arbetat för har sitt eget tabellformat som beskriver namnen (på ryska och (minst) engelska, i olika fall av ryska) på tolv månader!
3) För det tredje - och här kommer jag att använda Oracle-terminologi - det finns inget sätt att anropa ett enkelt Insert- eller Update-skript som använder Returning, på samma sätt som vi kallar Select. Det här är kanske inte Oracle-problem, utan problem i gränssnittet för Delphi + Oracle.
4) För det fjärde - behovet av att tilldela befogenheter till de procedurer och funktioner jag skapar där jag inte vill göra detta. Jag vill inte ställa in och sedan ändra användarbehörigheter för procedurer och funktioner. Varför, om jag inte uttryckligen skrev Grants, kunde inte systemet självt titta på de inblandade objekten och, i enlighet med rätten att agera med dem, ge eller inte ge vissa användare rätten att anropa en funktion? Jag är redo att skriva ett nyckelord för detta när jag skriver funktioner och procedurer. Eller, ännu bättre, låt användaren börja köra, och om algoritmgrenen leder honom till en begäran som användaren inte har rättigheter för, kommer han att kasta ut den med ett fel.
Källa: will.com