Klient interaguje s databází.
Z webu , autor obrazu Jonathan Tiong.
Kromě toho, že jsem programátor (převážně Delphi + různé databázové systémy, v poslední době ORACLE, + trochu PHP), mám koníček — koupě a prodej bytů. Kupují byt ve fázi výstavby od více či méně spolehlivého developera za výhodnou cenu (například v současnosti je takovým developerem Samoljot, byty poblíž stanice metra Nekrasovka se prodávají), čekám na dokončení domu (často o dva roky později, levné nabídky se to někdy stává), dělám v něm rekonstrukci a pak prodávám za 95-100% jeho tržní ceny.
No a já (jako každý) jsem narazil na problém absence transakčnosti u Rosreesteru.
Problém absence transakčnosti obchodů u Rosreesteru
V programování je 'Transakce', a v nemovitostech se tomu říká 'Obchod s alternativou' (a také, jako její součást, 'Smlouva o bankovní schránce'), a tam je to trochu složitější. Pojďme to vyprávět.
Vaša přišel na prohlídku bytu, který prodává Petja. A Vaša se mu všechno velmi líbilo, včetně ceny, ale Vaša nemá peníze. Tak začíná náš příběh.
Vaša má svou nemovitost, která má nějaké pro něj nepotřebné hodnoty — v sousedním domě bydlel Lomonosov, výška stropů je sedm a půl metru, poblíž je ovozelové skladiště a trh Sadowod, lze dojít pěšky na Aeroexpress, pod bytem je sklep se stropem vysokým 1 metr, nad bytem je půda vhodná pro astronomická pozorování. Vaša chápe, že tyto vlastnosti zvyšují cenu jeho bytu, ale ne pro něj samotného. A rozhodne se koupit byt od Petji a prodat svůj byt. Ale prodá ho právě proto, aby koupil byt od Petji, a ne jen tak. V jazyce realitních makléřů se tomu říká — 'Alternativa je vybavena'.
Teď se podíváme na tuto situaci z pohledu Petji. Skutečností je, že Petja také nemá zájem sedět na devalvujících penězích, prodává byt, aby si koupil byt v elfském městě Valinor, ale jaký přesně — ještě nepřemýšlel. V jazyce realitních makléřů se tomu říká — 'Obchod s alternativou'.
Dva elfové Středozemě, Maglor a Maedhros, mají vhodnou nemovitost v městě Valinor, kterou nutně prodávají, protože se chystají sloužit Melkorovi. V jazyce realitních makléřů se tomu říká - „Volný prodej“.
Takže Vaša nachází klienta Sergeje. Nyní, Petya najde dva vhodné varianty v městě Valinor. Přecházíme k uzavření obchodu. Předpokládáme pro jednodušší účely, že nikdo z účastníků obchodu nepoužívá hypotéku a nemá nezletilé spoluvlastníky. Takže nyní musí proběhnout následující kroky:
1. Sergej předává peníze Petovi.
2. Vaša předává svůj byt Sergejovi.
3. Petya předává svůj byt Vašovi.
4. Buď Maglor, nebo Maedhros, předávají svůj byt v Valinoru Petovi a dostávají peníze od Sergeje.
5. Malkor a Maedhros odcházejí do Mordoru sloužit Melkorovi.
Bylo by ideální předat na Rosregistr provedení následujícího skriptu:
START TRANSACTION
Byt Vaši předat Sergejovi.
Byt Peti předat Vašovi.
begin
Byt Malkoru předat Petovi
Peníze Sergeje předat Malkorovi
IF_ERROR:
Byt Maedhrose předat Petovi
Peníze Sergeje předat Maedhrosovi
end
COMMIT TRANSACTION
To je zjednodušený skript obchodu s alternativou, předpokládající, že všechny byty mají jednoho dospělého (a způsobilého) vlastníka, že jejich hodnoty jsou si rovny a že odměna realitních makléřů (pokud existují) se platí mimo fáze obchodu.
Nicméně, Rosregistr nepodporuje transakčnost. Všechny akce budou prováděny sekvenčně a nezávisle, jedna po druhé, bez celkového vrácení transakce, pokud neproběhne jedna z nich. Maximálně, co lze dosáhnout - s ohledem na to, že Rosregistr a MFC nepracují s předáváním hotovosti - je uložit peníze do bankovní schránky, s podmínkami přístupu k nim Vaši, Peti, Sergeje (pokud vůbec žádná transakce není registrována), a dalších účastníků, při předložení registrovaných smluv Rosregistru. (A mimochodem, banky samy o sobě ověřování pravosti smluv neprovádějí, tedy důvěřují pravosti dokumentů účastníků obchodu).
Kromě rizik neúplného provedení transakce je dalším problémem, že pokud mohou ostatní účastníci vstoupit do svého nového bydlení, aniž by čekali na úplné dokončení (ahoj, otázka nedoplatků na službách!), tak Maglor a Maedhros se jen tak nevypraví sloužit Melkorovi a pravděpodobně Maglor nebude mít příležitost držet v rukou silmarily, jednoduše na to nebude mít čas. Obchody s nemovitostmi se provádějí postupně a dokončení každého obchodu trvá minimálně 9 pracovních dní.
Kromě toho státní registr neumožňuje zatížení budovy, která je stavěna na základě DDU, i když by to mohl udělat, je to elementární úkon týkající se jednoduchého futures kontraktu.
Nyní přejdeme k nedostatkům a mým požadavkům na SÚBD.
1) První – nedostatek systému správy verzí. Pokud z pohledu Delphi pracuji na vývoji ve své pískovišti a změny, které provedu, se neobjeví u ostatních programátorů, dokud je necommitují, tak s SÚBD je to jinak. I když mi důvěřují plný (alespoň v rámci potřebného pro úkol, který mám před sebou) přístup k živé databázi, což se někdy stane, nemohu na ní vyvíjet. Dokud se budu ladit, všechno se zhroutí. Co to je za kamenný věk??? Udělejte pískoviště pro vývojáře.
2) Druhý – nedostatek předinstalovaných standardizovaných tabulek, které popisují reálný svět. V každé společnosti, kde jsem pracoval, byl svůj vlastní formát tabulky, který popisoval názvy (v ruštině a (alespoň) angličtině, v různých pádech ruského jazyka) dvanácti měsíců!
3) Třetí – a zde využiji terminologii Oracle – chybí možnost vyvolat jednoduchý skript Insert nebo Update, který používá Returning, tak, jak vyvoláváme Select. Možná to není problém Oracle, ale problém propojení Delphi + Oracle.
4) Čtvrté — je nutnost přiřadit mým vytvářeným procedurám a funkcím oprávnění tam, kde se mi do toho nechce. Nechci určovat a poté měnit práva uživatelů k procedurám a funkcím. Proč by systém nemohl sám posoudit zapojené objekty a podle práv na akce s nimi přidělit nebo nepřidělit těm či oněm uživatelům právo na volání funkce, pokud jsem explicitně nenapsal granty? Jsem připraven přidat k tomu při psaní funkcí a procedur jedno klíčové slovo. Nebo ještě lépe, ať uživatel zahájí vykonání a pokud ho směr algoritmu přivede k žádosti, na kterou uživatel nemá práva, tak ať dostane chybu.
Zdroj: habr.com
