My wishes for the DBMS of the future, as well as for Rosreestr in terms of transactionality



The client interacts with the database.

From the site http://corchaosis.ru , author of the picture Jonathan Tiong.



In addition to being a programmer (mainly Delphi + all sorts of different DBMS, recently ORAKL, + 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 such a developer is Airplane, apartments near metro Nekrasovka are for sale), wait for the delivery of the house (often two years later, with inexpensive offers this happens), I do it in renovated and then sold for 95-100% of its market price.



So, I (like everyone else) faced the problem of RosReestr's lack of transactionality.



The problem of Rosreestr's lack of transactional transactions



In programming "Transaction", and in real estate it is "Deal with an alternative" (and also, as a part of it, "Agreement on a safe deposit box"), and everything is a little more complicated there. I'm telling you.



Vasya came to see the apartment that Petya is selling. And Vasya really liked everything, including the price, but Vasya has no money. This is how our story begins.



Vasya has his own property, which has some values ​​that are not particularly necessary for him - Lomonosov lived in the next house, the ceiling height is seven and a half meters, there is a fruit-growing base and the Gardener market nearby, you can walk to Aeroexpress, there is a basement 1 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 Petit'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 perspective. The fact is that Petya is also not interested in sitting on depreciating money, he sells 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 real estate suitable (according to Petit's criteria) 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 Seryozha. Now, Petya finds two options suitable for him in the city of Valinor. We go to the registration of the transaction. For the sake of simplicity, let's say that none of the parties to the transaction uses a mortgage and does not have a minority shareholder. Thus, the following actions must now take place:

1. Seryozha gives the money to Petya.

2. Vasya hands over his apartment to Seryozha.

3. Petya hands over his apartment to Vasya.

4. Either Maglor, or Maedhros, hand over their apartment in Valinor to Pete and receive Seryozha's money.

5. Malkor and Maedhros go to Mordor to serve Melkor.



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

START TRANSACTION

Give Vasya's apartment to Seryozha.

Give Petya's apartment to Vasya.

begin

Give Malkor's Apartment to Petya Give

Seryozha's Money to Malkor IF_

ERROR: Give

Maedhros's 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 the payment of realtors (if any) is paid outside of the transaction stages.



However, Rosreestr does not support transactionality. All actions will be performed sequentially and independently, one after another, without rolling back the entire transaction 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 safe deposit box, with the conditions for access to it for Vasya, Petit, Seryozha (if no transaction is registered at all), and other actors, upon presentation by them of contracts registered by Rosreestr. (And by the way, banks do not independently verify the authenticity of contracts, that is, they trust the authenticity of the securities of the participants in the transaction).



In addition to the risks of incomplete execution of the transaction, another problem is that if other participants can move into their new housing without waiting for full registration (hello, the issue of underpayment of utility bills!), Then Maglor and Maedhros will not go to serve Melkor soon, and perhaps Maglor will not be able hold the Silmarils in his hands, he simply will not have time. Real estate transactions are carried out sequentially, and each transaction will take at least 9 business days to complete.



In addition, Rosreestr does not support the encumbrance of housing under construction under the DDU, but could, this is an elementary action in relation to a simple futures.



Now let's move on to the disadvantages and my wishes about the DBMS



1) The first is the absence of a version control system. If from the Delphi side I conduct development in my sandbox, and the changes I made do not appear in other programmers until the moment of their commit, then this is not the case with the DBMS. And even if they trust me with full (at least within the framework of the necessary for the task assigned to me) access to the combat database, and this happens, I cannot develop on it. While I'm debugging, everything will crash. What is this Stone Age ??? Sandbox the developers.



2) The second is the absence of predefined standardized tables describing the real world. Each company where I worked has its own table format describing the names (in Russian and (at least) English, in different Russian cases) for twelve months!



3) Third - and here I will use Orakl's terminology - there is no way to call a simple Insert or Update script using Returning, as we call Select. Perhaps these are not Orakl's problems, but Delphi + Oracle junction problems.



4) Fourth - the need to assign authority to the procedures and functions I create where I do not want to do this. I do not want to set, and then change, the user authority of the procedure and function. Why, if I did not explicitly write Grants, the system could not itself look at the objects involved, and, in accordance with the rights to act with them, grant 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 branch of the algorithm leads him to a request for which the user does not have permission, then it will throw it out with an error.



All Articles