Моите пожелания към СУБД на бъдещето, както и към Rosreestr по отношение на транзакционността

Клиентът взаимодейства с базата данни.
От сайта http://corchaosis.ru, от Джонатан Тионг.

Освен, че съм програмист (основно Делфи + всякакви разни СУБД, от скоро ORACLE, + малко PHP), имам хоби - покупко-продажба на апартаменти. Купувам апартамент по време на етапа на строителство от повече или по-малко надежден предприемач на добра цена (например сега Самолет е такъв предприемач, продават се апартаменти близо до метростанция Некрасовка), чакам къщата да бъде доставена (често две години по-късно, това се случва с евтини оферти), ремонтирам го и след това го продавам за 95-100% от пазарната му цена.

И така, аз (както всички останали) бях изправен пред проблема с липсата на транзакционност на RosReestr.

Проблемът с липсата на транзакции в Rosreestr

В програмирането това е „Транзакция“, а в недвижимите имоти е „Транзакция с алтернатива“ (и също, като част от нея, „Споразумение за сейф“) и е малко по-сложно. Казвам ти.

Вася дойде да огледа апартамента, който Петя продаваше. И Вася много хареса всичко, включително цената, но Вася няма пари. Така започва нашата история.

Вася има собствен имот, който има някои ценности, които не са особено необходими за него - Ломоносов е живял в съседната къща, височината на тавана е седем метра и половина, има база за плодове и зеленчуци и пазар Sadovod в близост, можете да се разходите по Aeroexpress, под апартамента има мазе с височина 1 метър, има таванско помещение над апартамента, удобно за астрономически наблюдения. Вася разбира, че тези функции увеличават цената на апартамента му, но не и за самия него. И той решава да купи апартамента на Петя и да продаде собствения си апартамент. Но продавам точно за да купя апартамента на Петя, а не само. На езика на брокерите това се нарича „Избрана е алтернатива“.

Сега да погледнем тази ситуация от страната на Петя. Факт е, че Петя също не се интересува да седи на обезценени пари, той продава апартамента, за да си купи апартамент в елфическия град Валинор, но още не е погледнал кой. На езика на брокерите това се нарича „Сделка с алтернатива“.

Двама елфи от Средната земя, Маглор и Маедрос, имат подходящ (по критериите на Петя) недвижим имот в град Валинор, който спешно се продава, тъй като ще служат на Мелкор. На езика на брокерите това се нарича „безплатна продажба“.

И така, Вася намира клиент, Серьожа. Сега Петя намира два подходящи варианта за него в град Валинор. Предстои да финализираме сделката. Нека приемем за простота, че нито една от страните по сделката не използва ипотека и няма непълнолетни лица като собственици на акции. Следователно сега трябва да се извършат следните действия:
1. Серьожа дава пари на Петя.
2. Вася дава апартамента си на Серьожа.
3. Петя дава апартамента си на Вася.
4. Или Maglor, или Maedhros прехвърлят апартамента си във Valinor на Peta и получават парите на Seryozha.
5. Малкор и Маедрос отиват в Мордор, за да служат на Мелкор.

Би било идеално да изпратите следния скрипт на Rosreestr за изпълнение:

СТАРТ НА ТРАНЗАКЦИЯ
Дайте апартамента на Вася на Серьожа.
Дайте апартамента на Петя на Вася.
започвам
Дайте апартамента на Малкор на Петя
Дайте парите на Серьожа на Малкор
IF_ERROR:
Дайте апартамента на Маедрос на Петя
Дайте парите на Seryozha на Maedhros
край
АНГАЖИРАНЕ НА СДЕЛКАТА

Това е опростен скрипт за транзакция с алтернатива, който предполага, че всички апартаменти имат един пълнолетен (и дееспособен) собственик, че техните стойности са еднакви и че брокерите (ако има такива) се плащат независимо от етапите на транзакцията.

Rosreestr обаче не поддържа транзакционност. Всички действия ще се извършват последователно и независимо, едно след друго, без да се връща транзакцията като цяло, ако едно от тях се провали. Максимумът, който може да се постигне - като се има предвид, че Rosreestr и MFC не работят с парични преводи - е да депозирате парите в сейф, с условията за достъп до него от Вася, Петя, Серьожа (ако няма транзакция е регистриран изобщо) и други участници, при представяне на договори, регистрирани от Rosreestr. (И между другото, банките не проверяват независимо автентичността на договорите, т.е. те се доверяват на автентичността на документите на страните по сделката).

Освен рисковете от непълно завършване на транзакцията, друг проблем е, че ако други участници могат да се преместят в новия си дом, без да чакат пълна регистрация (здравейте, проблемът с непълното плащане на сметки за комунални услуги!), тогава Maglor и Maedhros скоро няма да отидат в служи на Мелкор и може би Маглор няма да може, той просто няма да има време да държи Силмарилите в ръцете си. Сделките с недвижими имоти се извършват последователно, като изпълнението на всяка сделка ще отнеме минимум 9 работни дни.

В допълнение, Rosreestr не подкрепя обременяването на жилища, които се строят по DDU, но би могло, това е елементарно действие във връзка с обикновен фючърс.

Сега да преминем към недостатъците и моите желания относно СУБД

1) Първият е липсата на система за контрол на версиите. Ако от страна на Delphi разработвам в моята собствена пясъчна среда и промените, които правя, няма да се появят на други програмисти, докато не бъдат ангажирани, тогава това не е случаят с СУБД. И дори да ми се довери пълен (поне в рамките на необходимото за възложената ми задача) достъп до бойната база данни и това се случи, не мога да се развивам върху нея. Докато отстранявам грешки, всичко ще се срине. Що за каменна ера е това??? Направете пясъчник за разработчици.

2) Второто е липсата на предварително дефинирани стандартизирани таблици, описващи реалния свят. Всяка компания, в която съм работил, има свой собствен табличен формат, описващ имената (на руски и (поне) английски, в различни случаи на руски) за дванадесет месеца!

3) Трето - и тук ще използвам терминологията на Oracle - няма начин да се извика прост скрипт Insert или Update, който използва Returning, по същия начин, по който наричаме Select. Може би това не са проблеми на Oracle, а проблеми в интерфейса на Delphi + Oracle.

4) Четвърто - необходимостта от възлагане на правомощия на процедурите и функциите, които създавам, когато не искам да правя това. Не искам да задавам и след това да променя потребителски разрешения за процедури и функции. Защо, ако не написах изрично Grants, самата система не можеше да разгледа включените обекти и в съответствие с правата за действие с тях да даде или не на определени потребители правото да извикат функция? Готов съм да напиша една ключова дума за това, когато пиша функции и процедури. Или още по-добре, оставете потребителя да започне изпълнението и ако клонът на алгоритъма го доведе до заявка, за която потребителят няма права, той ще я изхвърли с грешка.

Източник: www.habr.com