Moje życzenia dla DBMS przyszłości, a także dla Rosreestr pod względem transakcyjności

Moje życzenia dla DBMS przyszłości, a także dla Rosreestr pod względem transakcyjności
Klient wchodzi w interakcję z bazą danych.
Z serwisu http://corchaosis.ru, autorstwa Jonathana Tionga.

Oprócz tego, że jestem programistą (głównie Delphi + różne rodzaje DBMS, ostatnio ORACLE + trochę PHP), mam hobby - kupno i sprzedaż mieszkań. Kupuję mieszkanie na etapie budowy od mniej lub bardziej solidnego dewelopera w smacznej cenie (np. teraz takim deweloperem jest Samolet, mieszkania w pobliżu stacji metra Nekrasovka są na sprzedaż), czekam na przekazanie domu (często dwa lata później zdarza się to przy niedrogich ofertach), robię to w naprawie, a następnie sprzedaję za 95-100% ceny rynkowej.

Tak więc (jak wszyscy inni) stanąłem przed problemem braku transakcyjności w RosReestr.

Problem braku transakcyjnego charakteru transakcji Rosreestra

W programowaniu „Transakcja” iw nieruchomościach jest to „Rozpraw się z alternatywą” (a także w jej ramach „Umowa skrytki depozytowej”), a tam sprawa jest nieco bardziej skomplikowana. Mówię.

Vasya przyszedł obejrzeć mieszkanie, które sprzedaje Petya. A Vasya bardzo lubiła wszystko, łącznie z ceną, ale Vasya nie ma pieniędzy. Tak zaczyna się nasza historia.

Vasya ma swoją własność, która ma pewne wartości, które nie są mu szczególnie potrzebne - Łomonosow mieszkał w sąsiednim domu, wysokość sufitu wynosi siedem i pół metra, w pobliżu znajduje się baza owocowa i targ Sadovod , można dojść do Aeroexpressu, pod mieszkaniem jest piwnica 1 metr, nad mieszkaniem strych dogodny do obserwacji astronomicznych. Vasya rozumie, że te cechy zwiększają cenę jego mieszkania, ale nie dla siebie. I postanawia kupić mieszkanie Petyi i sprzedać swoje mieszkanie. Ale sprzedać go, aby kupić mieszkanie Petyi, a nie tylko. W języku pośredników w handlu nieruchomościami nazywa się to - „Wybrano alternatywę”.

Teraz spójrzmy na tę sytuację od strony Petyi. Faktem jest, że Petya również nie jest zainteresowany siedzeniem na amortyzacji pieniędzy, sprzedaje mieszkanie, aby kupić mieszkanie w elfickim mieście Valinor, ale jeszcze nie spojrzał, które. W języku pośredników w handlu nieruchomościami nazywa się to - "Zajmij się alternatywą".

Dwa elfy ze Śródziemia, Maglor i Maedhros, mają odpowiednią (według kryteriów Petita) nieruchomość w mieście Valinor, która jest pilnie sprzedawana, ponieważ są wysyłani, by służyć Melkorowi. W języku pośredników w handlu nieruchomościami nazywa się to - "Bezpłatna sprzedaż".

Tak więc Vasya znajduje klienta Serezha. Teraz Petya znajduje dla niego dwie odpowiednie opcje w mieście Valinor. Mamy zamiar zawrzeć umowę. Załóżmy dla uproszczenia, że ​​żaden z uczestników transakcji nie korzysta z kredytu hipotecznego i nie ma mniejszego udziałowca. W związku z tym należy teraz podjąć następujące działania:
1. Seryozha daje pieniądze Petyi.
2. Vasya oddaje Seryozha swoje mieszkanie.
3. Petya oddaje Vasyi swoje mieszkanie.
4. Albo Maglor, albo Maedhros przekazują Petyi swoje mieszkanie w Valinorze i otrzymują pieniądze Seryozhy.
5. Malkor i Maedhros udają się do Mordoru, aby służyć Melkorowi.

Idealnie byłoby przesłać następujący skrypt do Rosreestr w celu wykonania:

ROZPOCZNIJ TRANSAKCJĘ
Oddaj mieszkanie Vasyi Sierioży.
Przekaż Vasyi mieszkanie Petita.
rozpocząć
Przekaż Petyi mieszkanie Malkora
Daj Malkorowi pieniądze Seryozhy
JEŻELI_BŁĄD:
Przekaż Petyi mieszkanie Maedhrosa
Daj Maedhrosowi pieniądze Seryozhy
zakończenia
ZAKOŃCZ TRANSAKCJĘ

Jest to uproszczony scenariusz transakcji z opcją alternatywną, zakładającą, że wszystkie mieszkania mają jednego dorosłego (i zdolnego) właściciela, ich ceny są równe, a pośrednicy (jeśli tacy są) są opłacani niezależnie od etapów transakcji.

Jednak Rosreestr nie obsługuje transakcyjności. Wszystkie akcje będą wykonywane sekwencyjnie i niezależnie, jedna po drugiej, bez wycofywania transakcji jako całości, jeśli jedna z nich nie została zakończona. Maksimum, jakie można osiągnąć - biorąc pod uwagę, że Rosreestr i MFC nie współpracują z przekazem gotówki - to włożenie pieniędzy do komórki bankowej, z warunkami dostępu do nich Vasya, Petya, Serezha (jeśli żadna transakcja nie jest zarejestrowana w ogóle) i innych podmiotów, po przedstawieniu umów zarejestrowanych przez Rosreestr. (Nawiasem mówiąc, banki nie weryfikują samodzielnie autentyczności umów, czyli ufają autentyczności dokumentów uczestników transakcji).

Oprócz ryzyka niesfinalizowania transakcji w całości, kolejnym problemem jest to, że jeśli inni uczestnicy mogą wprowadzić się do nowego mieszkania bez czekania na pełną rejestrację (cześć, kwestia niedopłaty rachunków za media!), to Maglor i Maedhros nie będą wkrótce pójdzie służyć Melkorowi, a być może Maglor nie będzie w stanie trzymać Silmarilów w dłoniach, po prostu nie będzie miał czasu. Transakcje dotyczące nieruchomości są realizowane sekwencyjnie, a przetwarzanie każdej transakcji zajmie co najmniej 9 dni roboczych.

Ponadto Rosreestr nie wspiera obciążania mieszkań w budowie w ramach DDU, ale może, jest to czynność elementarna w stosunku do prostych kontraktów terminowych.

Przejdźmy teraz do niedociągnięć i mojej listy życzeń dotyczącej DBMS

1) Pierwszym jest brak systemu kontroli wersji. Jeśli od strony Delphi rozwijam się w swoim sandboksie, a zmiany, które wprowadziłem, nie będą widoczne dla innych programistów, dopóki nie zostaną zatwierdzone, to z DBMS tak nie jest. I nawet jeśli powierzono mi pełny (przynajmniej w ramach powierzonego mi zadania) dostęp do bojowej bazy danych, a tak się dzieje, nie mogę się na niej rozwijać. Podczas debugowania wszystko się zawali. Co to jest ta epoka kamienia łupanego? Stwórz piaskownicę dla programistów.

2) Drugi to brak preinstalowanych znormalizowanych tabel opisujących rzeczywisty świat. Każda firma, w której pracowałem, ma własny format tabeli opisujący nazwy (w języku rosyjskim i (przynajmniej) angielskim, w różnych przypadkach rosyjskim) dwunastu miesięcy!

3) Po trzecie - i tutaj użyję terminologii Oracle - nie ma możliwości wywołania prostego skryptu Insert lub Update, który używa Returning, tak jak nazywamy Select. Być może nie są to problemy z Oracle, ale problemy z interfejsem Delphi + Oracle.

4) Po czwarte, konieczność przypisania uprawnień procedurom i funkcjom, które tworzę tam, gdzie nie chcę tego robić. Nie chcę ustawiać, a następnie zmieniać uprawnień użytkownika do procedur i funkcji. Dlaczego, skoro nie napisałem wprost Grantów, sam system nie mógłby spojrzeć na zaangażowane obiekty i, zgodnie z prawami do działania z nimi, przyznać lub nie niektórym użytkownikom prawa do wywołania funkcji? Jestem gotów napisać do tego jedno słowo kluczowe podczas pisania funkcji i procedur. Lub, jeszcze lepiej, pozwolić użytkownikowi rozpocząć wykonywanie, a jeśli gałąź algorytmu doprowadzi go do żądania, do którego użytkownik nie ma uprawnień, wyrzuci je z błędem.

Źródło: www.habr.com

Dodaj komentarz