Der Kunde interagiert mit der Datenbank.
Von der Website , der Autor des Gemäldes Jonathan Tiong.
Neben meiner Tätigkeit als Programmierer (hauptsächlich Delphi + verschiedene DBMS, zuletzt 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 attraktiven Preis (zum Beispiel ist derzeit ein solcher Bauträger Samoljot, die Wohnungen in der Nähe der U-Bahn-Station Nekrasovka werden verkauft), warte auf die Fertigstellung des Hauses (oft zwei Jahre später, bei günstigen Angeboten kommt das vor), renoviere sie und verkaufe sie dann für 95-100% ihres Marktpreises.
So bin ich (wie alle) mit dem Problem konfrontiert, dass es beim Rosreestr an Transaktionsfähigkeit mangelt.
Das Problem der fehlenden Transaktionsfähigkeit beim Rosreestr
In der Programmierung ist eine "Transaktion" und in der Immobilienwirtschaft ist es "Eine Transaktion mit Alternativen" (und als Teil davon "Vereinbarung über ein Bankfach"), und dort ist alles ein wenig komplizierter. Ich erzähle.
Wanja kam zur Besichtigung der Wohnung, die Petja verkauft. Und Wanja hat alles sehr gefallen, einschließlich des Preises, aber Wanja hat kein Geld. So beginnt unsere Geschichte.
Wanja besitzt eine Immobilie, die für ihn nicht besonders wertvoll ist — im Nachbarhaus lebte Lomonossow, die Deckenhöhe beträgt sieben Meter fünfzig, in der Nähe gibt es eine Obst- und Gemüsebasis und den Markt Sadovod, man kann zum Aeroexpress zu Fuß gehen, unter der Wohnung gibt es einen ein Meter hohen Keller, über der Wohnung ein Dachboden, der sich gut für astronomische Beobachtungen eignet. Wanja versteht, dass diese Besonderheiten den Preis seiner Wohnung erhöhen, aber nicht für ihn selbst. Und er beschließt, die Wohnung von Petja zu kaufen und seine eigene Wohnung zu verkaufen. Aber verkaufen, um genau Petjas Wohnung zu kaufen, nicht einfach so. Auf der Sprache der Immobilienmakler nennt man das — "Alternative ausgewählt".
Lassen Sie uns die Situation aus Petjas Sicht betrachten. Tatsache ist, dass Petja auch nicht interessiert daran ist, mit abgewerteten Geld zu sitzen, er verkauft die Wohnung, um sich eine Wohnung in der elbischen Stadt Valinor zu kaufen, aber welche genau — hat er noch nicht angesehen. Auf der Sprache der Immobilienmakler nennt man das — "Transaktion mit Alternativen".
Zwei Elfen aus Mittelerde, Maglor und Maedhros, besitzen geeignete Immobilien (für Petja) in der Stadt Valinor, die sie dringend verkaufen, da sie in den Dienst Melkors gehen. In der Sprache der Immobilienmakler nennt man das - "Freie Verkaufsoption".
Also findet Wasja den Kunden Sereja. Jetzt findet Petja zwei passende Optionen in der Stadt Valinor. Wir gehen zur Vertragsabwicklung über. Angenommen, zur Vereinfachung, dass niemand der an der Transaktion beteiligten Parteien eine Hypothek nutzt und keine minderjährigen Mitbesitzer hat. Folglich müssen nun folgende Schritte durchgeführt werden:
1. Sereja übergibt das Geld an Petja.
2. Wasja übergibt seine Wohnung an Sereja.
3. Petja übergibt seine Wohnung an Wasja.
4. Entweder Maglor oder Maedhros übergeben ihre Wohnung in Valinor an Petja und erhalten das Geld von Sereja.
5. Malcor und Maedhros gehen nach Mordor, um Melkor zu dienen.
Idealerweise sollte der folgende Skript an das Rosregistr übergeben werden:
START TRANSACTION
Die Wohnung von Wasja wird Sereja übergeben.
Die Wohnung von Petja wird Wasja übergeben.
begin
Die Wohnung von Malcor wird Petja übergeben
Das Geld von Sereja wird Malcor übergeben
WENN_FEHLER:
Die Wohnung von Maedhros wird Petja übergeben
Das Geld von Sereja wird Maedhros übergeben
end
COMMIT TRANSACTION
Dies ist das vereinfachte Skript der Transaktion mit einer Alternative, die davon ausgeht, dass jede Wohnung einen erwachsenen (und geschäftsfähigen) Eigentümer hat, dass ihre Werte gleich sind und dass die Zahlungen an die Immobilienmakler (sofern vorhanden) unabhängig von den Transaktionsschritten erfolgen.
Jedoch unterstützt das Rosregistr keine Transaktionsfähigkeit. Alle Aktionen werden nacheinander und unabhängig, nacheinander, ohne Rückabwicklung der gesamten Transaktion durchgeführt, wenn eine davon nicht ausgeführt wurde. Das Höchste, was erreicht werden kann - da das Rosregistr und das MFC keine Barmittelübergabe abwickeln - ist, das Geld in ein Bankschließfach zu legen, mit den Zugangsbedingungen für Wasja, Petja, Sereja (sofern keine Transaktion registriert wird) und anderen beteiligten Personen, die ihre registrierten Verträge beim Rosregistr vorlegen. (Übrigens führen Banken selbst keine Echtheitsprüfungen für Verträge durch, d.h. sie vertrauen auf die Echtheit der Papiere der an der Transaktion beteiligten Parteien.)
Neben den Risiken unvollständiger Transaktionen gibt es ein weiteres Problem: Wenn andere Teilnehmer in ihre neue Wohnung einziehen können, ohne auf die vollständige Registratur zu warten (Hallo, Thema der ausstehenden Versorgungszahlungen!), werden Maglor und Maedhros nicht schnell zu Melkor aufbrechen, und möglicherweise kann Maglor die Silmarils nicht in seinen Händen halten, da er einfach nicht schnell genug sein wird. Immobiliengeschäfte werden nacheinander ausgeführt, und die Registrierung jeder Transaktion dauert mindestens 9 Arbeitstage.
Darüber hinaus unterstützt das Rosregistrierungsamt keine Belastungen von im Bau befindlichem Wohnraum gemäß DDU, was möglich wäre – es ist eine grundlegende Handlung in Bezug auf einen einfachen Futures-Vertrag.
Kommen wir nun zu den Nachteilen und meinen Wünschen in Bezug auf DBMS.
1) Erstens – es fehlt ein Versionskontrollsystem. Wenn ich von Delphi aus in meiner Sandbox entwickle und meine Änderungen bei anderen Programmierern erst nach dem Commit auftauchen, ist das bei DBMS nicht der Fall. Selbst wenn ich vollen Zugang zur Produktivdatenbank habe (zumindest im Rahmen der für die mir gestellten Aufgabe erforderlichen Anforderungen), kann ich nicht daran arbeiten. Während ich debugge, läuft alles zusammen. Was ist das für die Steinzeit??? Schaffen Sie eine Sandbox für die Entwickler.
2) Zweitens – es gibt keine vorinstallierten standardisierten Tabellen, die die reale Welt beschreiben. In jedem Unternehmen, in dem ich gearbeitet habe, gibt es ein eigenes Tabellenformat, das die Namen (auf Russisch und (zumindest) Englisch, in verschiedenen Fällen der russischen Sprache) der zwölf Monate beschreibt!
3) Drittens – und hier benutze ich die Terminologie von Oracle – es fehlt die Möglichkeit, ein einfaches Insert- oder Update-Skript mit Returning aufzurufen, so wie wir Select aufrufen. Möglicherweise liegt das nicht an Oracle, sondern an der Schnittstelle zwischen Delphi und Oracle.
4) Der vierte Punkt ist die Notwendigkeit, den von mir geschaffenen Verfahren und Funktionen Befugnisse zuzuweisen, wo ich dies nicht möchte. Ich möchte die Befugnisse der Benutzer für die Prozedur und die Funktion nicht festlegen und später ändern. Warum kann das System, wenn ich nicht ausdrücklich Grants angegeben habe, nicht selbst die beteiligten Objekte prüfen und je nach Rechten zur Handhabung dieser Objekte die entsprechenden Benutzer mit dem Recht zum Aufruf der Funktion ausstatten oder nicht? Ich bin bereit, dafür beim Schreiben von Funktionen und Prozeduren ein Schlüsselwort zu verwenden. Oder noch besser, der Benutzer könnte die Ausführung starten, und wenn der Algorithmus ihn zu einer Anfrage führt, für die der Benutzer keine Berechtigung hat, würde ein Fehler angezeigt werden.
Quelle: habr.com
