Le client interagit avec la base de données.
Du site , de Jonathan Tiong.
En plus du fait que je suis programmeur (principalement Delphi + toutes sortes de SGBD différents, récemment ORACLE, + un peu PHP), j'ai un passe-temps : acheter et vendre des appartements. J'achète un appartement en phase de construction auprès d'un promoteur plus ou moins fiable à un bon prix (par exemple, maintenant Samolet est un tel promoteur, des appartements près de la station de métro Nekrasovka sont à vendre), j'attends que la maison soit livrée (souvent deux des années plus tard, cela se produit avec des offres bon marché), je le rénove puis le vends à 95-100 % de son prix de marché.
Ainsi, j’ai (comme tout le monde) été confronté au problème du manque de transactionnalité de RosReestr.
Le problème du manque de transactions transactionnelles à Rosreestr
En programmation, c'est « Transaction », et en immobilier, c'est « Transaction avec Alternative » (et aussi, dans le cadre de celui-ci, « Accord de coffre-fort »), et c'est un peu plus compliqué. Je te dis.
Vassia est venue voir l'appartement que Petya vendait. Et Vasya a vraiment tout aimé, y compris le prix, mais Vasya n'a pas d'argent. C'est ainsi que commence notre histoire.
Vasya a sa propre propriété, qui a certaines valeurs qui ne lui sont pas particulièrement nécessaires - Lomonossov vivait dans la maison voisine, la hauteur sous plafond est de sept mètres et demi, il y a une base de fruits et légumes et le marché de Sadovod à proximité, vous pouvez prendre l'Aeroexpress, sous l'appartement il y a un sous-sol d'une hauteur de 1 mètre, il y a un grenier au dessus de l'appartement, pratique pour les observations astronomiques. Vasya comprend que ces caractéristiques augmentent le prix de son appartement, mais pas pour lui-même. Et il décide d’acheter l’appartement de Petya et de vendre son propre appartement. Mais vendre précisément pour acheter l’appartement de Petya, et pas seulement. Dans le langage des agents immobiliers, cela s’appelle « Une alternative a été sélectionnée ».
Regardons maintenant cette situation du côté de Petya. Le fait est que Petya n'est pas non plus intéressé à s'asseoir sur de l'argent déprécié, il vend l'appartement afin de s'acheter un appartement dans la ville elfique de Valinor, mais il n'a pas encore regardé lequel. Dans le langage des agents immobiliers, cela s’appelle « un accord avec une alternative ».
Deux elfes de la Terre du Milieu, Maglor et Maedhros, possèdent des biens immobiliers appropriés (selon les critères de Petya) dans la ville de Valinor, qui sont vendus d'urgence, car ils vont servir Melkor. Dans le langage des agents immobiliers, cela s’appelle « Vente Libre ».
Ainsi, Vasya trouve un client, Seryozha. Maintenant, Petya trouve deux options qui lui conviennent dans la ville de Valinor. Nous sommes sur le point de finaliser l'accord. Supposons pour simplifier qu'aucune des parties à la transaction ne recourt à une hypothèque et n'ait des mineurs comme actionnaires. Ainsi, les actions suivantes doivent maintenant être effectuées :
1. Seryozha donne de l'argent à Petya.
2. Vasya cède son appartement à Seryozha.
3. Petya cède son appartement à Vasya.
4. Maglor ou Maedhros transfèrent leur appartement de Valinor à Peta et reçoivent l'argent de Seryozha.
5. Malkor et Maedhros se rendent au Mordor pour servir Melkor.
Il serait idéal de soumettre le script suivant à Rosreestr pour exécution :
DÉMARRER LA TRANSACTION
Donnez l'appartement de Vasya à Seryozha.
Donnez l'appartement de Petya à Vasya.
commencer
Donnez l'appartement de Malkor à Petya
Donnez l'argent de Seryozha à Malkor
SI_ERREUR :
Donnez l'appartement de Maedhros à Petya
Donnez l'argent de Seryozha à Maedhros
fin
COMMIT TRANSACTION
Il s'agit d'un script de transaction simplifié avec une alternative, qui suppose que tous les appartements ont un propriétaire adulte (et capable), que leurs valeurs sont égales et que les agents immobiliers (le cas échéant) sont payés quelles que soient les étapes de la transaction.
Cependant, Rosreestr ne prend pas en charge la transactionnalité. Toutes les actions seront exécutées séquentiellement et indépendamment, les unes après les autres, sans annuler la transaction dans son ensemble si l'une d'entre elles échoue. Le maximum qui peut être atteint - étant donné que Rosreestr et le MFC ne travaillent pas avec le transfert d'argent - est de déposer l'argent dans un coffre-fort, avec les conditions d'accès à celui-ci par Vasya, Petya, Seryozha (si aucune transaction est enregistré du tout), et d'autres acteurs, sur présentation des contrats enregistrés par Rosreestr. (Et d'ailleurs, les banques ne vérifient pas de manière indépendante l'authenticité des contrats, c'est-à-dire qu'elles font confiance à l'authenticité des papiers des parties à la transaction).
Outre les risques d'achèvement incomplet de la transaction, un autre problème est que si d'autres participants peuvent emménager dans leur nouveau logement sans attendre l'enregistrement complet (bonjour, le problème du sous-paiement des factures de services publics !), alors Maglor et Maedhros n'iront pas de sitôt. servir Melkor, et peut-être que Maglor n'en sera pas capable, il n'aura tout simplement pas le temps de tenir les Silmarils entre ses mains. Les transactions immobilières sont effectuées de manière séquentielle et l'exécution de chaque transaction prendra au moins 9 jours ouvrables.
De plus, Rosreestr ne soutient pas la charge des logements construits dans le cadre du DDU, mais elle le pourrait, il s'agit d'une action élémentaire par rapport à un avenir simple.
Passons maintenant aux lacunes et à mes souhaits concernant le SGBD
1) Le premier est l’absence de système de contrôle de version. Si du côté Delphi je développe dans mon propre bac à sable et que les modifications que j'apporte n'apparaîtront pas aux autres programmeurs tant qu'elles ne seront pas validées, alors ce n'est pas le cas avec le SGBD. Et même si on me confie un accès complet (au moins dans la limite de ce qui est nécessaire à la tâche qui m'est assignée) à la base de données de combat, et cela arrive, je ne peux pas m'y développer. Pendant que je débogue, tout va s'effondrer. De quel genre d'âge de pierre s'agit-il ??? Créez un bac à sable pour les développeurs.
2) La seconde est le manque de tableaux standardisés prédéfinis décrivant le monde réel. Chaque entreprise pour laquelle j'ai travaillé a son propre format de tableau décrivant les noms (en russe et (au moins) en anglais, dans différents cas de russe) des douze mois !
3) Troisièmement - et j'utiliserai ici la terminologie Oracle - il n'y a aucun moyen d'appeler un simple script d'insertion ou de mise à jour qui utilise Returning, de la même manière que nous appelons Select. Ce ne sont peut-être pas des problèmes Oracle, mais des problèmes à l'interface Delphi + Oracle.
4) Quatrièmement - la nécessité d'attribuer des pouvoirs aux procédures et fonctions que je crée là où je ne veux pas le faire. Je ne souhaite pas définir puis modifier les autorisations des utilisateurs pour les procédures et les fonctions. Pourquoi, si je n’écrivais pas explicitement Grants, le système lui-même ne pourrait-il pas regarder les objets impliqués et, conformément aux droits d’agir avec eux, accorder ou non à certains utilisateurs le droit d’appeler une fonction ? Je suis prêt à écrire un mot-clé pour cela lors de l'écriture de fonctions et de procédures. Ou, mieux encore, laissez l'utilisateur lancer l'exécution, et si la branche de l'algorithme le conduit à une requête pour laquelle l'utilisateur n'a pas de droits, il la rejettera avec une erreur.
Source: habr.com