My wishes for the database of the future, as well as for the Russian State Register concerning transactionality

My wishes for the database of the future, as well as for the Russian State Register concerning transactionality
The client interacts with the database.
From the site http://corchaosis.ru, author of the painting Jonathan Tiong.

In addition to being a programmer (primarily in Delphi and various databases, recently Oracle, and a bit of PHP), I have a hobby — buying and selling apartments. I buy an apartment during the construction stage from a more or less reliable developer at an attractive price (for example, a current reliable developer is Samolyot, selling apartments near Nekrasovka metro station), I wait for the building to be finished (often two years later, this can happen with inexpensive offers), I renovate it, and then sell it for 95-100% of its market value.

So, I (like everyone else) faced the problem of the lack of transactional processing at Rosreestr.

The problem of the lack of transactional processing for deals at Rosreestr

In programming, we have 'Transaction', whereas in real estate this is known as 'Deal with Alternatives' (and, as part of it, 'Bank Safe Deposit Agreement'), and it is somewhat more complicated. Let me explain.

Vasya came to view the apartment being sold by Petya. Vasya liked everything about it, including the price, but he has no money. Thus begins our story.

Vasya owns a property that has some features that are not particularly valuable to him — Lomonosov lived in the neighboring building, the ceiling height is seven and a half meters, there is a fruit and vegetable warehouse and a market called Sadovod nearby, one can walk to Aeroexpress, there is a basement under the apartment that is one meter high, and there is an attic above the apartment convenient for astronomical observations. Vasya understands that these features raise the price of his apartment, but not for him personally. He decides to buy Petya's apartment and sell his own. But he intends to sell his apartment specifically to buy Petya's apartment, not just for the sake of it. In real estate language, this is called 'An Alternative has been Selected.'

Now let’s look at this situation from Petya's perspective. The thing is, Petya is also not interested in sitting on depreciating money; he is selling his apartment to buy a new one in the Elven city of Valinor, but he hasn't yet decided which one. In real estate language, this is referred to as 'Deal with Alternatives.'

Two elves of Middle-earth, Maglor and Maedros, have suitable real estate in the city of Valinor that they urgently need to sell as they are going to serve Melkor. In real estate terms, this is called a 'Free Sale.'

So, Vasya finds a client named Sergey. Now, Petya finds two options suitable for him in the city of Valinor. We proceed to finalize the deal. For simplicity's sake, let's assume that none of the participants in the transaction is using a mortgage or has underage co-owners. Therefore, the following actions must now take place:
1. Sergey hands over the money to Petya.
2. Vasya transfers his apartment to Sergey.
3. Petya transfers his apartment to Vasya.
4. Either Maglor or Maedros transfers their apartment in Valinor to Petya and receives money from Sergey.
5. Malcor and Maedros go to Mordor to serve Melkor.

It would be ideal to submit the following script to Rosreestr for execution:

START TRANSACTION
Transfer Vasya's apartment to Sergey.
Transfer Petya's apartment to Vasya.
begin
Transfer Malcor's apartment to Petya.
Transfer Sergey's money to Malcor.
IF_ERROR:
Transfer Maedros's apartment to Petya.
Transfer Sergey's money to Maedros.
end
COMMIT TRANSACTION

This is a simplified transaction script with alternatives, assuming that all apartments have one adult (and legally capable) owner, that their values are equal, and that any realtor fees (if applicable) are paid independently of the transaction stages.

However, Rosreestr does not support transactions. All actions will be executed sequentially and independently, one after the other, without rolling back the transaction as a whole if one of them fails. The most that can be achieved—considering that Rosreestr and MFC do not handle cash transfers—is to deposit the money in a bank safe deposit box, with access conditions for Vasya, Petya, Sergey (if no transaction is registered at all), and other active parties upon presenting their contracts registered by Rosreestr. (By the way, banks do not independently verify the authenticity of the contracts, meaning they trust the authenticity of the participants' documents).

In addition to the risks of incomplete transaction execution, another issue is that if other participants can move into their new homes without waiting for the full processing (hello, the issue of underpayment of utility bills!), then Maglor and Maedhros will not be serving Melkor anytime soon, and it’s possible that Maglor will not be able to hold the Silmarils in his hands; he simply won't have enough time. Real estate transactions are carried out sequentially, and processing each transaction will take no less than 9 business days.

Furthermore, the Rosreestr does not support encumbrance of housing constructed under shared construction agreements, although it could; this is a simple action regarding a straightforward futures contract.

Now, let's move on to the drawbacks and my wishes regarding the DBMS.

1) The first is the lack of a version control system. If I am developing in Delphi in my sandbox, the changes I make will not appear to other programmers until they are committed, but it’s not the same with the DBMS. Even if I am trusted with full access (at least within the limits required for the task at hand) to the production database—such things do happen—I cannot develop on it. While I am debugging, everything will crash. What is this, the Stone Age??? Create a sandbox for developers.

2) The second is the absence of pre-installed standardized tables that describe the real world. In every company I have worked for, there is their own format for the table describing names (in Russian and at least in English, in different cases of the Russian language) for the twelve months!

3) The third is, and I will use Oracle's terminology here—the inability to call a simple Insert or Update script that uses Returning, just like we call Select. This might not be an issue with Oracle but rather with the interface between Delphi and Oracle.

4) The fourth point is the need to grant the procedures and functions I create permissions where I do not want to. I do not want to set and then change user permissions for the procedure and function. Why, if I have not explicitly written Grants, couldn't the system look at the objects involved and grant or deny users the right to call the function based on their action rights? I am ready to include a single keyword for this when writing functions and procedures. Or, even better, let the user initiate the process, and if the flow of the algorithm leads to a request that the user does not have rights for, it would throw an error.

Source: habr.com

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster