The client interacts with the database.
From the website , by Jonathan Tiong.
Besides the fact that I am a programmer (mostly Delphi + all sorts of different DBMS, recently ORACLE, + a little PHP), I have a hobby - buying and selling apartments. I buy an apartment at the construction stage from a more or less reliable developer at a tasty price (for example, now Samolet is such a developer, apartments near the Nekrasovka metro station are for sale), I wait for the house to be handed over (often two years later, this happens with inexpensive offers), I do it in repair it and then sell it for 95-100% of its market price.
So, I (like everyone else) ran into the problem of RosReestr's lack of transactionality.
The problem of Rosreestr's lack of transactional nature of transactions
In programming "Transaction" and in real estate it is "Deal with alternative" (and also, as part of it, "Deposit box agreement"), and there things are a little more complicated. I'm telling.
Vasya came to see the apartment that Petya is selling. And Vasya liked everything very much, including the price, but Vasya has no money. This is how our story begins.
Vasya has his own property, which has some values ββ\u1b\uXNUMXbthat are not particularly necessary for him - Lomonosov lived in a neighboring house, the ceiling height is seven and a half meters, there is a fruit base and the Sadovod market nearby, you can walk to the Aeroexpress, there is a basement under the apartment XNUMX meter, above the apartment there is an attic convenient for astronomical observations. Vasya understands that these features increase the price of his apartment, but not for himself. And he decides to buy Petya's apartment, and sell his apartment. But to sell it in order to buy Petya's apartment, and not just. In the language of realtors, this is called - "The alternative is selected."
Now let's look at this situation from Petya's side. The fact is that Petya is also not interested in sitting on depreciating money, he is selling an apartment in order to buy an apartment in the elven city of Valinor, but he has not yet looked at which one. In the language of realtors, this is called - "Deal with an alternative."
Two elves of Middle-earth, Maglor and Maedhros, have suitable (Petit's criteria) real estate in the city of Valinor, which is urgently sold, as they are sent to serve Melkor. In the language of realtors, this is called - "Free sale".
So, Vasya finds a client Serezha. Now, Petya finds two suitable options for him in the city of Valinor. We're going to make a deal. Assume for simplicity that none of the participants in the transaction uses a mortgage and does not have a minor share owner. Thus, the following actions should now take place:
1. Seryozha gives money to Petya.
2. Vasya gives his apartment to Seryozha.
3. Petya gives his apartment to Vasya.
4. Either Maglor or Maedhros hand over their apartment in Valinor to Petya and receive Seryozha's money.
5. Malkor and Maedhros go to Mordor to serve Melkor.
It would be ideal to transfer the following script to Rosreestr for execution:
START TRANSACTION
Give Vasya's apartment to Seryozha.
Give Petit's apartment to Vasya.
begin
Give Malkor's apartment to Petya
Give Seryozha's money to Malkor
IF_ERROR:
Give Maedhros' apartment to Petya
Give Seryozha's money to Maedhros
end
COMMIT TRANSACTION
This is a simplified transaction script with an alternative, assuming that all apartments have one adult (and capable) owner, that their prices are equal, and that realtors (if any) are paid regardless of the stages of the transaction.
However, Rosreestr does not support transactionality. All actions will be performed sequentially and independently, one after another, without rolling back the transaction as a whole if one of them has not been completed. The maximum that can be achieved - given that Rosreestr and the MFC do not work with the transfer of cash - is to put money in a bank cell, with the conditions for access to them by Vasya, Petya, Serezha (if no transaction is registered at all), and other actors, upon presentation of agreements registered by Rosreestr. (And by the way, banks do not independently verify the authenticity of contracts, that is, they trust the authenticity of the papers of the participants in the transaction).
In addition to the risks of not completing the transaction in full, another problem is that if other participants can move into their new housing without waiting for full registration (hello, the question of underpayment of utility bills!), then Maglor and Maedhros will not soon go to serve Melkor, and perhaps Maglor will not be able to to hold the Silmarils in his hands, he simply will not have time. Real estate transactions are executed sequentially, and the processing of each transaction will take at least 9 working days.
In addition, Rosreestr does not support the encumbrance of housing under construction under the DDU, but it could, this is an elementary action in relation to a simple futures.
Now let's move on to the shortcomings and my Wishlist about the DBMS
1) The first is the lack of a version control system. If from the Delphi side I am developing in my sandbox, and the changes I made will not appear to other programmers until they are committed, then it is not so with the DBMS. And even if I am trusted with full (at least within the framework of the task assigned to me) access to the combat database, and this happens, I cannot develop on it. While I'm debugging, everything will collapse. What is this stone age? Make a sandbox for developers.
2) The second is the lack of pre-installed standardized tables describing the real world. Every company I've worked for has its own table format describing the names (in Russian and (at least) English, in different cases of Russian) of twelve months!
3) Third - and here I will use Oracle terminology - there is no way to call a simple Insert or Update script that uses Returning, the way we call Select. Perhaps these are not Oracle problems, but Delphi + Oracle interface problems.
4) Fourth, the need to assign powers to the procedures and functions I create where I do not want to do this. I don't want to set, and then change, the user's permissions for procedures and functions. Why, if I did not explicitly write Grants, could the system itself look at the involved objects, and, in accordance with the rights to act with them, give or not certain users the right to call the function? I am ready to write one keyword for this when writing functions and procedures. Or, even better, let the user start execution, and if the algorithm branch leads him to a request for which the user does not have rights, he will throw it out with an error.
Source: habr.com