Klient wchodzi w interakcję z bazą danych.
Z witryny , autor obrazu Jonathan Tiong.
Oprócz tego, że jestem programistą (głównie Delphi + różne bazy danych, ostatnio ORACLE, + trochę PHP), mam hobby — kupno i sprzedaż mieszkań. Kupuję mieszkanie na etapie budowy od względnie wiarygodnego dewelopera w atrakcyjnej cenie (na przykład, obecnie takim deweloperem jest Samolot, mieszkania w pobliżu stacji metra Nekrasowka są na sprzedaż), czekam na zakończenie budowy (często o dwa lata później, takie przypadki zdarzają się przy niedrogich ofertach), robię w nim remont, a następnie sprzedaję za 95-100% jego rynkowej ceny.
Tak więc, ja (jak wszyscy) napotkałem problem braku transakcyjności w RosRejestrze.
Problem braku transakcyjności transakcji w RosRejestrze
W programowaniu 'Transakcja', a w nieruchomościach to 'Transakcja z alternatywą' (a także, jako jej część, 'Umowa o bankowe konto depozytowe'), i tam wszystko jest nieco bardziej skomplikowane. Opowiem.
Wania przyszedł na oględziny mieszkania, które sprzedaje Petia. I Wania był bardzo zadowolony, w tym z ceny, ale Wania nie ma pieniędzy. Tak zaczyna się nasza historia.
Wania ma swoją nieruchomość, która ma jakieś niekoniecznie potrzebne dla niego wartości — w sąsiednim domu mieszkał Lomonosow, wysokość sufitów to siedem i pół metra, w pobliżu znajduje się hurtownia warzyw i rynek Sadownik, można dojść pieszo na Aeroekspres, pod mieszkaniem jest piwnica o wysokości 1 metra, nad mieszkaniem jest strych wygodny do obserwacji astronomicznych. Wania zdaje sobie sprawę, że te cechy podnoszą wartość jego mieszkania, ale nie dla niego samego. I decyduje się kupić mieszkanie Petii, a swoje mieszkanie sprzedać. Ale sprzedaje je właśnie po to, aby kupić mieszkanie Petii, a nie ot tak. W języku pośredników nazywa się to — 'Alternatywa dobrana'.
Teraz przyjrzyjmy się tej sytuacji z perspektywy Petii. Rzecz w tym, że Petii również nie interesuje siedzenie na tracących na wartości pieniędzach, sprzedaje swoje mieszkanie, aby kupić mieszkanie w elfięj krainie Valinor, ale jeszcze nie wie, które dokładnie — jeszcze nie oglądał. W języku pośredników nazywa się to — 'Transakcja z alternatywą'.
Dwaj elfy Śródziemia, Maglor i Maedros, posiadają odpowiednią (według kryteriów Pietii) nieruchomość w mieście Valinor, którą pilnie sprzedają, ponieważ udają się służyć Melkoremu. W języku nieruchomości zwie się to — „Wolna sprzedaż”.
Więc, Wania znajduje klienta Siergieja. Teraz Pietia znajduje dwa odpowiednie dla siebie warianty w mieście Valinor. Przechodzimy do sfinalizowania transakcji. Załóżmy dla uproszczenia, że nikt z uczestników transakcji nie korzysta z kredytu hipotecznego i nie ma wspólnych właścicieli nieletnich. Tak więc, teraz muszą się odbyć następujące działania:
1. Siergiej przekazuje pieniądze Pietii.
2. Wania przekazuje swoje mieszkanie Siergiejowi.
3. Pietia przekazuje swoje mieszkanie Wani.
4. Albo Maglor, albo Maedros, przekazują swoje mieszkanie w Valinor Pietii i otrzymują pieniądze od Siergieja.
5. Malcor i Maedros idą do Mordoru służyć Melkoremu.
Idealnie byłoby przekazać do Rosrejestru następujący skrypt:
START TRANSACTION
Mieszkanie Wani oddać Siergiejowi.
Mieszkanie Pietii oddać Wani.
begin
Mieszkanie Malcora oddać Pietii
Pieniądze Siergieja oddać Malcorowi
JEŻELI_BŁĄD:
Mieszkanie Maedrosa oddać Pietii
Pieniądze Siergieja oddać Maedrosowi
end
COMMIT TRANSACTION
To uproszczony skrypt transakcji z alternatywą, zakładający, że wszystkie mieszkania mają jednego dorosłego (i pełnoletniego) właściciela, że ich wartości są równe, i że wynagrodzenie dla pośredników (jeśli są) płacone jest niezależnie od etapów transakcji.
Jednakże, Rosrejestr nie wspiera transakcyjności. Wszystkie działania będą wykonywane kolejno i niezależnie, jedno po drugim, bez odwracania transakcji w całości, jeśli nie zrealizowano jednego z nich. Najwięcej, co można osiągnąć — biorąc pod uwagę, że Rosrejestr i MFC nie obsługują przekazywania gotówki — to złożyć pieniądze w bankowej skrytce, z warunkami dostępu dla Wani, Pietii, Siergieja (jeśli żadna transakcja nie jest zarejestrowana), oraz innych działających podmiotów, na podstawie przedstawienia im zarejestrowanych przez Rosrejestr umów. (I nawiasem mówiąc, banki same nie przeprowadzają weryfikacji autentyczności umów, to znaczy ufają autentyczności dokumentów uczestników transakcji).
Oprócz ryzyk związanych z niepełnym wykonaniem transakcji, innym problemem jest to, że jeśli inni uczestnicy mogą wprowadzić się do swojego nowego mieszkania, nie czekając na pełne formalności (cześć, kwestia niedopłaty za media!), to Maglor i Maedhros długo nie wyruszą służyć Melkiorowi, a być może Maglor nie zdąży trzymać w swoich rękach silmarilli, po prostu nie zdąży. Transakcje nieruchomości są realizowane sekwencyjnie, a załatwienie każdej transakcji zajmie co najmniej 9 dni roboczych.
Ponadto, Rosrejestr nie wspiera obciążenia budowanego mieszkania w oparciu o DDU, a mógłby, to elementarna czynność dotycząca prostego futuresu.
Teraz przejdźmy do niedoskonałości i moich oczekiwań dotyczących DBMS
1) Pierwsza — to brak systemu kontroli wersji. Jeśli po stronie Delphi prowadzę rozwój w swojej piaskownicy, a wprowadzone przeze mnie zmiany nie pojawią się u innych programistów do czasu ich zatwierdzenia, to z DBMS jest inaczej. I nawet jeśli ufają mi pełen (co najmniej w ramach potrzebnej dla postawionego przede mną zadania) dostęp do działającej bazy danych, a takie sytuacje się zdarzają, nie mogę na niej rozwijać. Dopóki będę debuggować, wszystko się zawali. Co to za kamieni epoka??? Zróbcie piaskownicę dla programistów.
2) Po drugie — to brak wstępnie zainstalowanych, znormalizowanych tabel opisujących rzeczywisty świat. W każdej firmie, w której pracowałem, był swój własny format tabeli, opisujący nazwy (w języku rosyjskim i (przynajmniej) angielskim, w różnych przypadkach języka rosyjskiego) dwunastu miesięcy!
3) Po trzecie — i tutaj posłużę się terminologią Oracla — brak możliwości wywołania prostego skryptu Insert lub Update, wykorzystującego Returning, tak jak wywołujemy Select. Być może to nie problemy Oracla, a problemy związane z integracją Delphi + Oracle.
4) Po czwarte, konieczność przydzielania uprawnień procedurom i funkcjom, które tworzę, tam, gdzie nie chcę tego robić. Nie chcę przydzielać, a później zmieniać uprawnień użytkowników do procedur i funkcji. Dlaczego, jeśli wyraźnie nie napisałem Grantów, system nie mógłby sam spojrzeć na zaangażowane obiekty i w zależności od praw na działania z nimi nadawać lub nie poszczególnym użytkownikom prawa do wywołania funkcji? Jestem gotów napisać przy tym jedno słowo kluczowe. A najlepiej, niech użytkownik rozpocznie wykonanie, a jeśli ścieżka algorytmu doprowadzi go do zapytania, na które użytkownik nie ma uprawnień, to wyrzuci błąd.
Źródło: habr.com
