Клієнт взаємодіє із базою даних.
З сайту , автор картини Jonathan Tiong.
Крім того, що я програміст (переважно, це Delphi + всякі різні СУБД, останнім часом ОРАКЛ, + трохи PHP), у мене є хобі - це купівля і продаж квартир. Я купую квартиру на етапі будівництва від більш менш надійного забудовника за смачною ціною (наприклад, зараз таким забудовником є Літак, квартири біля м. Некрасівка продаються), чекаю здачі будинку (часто на два роки пізніше, з недорогими пропозиціями таке трапляється), роблю в ній ремонт і потім продаю за 95-100% її ринкової ціни.
Так от, я (як і всі) зіткнувся з проблемою відсутності у РосРеєстру транзакційності.
Проблема відсутності у Росреєстру транзакційності угод
У програмуванні «Транзакція», а в нерухомості це «Угода з альтернативою» (а також, як її частина, «Договір про банківську комірку»), і там все трохи складніше. Розповідаю.
Вася прийшов на перегляд квартири, яку продає Петя. І Васі все дуже сподобалося, навіть ціна, але у Васі грошей немає. Так розпочинається наша історія.
Вася має свою нерухомість, яка має якісь не особливо потрібні для нього цінності — в сусідньому будинку жив Ломоносов, висота стель сім з половиною метрів, поблизу знаходиться плодова база та ринок Садівник, можна дійти пішки на Аероекспрес, під квартирою є підвал заввишки. метр, над квартирою є горище зручне для астрономічних спостережень. Вася розуміє, що ці особливості підвищують ціну його квартири, але не для нього самого. І він вирішує квартиру Петі купити, а свою квартиру продати. Але продати саме для того, щоб купити квартиру Петі, а не просто. Мовою ріелторів це називається - "Альтернатива підібрана".
Тепер подивимося на цю ситуацію з боку Петі. Справа в тому, що Петі теж не цікаво сидіти на грошах, що знецінюються, він продає квартиру заради того, щоб купити собі квартиру в ельфійському місті Валінор, але яку саме — ще не дивився. Мовою ріелторів це називається - "Угода з альтернативою".
Два ельфи Середзем'я, Маглор і Маедрос, володіють підходящою (критеріями Петі) нерухомістю в місті Валінор, яку терміново розпродують, оскільки вирушають служити Мелькору. Мовою ріелторів це називається - «Вільний продаж».
Отже, Вася знаходить клієнта Сергію. Тепер, Петя знаходить два потрібні йому варіанти в місті Валінор. Виходимо оформлення угоди. Допустимо для простоти, що ніхто з учасників угоди не використовує іпотеку і не має пайового власника неповнолітніх. Таким чином, тепер мають відбутися такі дії:
1. Сергій передає гроші Пете.
2. Вася передає свою квартиру Сергію.
3. Петя передає свою квартиру Васі.
4. Або Маглор, або Маедрос, передають свою квартиру у Валінорі Пете і отримують гроші Сергія.
5. Малкор і Маедрос йдуть у Мордор служити Мелькору.
Ідеально було б передати до Росреєстру на виконання наступний скрипт:
START TRANSACTION
Квартиру Васі віддати Сергію.
Квартиру Петі віддати Васі.
починати
Квартиру Малкора віддати Пете
Гроші Сергія віддати Малкору
ЯКЩО_ПОМИЛКА:
Квартиру Маедроса віддати Пете
Гроші Сергія віддати Маедросу
кінець
COMMIT TRANSACTION
Це спрощений скрипт угоди з альтернативою, що передбачає, що у всіх квартир один дорослий (і дієздатний) власник, що їхня вартість дорівнює, і що оплата ріелторів (якщо вони є) оплачується поза прив'язкою до етапів угоди.
Проте Росреєстр не підтримує транзакційність. Всі дії будуть виконуватися послідовно і незалежно, одна за одною, без відкату транзакції в цілому, якщо не виконалося одне з них. Максимум, що можна досягти — враховуючи, що Росреєстр і МФЦ не працюють із передачею готівки — це закласти гроші в банківський осередок, з умовами доступу до них Васі, Петі, Сергія (якщо взагалі жодна угода не зареєстрована), та інших дійових осіб, за фактом пред'явлення ними зареєстрованих Росреєстром договорів. (І, до речі, банки самостійно перевірку справжності договорів не здійснюють, тобто довіряють справжності паперів учасників угоди).
Окрім ризиків неповного виконання транзакції, інша проблема в тому, що якщо інші учасники можуть в'їхати у своє нове житло, не чекаючи повного оформлення (привіт, питання недоплати комунальних платежів!), то Маглор і Маедрос нескоро вирушать служити Мелькору, і можливо, Маглор не зможе потримати у своїх руках сильмарилли, він просто не встигне. Угоди з нерухомістю виконуються послідовно, і оформлення кожної угоди триватиме щонайменше 9 робочих днів.
Крім цього, Росреєстр не підтримує обтяження житла, що будується по ДДУ, а міг би, це елементарна дія щодо простого ф'ючерсу.
Тепер перейдемо до недоліків та моїх хотівок про СУБД
1) Перше — відсутність системи контролю версій. Якщо з боку Delphi я веду розробку у своїй пісочниці, і зроблені мною зміни не з'являться в інших програмістів до моменту їхнього комміту, то з СУБД не так. І навіть якщо мені довіряють повний (принаймні в рамках потрібного для поставленого переді мною завдання) доступ до бойової БД, а таке трапляється, я не можу на ній розробляти. Поки я налагоджуватимуся, все впаде. Це що за кам'яний вік? Зробіть пісочницю розробникам.
2) Друге - це відсутність встановлених стандартизованих таблиць, що описують реальний світ. У кожній компанії, де я працював, свій власний формат таблиці, що описує назви (російською та (принаймні) англійською мовою, у різних відмінках російської мови) дванадцяти місяців!
3) Третє - і тут я скористаюся термінологією Оракла - відсутня можливість викликати простий скрипт Insert або Update, що використовує Returning, оскільки ми викликаємо Select. Можливо, це не проблеми Оракла, а проблеми стику Delphi + Oracle.
4) Четверте — необхідність призначення створюваних мною процедур і функцій повноважень там, де робити цього не хочу. Я не хочу задавати, а потім змінювати повноваження користувачів процедури та функції. Чому, якщо я явно не написав Grant, система не могла б сама подивитися на задіяні об'єкти, і відповідно до прав на дії з ними наділяти чи ні тих чи інших користувачів правом на виклик функції? Я готовий написати для цього при написанні функцій та процедур одне ключове слово. Або ще краще, нехай користувач почне виконання, а якщо гілка алгоритму приведе його до запиту на який у користувача немає прав, то викине з помилкою.
Джерело: habr.com