Meine Wünsche für das DBMS der Zukunft sowie für Rosreestr in Bezug auf die Transaktionalität

Der Client interagiert mit der Datenbank.
Von der Website http://corchaosis.ru, von Jonathan Tiong.

Neben der Tatsache, dass ich Programmierer bin (hauptsächlich Delphi + alle möglichen DBMS, neuerdings ORACLE, + ein wenig PHP), habe ich ein Hobby – den Kauf und Verkauf von Wohnungen. Ich kaufe eine Wohnung in der Bauphase von einem mehr oder weniger zuverlässigen Bauträger zu einem günstigen Preis (zum Beispiel, jetzt ist Samolet ein solcher Bauträger, Wohnungen in der Nähe der U-Bahn-Station Nekrasovka stehen zum Verkauf), ich warte auf die Übergabe des Hauses (bei günstigen Angeboten passiert das oft zwei Jahre später), ich repariere es und verkaufe es dann für 95-100 % des Marktpreises.

Also stieß ich (wie alle anderen auch) auf das Problem der mangelnden Transaktionalität von RosReestr.

Das Problem des fehlenden Transaktionscharakters von Transaktionen in Rosreestr

In der Programmierung „Transaktion“ und im Immobilienbereich heißt es „Deal with alternative“ (und als Teil davon auch „Deposit box Agreement“), und da sind die Dinge etwas komplizierter. Ich erzähle.

Vasya kam, um die Wohnung zu besichtigen, die Petya verkauft. Und Vasya hat alles sehr gut gefallen, auch der Preis, aber Vasya hat kein Geld. So beginnt unsere Geschichte.

Vasya verfügt über ein eigenes Grundstück, das über einige Werte verfügt, die für ihn nicht besonders notwendig sind – Lomonossow wohnte in einem Nachbarhaus, die Deckenhöhe beträgt siebeneinhalb Meter, es gibt eine Obstbasis und den Sadovod-Markt in der Nähe , Sie können zum Aeroexpress laufen, unter der Wohnung befindet sich 1 Meter ein Keller, über der Wohnung befindet sich ein Dachboden, der für astronomische Beobachtungen geeignet ist. Vasya versteht, dass diese Eigenschaften den Preis seiner Wohnung erhöhen, jedoch nicht für ihn selbst. Und er beschließt, Petjas Wohnung zu kaufen und seine Wohnung zu verkaufen. Aber es zu verkaufen, um Petjas Wohnung zu kaufen, und nicht nur. In der Maklersprache nennt man das: „Die Alternative ist ausgewählt.“

Schauen wir uns diese Situation nun von Petyas Seite aus an. Tatsache ist, dass Petya auch kein Interesse daran hat, auf abwertendem Geld zu sitzen, er verkauft eine Wohnung, um eine Wohnung in der Elfenstadt Valinor zu kaufen, aber er hat sich noch nicht angeschaut, welche. In der Sprache der Immobilienmakler nennt man das „Deal with a Alternative.“

Zwei Elfen von Mittelerde, Maglor und Maedhros, verfügen über geeignete (Petits Kriterien) Immobilien in der Stadt Valinor, die dringend verkauft werden, da sie in den Dienst von Melkor geschickt werden. In der Maklersprache nennt man das „Freiverkauf“.

Also findet Vasya einen Kunden, Serezha. Nun findet Petya in der Stadt Valinor zwei passende Optionen für ihn. Wir werden einen Deal machen. Nehmen Sie der Einfachheit halber an, dass keiner der Transaktionsteilnehmer eine Hypothek in Anspruch nimmt und keinen Minderheitsaktionär hat. Somit sollten nun folgende Aktionen stattfinden:
1. Seryozha gibt Petya Geld.
2. Vasya übergibt Seryozha seine Wohnung.
3. Petya gibt Vasya seine Wohnung.
4. Entweder Maglor oder Maedhros übergeben ihre Wohnung in Valinor an Petya und erhalten Seryozhas Geld.
5. Malkor und Maedhros gehen nach Mordor, um Melkor zu dienen.

Ideal wäre es, das folgende Skript zur Ausführung an Rosreestr zu übertragen:

TRANSAKTION STARTEN
Gib Vasyas Wohnung Seryozha.
Gib Vasya Petits Wohnung.
beginnen
Gib Petya Malkors Wohnung
Gib Malkor Seryozhas Geld
IF_ERROR:
Gebt Petya Maedhros' Wohnung
Gebt Seryozhas Geld Maedhros
Ende
COMMIT TRANSACTION

Dies ist ein vereinfachtes Transaktionsskript mit einer Alternative, bei der davon ausgegangen wird, dass alle Wohnungen einen erwachsenen (und fähigen) Eigentümer haben, dass ihre Preise gleich sind und dass Makler (falls vorhanden) unabhängig von den Phasen der Transaktion bezahlt werden.

Allerdings unterstützt Rosreestr keine Transaktionalität. Alle Aktionen werden nacheinander und unabhängig voneinander ausgeführt, ohne dass die gesamte Transaktion rückgängig gemacht wird, wenn eine davon nicht abgeschlossen wurde. Das Maximum, das erreicht werden kann – da Rosreestr und das MFC nicht mit der Überweisung von Bargeld arbeiten – besteht darin, Geld in eine Bankzelle zu legen, mit den Bedingungen für den Zugriff darauf durch Vasya, Petya, Serezha (sofern keine Transaktion registriert ist). überhaupt) und andere Akteure, gegen Vorlage der von Rosreestr registrierten Vereinbarungen. (Übrigens überprüfen Banken die Echtheit von Verträgen nicht unabhängig, das heißt, sie vertrauen auf die Echtheit der Papiere der Transaktionsteilnehmer).

Zusätzlich zu den Risiken, die Transaktion nicht vollständig abzuschließen, besteht ein weiteres Problem darin, dass Maglor und Maedhros dies nicht tun werden, wenn andere Teilnehmer in ihre neue Wohnung einziehen können, ohne auf die vollständige Registrierung zu warten (Hallo, die Frage der Unterzahlung von Stromrechnungen!). Gehen Sie bald, um Melkor zu dienen, und vielleicht wird Maglor nicht in der Lage sein, die Silmarils in seinen Händen zu halten, er wird einfach keine Zeit haben. Immobilientransaktionen werden nacheinander ausgeführt und die Bearbeitung jeder Transaktion dauert mindestens 9 Werktage.

Darüber hinaus unterstützt Rosreestr die Belastung von im Bau befindlichen Wohnungen im Rahmen der DDU nicht, könnte es aber sein, dies ist eine elementare Maßnahme in Bezug auf eine einfache Zukunft.

Kommen wir nun zu den Mängeln und meiner Wunschliste zum DBMS

1) Der erste Grund ist das Fehlen eines Versionskontrollsystems. Wenn ich von der Delphi-Seite aus in meiner Sandbox entwickle und die von mir vorgenommenen Änderungen für andere Programmierer erst sichtbar werden, wenn sie festgeschrieben werden, dann ist dies beim DBMS nicht der Fall. Und selbst wenn mir (zumindest im Rahmen der mir übertragenen Aufgabe) uneingeschränkter Zugriff auf die Kampfdatenbank zugestanden wird und dies geschieht, kann ich darauf nicht weiterentwickeln. Während ich debugge, wird alles zusammenbrechen. Was ist diese Steinzeit? Erstellen Sie eine Sandbox für Entwickler.

2) Der zweite Grund ist das Fehlen vorinstallierter standardisierter Tabellen, die die reale Welt beschreiben. Jedes Unternehmen, für das ich gearbeitet habe, verfügt über ein eigenes Tabellenformat, in dem die Namen von zwölf Monaten (auf Russisch und (mindestens) Englisch, in verschiedenen Fällen Russisch) beschrieben werden!

3) Drittens – und hier verwende ich die Oracle-Terminologie – gibt es keine Möglichkeit, ein einfaches Insert- oder Update-Skript aufzurufen, das Returning verwendet, wie wir es Select nennen. Möglicherweise handelt es sich hierbei nicht um Oracle-Probleme, sondern um Probleme mit der Delphi + Oracle-Schnittstelle.

4) Viertens die Notwendigkeit, den von mir erstellten Verfahren und Funktionen Befugnisse zuzuweisen, wenn ich dies nicht tun möchte. Ich möchte nicht die Berechtigungen des Benutzers für Prozeduren und Funktionen festlegen und dann ändern. Warum, wenn ich Grants nicht explizit geschrieben habe, könnte sich das System dann selbst die beteiligten Objekte ansehen und entsprechend den Rechten, mit ihnen zu handeln, bestimmten Benutzern das Recht geben, die Funktion aufzurufen, oder nicht? Ich bin bereit, beim Schreiben von Funktionen und Prozeduren ein Schlüsselwort dafür zu schreiben. Oder, noch besser, lassen Sie den Benutzer mit der Ausführung beginnen, und wenn der Algorithmuszweig ihn zu einer Anfrage führt, für die der Benutzer keine Rechte hat, wird er sie mit einem Fehler verwerfen.

Source: habr.com