De klant interageert met de database.
Van de website , de kunstenaar Jonathan Tiong.
Naast mijn werk als programmeur (vooral Delphi en verschillende DBMS, onlangs ORACLE, en een beetje PHP) heb ik een hobby: de koop en verkoop van appartementen. Ik koop een appartement in de bouwfase van een redelijk betrouwbare ontwikkelaar tegen een aantrekkelijke prijs (bijvoorbeeld, op dit moment is zo'n ontwikkelaar Samolyot, appartementen in de buurt van metrostation Nekrasovka worden verkocht), wacht op de oplevering van het gebouw (vaak twee jaar later, dit kan gebeuren met goedkopere aanbiedingen), maak het appartement af en verkoop het daarna voor 95-100% van de marktprijs.
Dus, zoals iedereen, kwam ik een probleem tegen: de afwezigheid van transacties bij Rosreestr.
Het probleem van het ontbreken van transactiekracht bij Rosreestr
In programmeren is er 'Transactie', en in onroerend goed is dat 'Transactie met alternatieve opties' (en ook, als onderdeel daarvan, 'Overeenkomst van een bankkluis'), en daar is het allemaal iets ingewikkelder. Laat me het uitleggen.
Vasia kwam voor een bezichtiging van het appartement dat Petya verkoopt. Vasia vond alles erg leuk, inclusief de prijs, maar hij heeft geen geld. Zo begint ons verhaal.
Vasia heeft onroerend goed dat voor hem geen bijzondere waarde heeft - in het naastgelegen gebouw woonde Lomonosov, de plafonds zijn zeven en een halve meter hoog, er is een groente- en fruitmarkt in de buurt, je kunt te voet naar Aeroexpress gaan, onder het appartement is er een kelder van Ć©Ć©n meter hoog, boven het appartement is er een zolder die handig is voor astronomische observaties. Vasia begrijpt dat deze eigenschappen de prijs van zijn appartement verhogen, maar niet voor hemzelf. En hij besluit het appartement van Petya te kopen en zijn eigen appartement te verkopen. Maar hij wil zijn appartement verkopen om Petya's appartement te kopen, en niet zomaar. In de taal van makelaars heet dit 'Alternatief is voorbereid'.
Laten we deze situatie eens vanuit Petya's perspectief bekijken. Het probleem is dat Petya ook niet geĆÆnteresseerd is in waardeloze geldbedragen, hij verkoopt zijn appartement om zelf een appartement te kopen in de elfenstad Valinor, maar welke dat precies is, heeft hij nog niet bekeken. In de taal van makelaars heet dit 'Transactie met alternatieve opties'.
Twee elfen van Midden-aarde, Maglor en Maedhros, hebben geschikte (aan Petja's criteria) onroerend goed in de stad Valinor, dat ze dringend te koop aanbieden, aangezien ze op het punt staan te dienen onder Melkor. In de taal van makelaars wordt dit aangeduid als 'Vrije verkoop'.
Dus, Vasja vindt klant Serjoezja. Nu vindt Petja twee opties die geschikt voor hem zijn in de stad Valinor. We gaan over tot de afhandeling van de transactie. Laten we voor de eenvoud aannemen dat geen van de deelnemers aan de transactie een hypotheek gebruikt en dat er geen minderjarige mede-eigenaar is. Daarom moeten nu de volgende stappen worden uitgevoerd:
1. Serjoezja geeft het geld aan Petja.
2. Vasja geeft zijn appartement aan Serjoezja.
3. Petja geeft zijn appartement aan Vasja.
4. Of Maglor of Maedhros geven hun appartement in Valinor aan Petja en ontvangen het geld van Serjoezja.
5. Malcor en Maedhros gaan naar Mordor om onder Melkor te dienen.
Het zou ideaal zijn om het volgende script in te dienen bij het Rosregister:
START TRANSACTION
Vasja's appartement geven aan Serjoezja.
Petja's appartement geven aan Vasja.
begin
Malcor's appartement geven aan Petja
Serjoezja's geld geven aan Malcor
ALS_FOUT:
Maedhros' appartement geven aan Petja
Serjoezja's geld geven aan Maedhros
end
COMMIT TRANSACTION
Dit is een vereenvoudigd transactie-script met een alternatief, dat veronderstelt dat alle appartementen Ć©Ć©n volwassen (en handelingsbekwame) eigenaar hebben, dat hun waarden gelijk zijn, en dat de betaling voor makelaars (als die er zijn) buiten de fasen van de transactie wordt gedaan.
Echter, het Rosregister ondersteunt geen transacties. Alle handelingen zullen sequentieel en onafhankelijk van elkaar worden uitgevoerd, achtereenvolgend, zonder dat de transactie als geheel wordt teruggedraaid als niet aan Ć©Ć©n van hen wordt voldaan. Het maximaal haalbare, gezien het feit dat het Rosregister en MFC niet werken met contante betalingen, is om het geld in een bankkluis te deponeren, met toegangvoorwaarden voor Vasja, Petja, Serjoezja (als er helemaal geen transactie is geregistreerd), en andere betrokkenen, op het moment dat zij geregistreerde contracten overleggen aan het Rosregister. (En trouwens, banken voeren zelf geen echtheidcontroles van de contracten uit, wat betekent dat ze vertrouwen op de echtheid van de documenten van de deelnemers aan de transactie).
Naast de risico's van onvolledige transactie-uitvoering, is een ander probleem dat als andere deelnemers in hun nieuwe woning kunnen intrekken zonder te wachten op de volledige formaliteiten (hallo, het probleem van onbetaalde nutsvoorzieningen!), dan zullen Maglor en Maedhros niet snel de kans krijgen om onder Melykor te dienen, en mogelijk kan Maglor de Silmarils niet vasthouden, hij zal gewoon niet op tijd zijn. Vastgoedtransacties worden sequentieel uitgevoerd, en het formaliseren van elke transactie duurt minimaal 9 werkdagen.
Daarnaast ondersteunt het Kadaster geen lasten op woningen die worden gebouwd volgens een koopovereenkomst, maar zou het dat wel moeten doen, het is een elementaire actie met betrekking tot een eenvoudige optie.
Laten we nu over de nadelen en mijn wensen met betrekking tot databasesystemen gaan.
1) Ten eerste is er het ontbreken van een versiebeheersysteem. Als ik vanuit Delphi ontwikkel in mijn sandbox, zullen de wijzigingen die ik aanbreng niet bij andere programmeurs komen totdat ze zijn gecommit, maar dat is niet het geval met databasesystemen. En zelfs als ik volledige (tenzij de toegang die nodig is voor de taak die mij is toegewezen) toegang tot de productie-database krijg, kan ik daar niet ontwikkelen. Terwijl ik aan het debuggen ben, zal alles instorten. Wat is dit, de stenen tijdperk??? Maak een sandbox voor ontwikkelaars.
2) Ten tweede is er het gebrek aan vooraf gedefinieerde gestandaardiseerde tabellen die de echte wereld beschrijven. In elk bedrijf waar ik heb gewerkt, is er een eigen tabelindeling die de namen (in het Russisch en (minstens) het Engels, in verschillende naamvallen van de Russische taal) van de twaalf maanden beschrijft!
3) Ten derde ā en hier gebruik ik de terminologie van Oracle ā ontbreekt de mogelijkheid om een eenvoudige Insert- of Update-script aan te roepen met Returning, zoals we Select aanroepen. Misschien is dit niet een probleem van Oracle, maar van de combinatie Delphi + Oracle.
4) Ten vierde is de noodzaak om bevoegdheden toe te kennen aan de procedures en functies die ik maak, waar ik dat niet wil doen. Ik wil de bevoegdheden van gebruikers voor procedures en functies niet instellen en daarna wijzigen. Waarom, als ik duidelijk geen Grant-verklaringen heb geschreven, de systeem niet zelf naar de betrokken objecten kan kijken, en op basis van de rechten op handelingen met hen gebruikers het recht kan geven om de functie aan te roepen of niet? Ik ben bereid om hiervoor Ć©Ć©n sleutelwoord toe te voegen bij het schrijven van functies en procedures. Of nog beter, laat de gebruiker de uitvoering starten, en als de tak van het algoritme hem leidt naar een verzoek waarvoor de gebruiker geen rechten heeft, gooi er dan een foutmelding uit.
Bron: habr.com
