将来の DBMS と、トランザクション性の観点からの Rosreestr に対する私の願い

クライアントはデータベースと対話します。
サイトから http://corchaosis.ru、ジョナサン・ティオン著。

私はプログラマー (主に Delphi + さまざまな DBMS、最近では ORACLE、+ 少し PHP) であることに加えて、アパートの売買という趣味があります。 私は建設段階で多かれ少なかれ信頼できる開発業者からおいしい価格でアパートを購入します（たとえば、現在サモレットはそのような開発業者であり、地下鉄ネクラソフカ駅近くのアパートが売りに出ています）、家の引き渡しを待ちます（多くの場合、95年後、安価なオファーでこれが起こります）、私はそれを修理し、その後市場価格の100〜XNUMX％で販売します。

そこで、私も（他の皆さんと同じように）RosReestr にはトランザクション性がないという問題に遭遇しました。

ロスリーストルのトランザクションのトランザクション的性質の欠如の問題

プログラミングでは「トランザクション」、不動産では「代替案との取引」（およびその一部として「貸金庫契約」）があり、物事はもう少し複雑です。 私は言っています。

VasyaはPetyaが販売しているアパートを見に来ました。 そして、Vasyaは価格を含めてすべてが非常に気に入りましたが、Vasyaにはお金がありません。 これが私たちの物語の始まりです。

ヴァシャには自分の財産があり、それは彼にとって特に必要ではないいくつかの価値観を持っています - ロモノソフは隣の家に住んでいました、天井の高さは1メートルで、近くには果物の基地とサドヴォド市場があります、アエロエクスプレスまで歩いて行けます、アパートの下XNUMXメートルに地下室があり、アパートの上には天体観測に便利な屋根裏部屋があります。 Vasya は、これらの機能によりアパートの価格が上昇することを理解していますが、それは自分自身のためではありません。 そして彼はペティアのアパートを購入し、彼のアパートを売ることにしました。 しかし、ペティアのアパートを買うためにそれを売るだけではありません。 不動産業者の言葉では、これを「代替案が選択される」と呼びます。

次に、この状況を Petya の側から見てみましょう。 実際のところ、ペティアも減価償却費に座ることに興味がなく、エルフの都市ヴァリノールのアパートを購入するためにアパートを売却していますが、まだどれを探していません。 不動産業者の言葉では、これを「代替案に対処する」と呼びます。

中つ国の二人のエルフ、マグロールとマエドロスは、ヴァリノール市に適切な（プチの基準による）不動産を所有しており、メルコールに仕えるために派遣されているため、緊急に売却されることになっている。 不動産業者の言葉では、これを「無料販売」と呼びます。

そこで、ヴァシャはクライアントのセレザを見つけました。 さて、ペティアはヴァリノール市で自分に適した選択肢を XNUMX つ見つけました。 取引をするつもりです。 話を簡単にするために、取引の参加者は誰も住宅ローンを利用しておらず、少数株主もいないと仮定します。 したがって、次のアクションが実行されるはずです。
1. セリョーザはペティアにお金を渡します。
2. ヴァシャは自分のアパートをセリョーザに与えます。
3. ペティアは自分のアパートをヴァシャに与えます。
4. マグロルかマエドロスのどちらかがヴァリノールのアパートをペティアに引き渡し、セリョーザのお金を受け取ります。
5. マルコールとマイドロスはメルコールに仕えるためにモルドールへ行く。

次のスクリプトを Rosreestr に転送して実行するのが理想的です。

取引を開始する
ヴァシャのアパートをセリョーザに渡す。
プティのアパートをヴァシャに渡す。
始まる
マルコのアパートをペティアに渡す
セリョーザのお金をマルコに渡す
IF_エラー:
マエドロスのアパートをペティアに渡す
セリョーザのお金をマエドロスに渡す
end
トランザクションのコミット

これは、すべてのアパートメントに XNUMX 人の成人 (および有能な) 所有者がいること、価格が等しいこと、および不動産業者 (存在する場合) が取引の段階に関係なく支払われることを前提とした、代替案を備えた簡略化された取引スクリプトです。

ただし、Rosreestr はトランザクション性をサポートしていません。 すべてのアクションは、いずれかが完了していない場合にトランザクション全体をロールバックすることなく、順番に独立して実行されます。 Rosreestr と MFC が現金の送金に対応していないことを考慮すると、達成できる最大限のことは、Vasya、Petya、Serezha がアクセスできる条件付きで銀行のセルにお金を入れることです (取引が登録されていない場合)まったく)、およびその他の関係者は、Rosreestr によって登録された契約書の提示に応じて、 （ちなみに、銀行は契約書の真正性を独自に検証することはありません。つまり、取引の参加者の書類の真正性を信頼しています）。

取引が完全に完了しないリスクに加えて、別の問題は、他の参加者が完全な登録を待たずに新しい住宅に入居できる場合（公共料金の過払いの問題です！）、その場合、Maglor と Maedros は、すぐにメルコールに仕えに行きます、そしておそらくマグロールはシルマリルを手に持つことができないでしょう、彼には単に時間がないでしょう。 不動産取引は順次実行され、各取引の処理には少なくとも 9 営業日かかります。

さらに、ロスリーストルは DDU に基づく建設中の住宅の妨害を支持していないが、これは単純な先物に関連した初歩的な行為であるため支持する可能性がある。

それでは、DBMS の欠点と私の欲しいものリストに移りましょう。

1) XNUMX つ目は、バージョン管理システムの欠如です。 Delphi 側から見ると、私はサンドボックスで開発しており、私が行った変更はコミットされるまで他のプログラマーには表示されませんが、DBMS ではそうではありません。 そして、たとえ私が戦闘データベースへの (少なくとも私に割り当てられたタスクの枠組み内で) 完全なアクセス権を持っていると信頼されていて、これが起こったとしても、私はそれを使って開発することはできません。 デバッグ中にすべてが崩れてしまいます。 この石器時代とは何でしょうか？ 開発者向けのサンドボックスを作成します。

2) XNUMX つ目は、現実世界を記述する標準化されたテーブルが事前にインストールされていないことです。 私が働いたことのあるすべての会社には、XNUMX か月の名前 (ロシア語と (少なくとも) 英語、ロシア語の場合は異なる) を説明する独自の表形式があります。

3) 第三に、ここでは Oracle の用語を使用します。Returning を使用する単純な Insert または Update スクリプトを呼び出す方法 (Select を呼び出す方法) はありません。 おそらく、これらは Oracle の問題ではなく、Delphi + Oracle インターフェイスの問題です。

4) XNUMX 番目に、作成したプロシージャや関数に権限を割り当てたくない場合に、権限を割り当てる必要があります。 プロシージャや機能に対するユーザーの権限を設定したり、変更したりしたくありません。 Grants を明示的に記述しなかった場合、なぜシステム自体が関係するオブジェクトを調べ、オブジェクトを操作する権利に従って、特定のユーザーに関数を呼び出す権利を与えるか与えないかを決めることができなかったのでしょうか? 関数やプロシージャを書くときに、これに関するキーワードを XNUMX つ書く準備ができています。 あるいは、さらに良いのは、ユーザーに実行を開始させ、アルゴリズムの分岐によってユーザーが権限を持たないリクエストに誘導された場合、ユーザーはそのリクエストをエラーで破棄することです。

出所： habr.com