Kívánom a jövő DBMS-ének, valamint a Rosreestr-nek a tranzakciós jelleget illetően

Kívánom a jövő DBMS-ének, valamint a Rosreestr-nek a tranzakciós jelleget illetően
Az ügyfél interakcióba lép az adatbázissal.
A weboldalról http://corchaosis.ru, írta: Jonathan Tiong.

Amellett, hogy programozó vagyok (főleg Delphi + mindenféle DBMS, mostanában ORACLE, + egy kis PHP), van egy hobbim - lakások adásvétele. Építés közben veszek lakást egy többé-kevésbé megbízható fejlesztőtől jó áron (például most a Samolet ilyen fejlesztő, a Nekrasovka metróállomás közelében lakások eladók), megvárom a ház átadását (gyakran kettő évekkel később ez olcsó ajánlatokkal történik), felújítom, majd a piaci ár 95-100%-áért eladom.

Tehát én (mint mindenki más) szembesültem a RosReestr tranzakciós hiányának problémájával.

A Rosreestr tranzakciós tranzakcióinak hiányának problémája

A programozásban ez „Tranzakció”, az ingatlanoknál pedig „Tranzakció alternatívával” (és ennek részeként „Széf-szerződés”), és ez egy kicsit bonyolultabb. Mondom.

Vasya eljött megnézni a lakást, amit Petya árult. És Vasyának nagyon tetszett minden, beleértve az árat is, de Vasyának nincs pénze. Így kezdődik a történetünk.

Vasyának van saját ingatlanja, amiben vannak olyan értékek, amelyek nem különösebben szükségesek a számára - Lomonoszov a szomszéd házban lakott, a belmagasság hét és fél méter, van zöldség-gyümölcs bázis és a szadovodi piac. a közelben sétálhat az Aeroexpressen, a lakás alatt van egy 1 méter magas pince, a lakás felett tetőtér található, amely alkalmas csillagászati ​​megfigyelésekre. Vasya megérti, hogy ezek a tulajdonságok növelik lakása árát, de nem saját magának. És úgy dönt, hogy megveszi Petya lakását, és eladja a saját lakását. De az eladás pontosan azért, hogy megvegye Petya lakását, és nem csak. Az ingatlanosok nyelvén ezt úgy hívják, hogy „Kiválasztottak egy alternatívát”.

Most nézzük meg ezt a helyzetet Petya oldaláról. Az tény, hogy Petyát sem érdekli az amortizálódó pénzen ülni, eladja a lakást, hogy vegyen magának lakást Valinor elf városában, de még nem nézte, melyiket. Az ingatlanosok nyelvén ezt „alternatív megállapodásnak” hívják.

Középfölde két elfének, Maglornak és Maedhrosnak megfelelő (Petya kritériumai szerint) ingatlana van Valinor városában, amelyet sürgősen eladnak, mivel Melkort szolgálják ki. Az ingatlanközvetítők nyelvén ezt „ingyenes eladásnak” nevezik.

Tehát Vasya ügyfelet talál, Seryozha. Petya most két megfelelő lehetőséget talál a számára Valinor városában. Az üzlet véglegesítése előtt állunk. Tegyük fel az egyszerűség kedvéért, hogy az ügyletben részt vevő felek egyike sem vesz igénybe jelzálogkölcsönt, és nincs kiskorú tulajdonosa. Ezért most a következő műveleteket kell végrehajtani:
1. Serjozsa pénzt ad Petyának.
2. Vasya Serjozsának adja a lakását.
3. Petya Vasyának adja a lakását.
4. Maglor vagy Maedhros átadják a valinori lakásukat Petának, és megkapják Seryozha pénzét.
5. Malkor és Maedhros Mordorba mennek, hogy Melkort szolgálják.

Ideális lenne a következő szkriptet benyújtani a Rosreestrnek végrehajtásra:

TRANZAKCIÓ INDÍTÁSA
Add Vasya lakását Serjozsának.
Add át Petya lakását Vasjának.
kezdődik
Add át Malkor lakását Petyának
Add Serjozsa pénzét Malkornak
IF_ERROR:
Add át Maedhros lakását Petyának
Add Seryozha pénzét Maedhrosnak
végén
TRANZAKCIÓ KÖTELEZÉSE

Ez egy leegyszerűsített tranzakciós forgatókönyv egy alternatívával, amely feltételezi, hogy minden lakásnak egy felnőtt (és cselekvőképes) tulajdonosa van, az értékük egyenlő, és az ingatlanosok (ha vannak) fizetést kapnak, függetlenül a tranzakció szakaszától.

A Rosreestr azonban nem támogatja a tranzakciókat. Minden műveletet egymás után és egymástól függetlenül hajtanak végre, anélkül, hogy a tranzakció egészét vissza kellene vonni, ha valamelyik meghiúsul. Az elérhető maximum - tekintettel arra, hogy a Rosreestr és az MFC nem működik készpénzátutalással - az, hogy a pénzt egy széfben helyezik el, azzal a feltételekkel, hogy Vasya, Petya, Seryozha hozzáférhessen (ha nincs tranzakció egyáltalán be van jegyezve), és más szereplők, a Rosreestr. által bejegyzett szerződések bemutatása esetén. (És egyébként a bankok nem önállóan ellenőrzik a szerződések valódiságát, vagyis megbíznak a tranzakcióban részt vevő felek papírjainak valódiságában).

A tranzakció hiányos lebonyolításának kockázata mellett további probléma, hogy ha más résztvevők a teljes regisztráció megvárása nélkül költözhetnek új otthonukba (üdvözöljük, a rezsi alulfizetés kérdése!), akkor a Maglor és a Maedhros nem egyhamar szolgálja Melkort, és talán Maglor nem lesz képes rá, egyszerűen nem lesz ideje a Silmarilokat a kezében tartani. Az ingatlanügyletek szekvenciálisan zajlanak, és az egyes tranzakciók végrehajtása legalább 9 munkanapot vesz igénybe.

Ráadásul a Rosreestr nem támogatja a DDU keretében épülő lakások megterhelését, de megtehetné, ez egy egyszerű határidős ügylet kapcsán elemi lépés.

Most térjünk át a hiányosságokra és a DBMS-sel kapcsolatos kívánságaimra

1) Az első a verziókezelő rendszer hiánya. Ha a Delphi oldalon a saját homokozómban fejlesztek, és az általam végrehajtott változtatások addig nem jelennek meg a többi programozó számára, amíg el nem készülnek, akkor ez nem így van a DBMS-rel. És még ha teljes (legalábbis a rám bízott feladathoz szükséges keretek között) hozzáférést kapok a harci adatbázishoz, és ez meg is történik, nem tudok fejlődni rajta. Hibakeresés közben minden összeomlik. Milyen kőkorszak ez??? Készítsen homokozót a fejlesztőknek.

2) A második a valós világot leíró előre definiált szabványosított táblázatok hiánya. Minden cégnek, ahol dolgoztam, van saját táblázatformátuma, amely leírja a tizenkét hónap nevét (oroszul és (legalább) angolul, különböző esetekben oroszul!

3) Harmadszor – és itt az Oracle terminológiáját fogom használni – nincs mód arra, hogy egy egyszerű Insert vagy Update parancsfájlt hívjunk meg, amely a Returning-t használja, ugyanúgy, ahogy a Select-et hívjuk. Lehet, hogy ezek nem az Oracle problémák, hanem a Delphi + Oracle interfészével kapcsolatos problémák.

4) Negyedszer – az általam létrehozott eljárásokhoz és funkciókhoz hatáskört kell rendelni ott, ahol nem akarom ezt megtenni. Nem akarok felhasználói engedélyeket beállítani, majd módosítani az eljárásokhoz és funkciókhoz. Ha nem írtam ki kifejezetten Grants-t, miért nem tudta a rendszer maga is megnézni az érintett objektumokat, és a velük való fellépés jogával összhangban bizonyos felhasználóknak megadni vagy sem a függvény meghívásának jogát? Kész vagyok egy kulcsszót írni ehhez a függvények és eljárások írásakor. Vagy még jobb, ha a felhasználó elindítja a végrehajtást, és ha az algoritmus ága olyan kérésre vezeti, amelyhez a felhasználónak nincs joga, akkor hibával kidobja.

Forrás: will.com

Hozzászólás