Mijn wensen voor het DBMS van de toekomst, evenals voor Rosreestr op het gebied van transactionaliteit

De klant communiceert met de database.
Van de website http://corchaosis.ru, door Jonathan Tiong.

Naast het feit dat ik programmeur ben (voornamelijk Delphi + allerlei verschillende DBMS'en, recentelijk ORACLE, + een beetje PHP), heb ik een hobby: appartementen kopen en verkopen. Ik koop tijdens de bouwfase een appartement van een min of meer betrouwbare ontwikkelaar voor een goede prijs (nu is Samolet bijvoorbeeld zo'n ontwikkelaar, er staan ​​appartementen in de buurt van het metrostation Nekrasovka te koop), wacht tot het huis wordt opgeleverd (vaak twee (jaren later gebeurt dit bij goedkope aanbiedingen), renoveer ik het en verkoop ik het vervolgens voor 95-100% van de marktprijs.

Dus ik werd (net als iedereen) geconfronteerd met het probleem van het gebrek aan transactionaliteit van RosReestr.

Het probleem van het gebrek aan transactionele transacties van Rosreestr

Bij het programmeren is het ‘Transactie’, en in onroerend goed is het ‘Transactie met Alternatief’ (en ook, als onderdeel daarvan, ‘Kluisovereenkomst’), en het is iets ingewikkelder. Ik zeg het je.

Vasya kwam het appartement bekijken dat Petya verkocht. En Vasya vond alles erg leuk, inclusief de prijs, maar Vasya heeft geen geld. Dit is hoe ons verhaal begint.

Vasya heeft zijn eigen bezit, dat een aantal waarden heeft die niet bijzonder noodzakelijk voor hem zijn - Lomonosov woonde in het aangrenzende huis, de plafondhoogte is zeven en een halve meter, er is een groente- en fruitbasis en de Sadovod-markt in de buurt kun je lopen met de Aeroexpress, onder het appartement bevindt zich een kelder met een hoogte van 1 meter, er is een zolder boven het appartement handig voor astronomische waarnemingen. Vasya begrijpt dat deze kenmerken de prijs van zijn appartement verhogen, maar niet voor hemzelf. En hij besluit Petya's appartement te kopen en zijn eigen appartement te verkopen. Maar verkopen juist om Petya's appartement te kopen, en niet alleen. In de taal van makelaars heet dit “Er is gekozen voor een alternatief.”

Laten we deze situatie nu eens van Petya's kant bekijken. Feit is dat Petya ook niet geïnteresseerd is in het afschrijven van geld, hij verkoopt het appartement om een ​​appartement voor zichzelf te kopen in de elfenstad Valinor, maar hij heeft nog niet gekeken welke. In de taal van makelaars heet dit een ‘Deal met een alternatief’.

Twee elfen van Midden-aarde, Maglor en Maedhros, hebben (volgens de criteria van Petya) geschikt onroerend goed in de stad Valinor, dat dringend wordt verkocht, omdat ze Melkor gaan bedienen. In de taal van makelaars heet dit “Gratis Verkoop”.

Dus Vasya vindt een cliënt, Seryozha. Nu vindt Petya twee geschikte opties voor hem in de stad Valinor. We staan ​​op het punt de deal af te ronden. Laten we voor de eenvoud aannemen dat geen van de partijen bij de transactie gebruik maakt van een hypotheek en geen minderjarigen als aandeelhouders heeft. Daarom moeten nu de volgende acties worden uitgevoerd:
1. Seryozha geeft geld aan Petya.
2. Vasya geeft zijn appartement aan Seryozha.
3. Petya geeft zijn appartement aan Vasya.
4. Maglor of Maedhros dragen hun appartement in Valinor over aan Peta en ontvangen het geld van Seryozha.
5. Malkor en Maedhros gaan naar Mordor om Melkor te dienen.

Het zou ideaal zijn om het volgende script ter uitvoering aan Rosreestr voor te leggen:

TRANSACTIE STARTEN
Geef Vasya's appartement aan Seryozha.
Geef Petya's appartement aan Vasya.
beginnen
Geef Malkors appartement aan Petya
Geef Seryozha's geld aan Malkor
IF_ERROR:
Geef het appartement van Maedhros aan Petya
Geef Seryozha's geld aan Maedhros
einde
VERRICHTE TRANSACTIE

Dit is een vereenvoudigd transactiescript met een alternatief, dat ervan uitgaat dat alle appartementen één volwassen (en capabele) eigenaar hebben, dat hun waarden gelijk zijn en dat eventuele makelaars worden betaald, ongeacht de fasen van de transactie.

Rosreestr ondersteunt echter geen transactionaliteit. Alle acties worden opeenvolgend en onafhankelijk, de een na de ander, uitgevoerd, zonder dat de transactie als geheel wordt teruggedraaid als een van de acties mislukt. Het maximale dat kan worden bereikt – gegeven dat Rosreestr en de MFC niet werken met het overmaken van contant geld – is het geld in een kluis te deponeren, met de voorwaarden voor toegang daartoe door Vasya, Petya, Seryozha (indien geen transactie plaatsvindt). überhaupt geregistreerd is), en andere actoren, op vertoon van contracten geregistreerd door Rosreestr. (En trouwens, banken verifiëren de authenticiteit van contracten niet onafhankelijk, dat wil zeggen, ze vertrouwen op de authenticiteit van de papieren van de partijen bij de transactie).

Naast de risico's van onvolledige voltooiing van de transactie, is een ander probleem dat als andere deelnemers naar hun nieuwe huis kunnen verhuizen zonder te wachten op volledige registratie (hallo, de kwestie van onderbetaling van energierekeningen!), Maglor en Maedhros niet snel naar hun nieuwe huis zullen gaan. Melkor dienen, en misschien zal Maglor dat niet kunnen, hij heeft simpelweg geen tijd om de Silmarils in zijn handen te houden. Vastgoedtransacties worden opeenvolgend uitgevoerd en de uitvoering van elke transactie duurt minimaal 9 werkdagen.

Bovendien ondersteunt Rosreestr de last van de woningbouw die onder de DDU wordt gebouwd niet, maar dat zou wel kunnen. Dit is een elementaire actie met betrekking tot een eenvoudige toekomst.

Laten we nu verder gaan met de tekortkomingen en mijn wensen over het DBMS

1) De eerste is het ontbreken van een versiebeheersysteem. Als ik aan de Delphi-kant ontwikkel in mijn eigen sandbox, en de wijzigingen die ik aanbreng zullen niet voor andere programmeurs verschijnen totdat ze zijn vastgelegd, dan is dit niet het geval met het DBMS. En zelfs als mij volledige (althans binnen de reikwijdte van wat nodig is voor de aan mij toegewezen taak) toegang tot de gevechtsdatabase wordt toevertrouwd, en dit gebeurt, kan ik me er niet op ontwikkelen. Terwijl ik aan het debuggen ben, stort alles in. Wat is dit voor steentijd??? Maak een sandbox voor ontwikkelaars.

2) De tweede is het ontbreken van vooraf gedefinieerde gestandaardiseerde tabellen die de echte wereld beschrijven. Elk bedrijf waarvoor ik heb gewerkt, heeft zijn eigen tabelformaat waarin de namen (in het Russisch en (tenminste) Engels, in verschillende gevallen van Russisch) van twaalf maanden worden beschreven!

3) Ten derde - en hier zal ik de terminologie van Oracle gebruiken - is er geen manier om een ​​eenvoudig Insert- of Update-script aan te roepen dat Returning gebruikt, op dezelfde manier waarop we Select aanroepen. Misschien zijn dit geen Oracle-problemen, maar problemen op de interface van Delphi + Oracle.

4) Ten vierde: de noodzaak om bevoegdheden toe te kennen aan de procedures en functies die ik creëer waar ik dit niet wil doen. Ik wil geen gebruikersrechten voor procedures en functies instellen en vervolgens wijzigen. Waarom zou het systeem, als ik niet expliciet Grants schreef, niet zelf naar de betrokken objecten kunnen kijken en, in overeenstemming met de rechten om ermee te handelen, bepaalde gebruikers wel of niet het recht kunnen geven om een ​​functie aan te roepen? Ik ben bereid hiervoor één trefwoord te schrijven bij het schrijven van functies en procedures. Of, nog beter, laat de gebruiker beginnen met de uitvoering, en als de algoritmetak hem naar een verzoek leidt waarvoor de gebruiker geen rechten heeft, zal hij het met een fout weggooien.

Bron: www.habr.com