Le client interagit avec la base de données.
Du site , auteur de l'œuvre Jonathan Tiong.
En plus d'être programmeur (principalement Delphi et divers SGBD, dernièrement ORACLE, plus un peu de PHP), j'ai une passion : l'achat et la vente d'appartements. J'achète un appartement lors de la construction auprès d'un promoteur relativement fiable à un bon prix (par exemple, en ce moment, un tel promoteur est Samolit, des appartements près de la station de métro Nekrasovka sont en vente), j'attends l'achèvement de l'immeuble (souvent deux ans plus tard, cela arrive avec des offres peu chères), je fais des rénovations et ensuite je le vends à 95-100 % de son prix sur le marché.
Ainsi, je (comme tout le monde) me suis heurté au problème de l'absence de transactionnalité chez Rosreestr.
Le problème de l'absence de transactionnalité des transactions chez Rosreestr
En programmation, on parle de « Transaction », tandis qu'en immobilier, cela se traduit par « Transaction avec alternative » (et aussi, comme partie de celle-ci, « Contrat de dépôt bancaire »), et c'est un peu plus compliqué. Je vais expliquer.
Vasia est venu visiter l'appartement que Petya vend. Et Vasia a beaucoup aimé, y compris le prix, mais il n'a pas d'argent. C'est ainsi que commence notre histoire.
Vasia possède un bien immobilier qui a certaines valeurs qui ne lui sont pas vraiment utiles : dans l'immeuble voisin a vécu Lomonossov, la hauteur sous plafond est de sept mètres et demi, il y a une base de fruits et légumes à proximité et le marché Sadovod, on peut y aller à pied pour prendre l'Aeroexpress, il y a une cave de 1 m de haut sous l'appartement, et au-dessus, il y a un grenier idéal pour l'observation astronomique. Vasia comprend que ces caractéristiques augmentent le prix de son appartement, mais pas pour lui. Et il décide d'acheter l'appartement de Petya et de vendre le sien. Mais il veut vendre son appartement précisément pour acheter celui de Petya, et non pas simplement. Dans le jargon des agents immobiliers, cela s'appelle « Alternative trouvée ».
Voyons maintenant cette situation du point de vue de Petya. En fait, Petya n'est pas non plus intéressé à rester assis sur des fonds dévalués, il vend son appartement pour pouvoir s'acheter un appartement dans la ville elfique de Valinor, mais il n'a pas encore regardé lequel. Dans le jargon des agents immobiliers, cela s'appelle une « Transaction avec alternative ».
Deux elfes de la Terre du Milieu, Maglor et Maedhros, possèdent un bien immobilier approprié (aux critères de Petya) dans la ville de Valinor, qu'ils vendent en urgence car ils partent servir Melkor. Dans le jargon immobilier, c'est ce qu'on appelle une « vente libre ».
Ainsi, Vasya trouve son client Seryozha. Maintenant, Petya trouve deux options qui lui conviennent dans la ville de Valinor. Passons à la conclusion de la transaction. Supposons pour simplifier que personne parmi les participants à la transaction n'utilise de prêt hypothécaire et n'a d'enfants mineurs comme copropriétaires. Ainsi, les actions suivantes doivent maintenant être effectuées :
1. Seryozha remet de l'argent à Petya.
2. Vasya remet son appartement à Seryozha.
3. Petya remet son appartement à Vasya.
4. Soit Maglor, soit Maedhros, remettent leur appartement à Valinor à Petya et reçoivent l'argent de Seryozha.
5. Malcor et Maedhros partent à Mordor servir Melkor.
Il serait idéal de soumettre le scénario suivant à Rosreestr pour exécution :
DÉBUT DE LA TRANSACTION
Remettre l'appartement de Vasya à Seryozha.
Remettre l'appartement de Petya à Vasya.
begin
Remettre l'appartement de Malcor à Petya
Remettre l'argent de Seryozha à Malcor
SI_ERREUR :
Remettre l'appartement de Maedhros à Petya
Remettre l'argent de Seryozha à Maedhros
end
VALIDER LA TRANSACTION
Ceci est un scénario simplifié de la transaction avec une alternative, supposant que tous les appartements ont un seul propriétaire adulte (et capable), que leurs valeurs sont égales, et que les frais des agents immobiliers (s'ils existent) sont payés sans lien avec les étapes de la transaction.
Cependant, Rosreestr ne prend pas en charge la transaction. Toutes les actions seront effectuées de manière séquentielle et indépendante, les unes après les autres, sans possibilité d'annuler la transaction dans son ensemble si l'une d'entre elles échoue. Au maximum, ce qui peut être réalisé — étant donné que Rosreestr et MFC ne traitent pas la remise d'argent liquide — est de déposer de l'argent dans une cellule bancaire, sous condition d'accès à celle-ci pour Vasya, Petya, Seryozha (si aucune transaction n'est enregistrée), et autres parties impliquées, sur présentation de contrats enregistrés par Rosreestr. (Et d'ailleurs, les banques ne vérifient pas elles-mêmes l'authenticité des contrats, c'est-à-dire qu'elles font confiance à l'authenticité des documents des participants à la transaction).
Outre les risques de transaction incomplète, un autre problème est que si d'autres participants peuvent emménager dans leur nouveau logement sans attendre l'achèvement complet (bonjour, la question des paiements de services publics non réglés !), alors Maglor et Maedhros ne se mettront pas en route pour servir Melkor de sitôt, et il se pourrait que Maglor ne puisse pas tenir les Silmarils dans ses mains, il n'a tout simplement pas le temps. Les transactions immobilières se font de manière séquentielle, et la finalisation de chaque transaction prendra au moins 9 jours ouvrables.
En outre, le Rosreestr ne prend pas en charge la charge d'un logement construit selon un contrat de construction, alors qu'il pourrait le faire, c'est une action élémentaire concernant un simple futur contrat.
Passons maintenant aux inconvénients et à mes souhaits concernant les SGBD.
1) Premièrement — c'est l'absence d'un système de contrôle de version. Du côté de Delphi, je développe dans mon bac à sable, et les changements que j'apporte n'apparaîtront pas chez d'autres programmeurs avant qu'ils ne soient validés, mais ce n'est pas le cas avec le SGBD. Même si on me fait confiance pour un accès complet (du moins dans le cadre de la tâche qui m'a été assignée) à la base de données de production, ce qui arrive, je ne peux pas y développer. Pendant que je fais des tests, tout s'effondre. C'est quoi, cette époque de pierre ??? Créez un bac à sable pour les développeurs.
2) Deuxièmement — c'est l'absence de tables standardisées préinstallées décrivant le monde réel. Dans chaque entreprise où j'ai travaillé, il y a son propre format de table, décrivant les noms (en russe et (du moins) en anglais, dans différents cas de la langue russe) des douze mois !
3) Troisièmement — et ici je vais utiliser la terminologie d'Oracle — il n'est pas possible d'appeler un simple script Insert ou Update utilisant Returning, comme nous appelons Select. Peut-être que ce n'est pas un problème d'Oracle, mais un problème d'interconnexion entre Delphi et Oracle.
4) Quatrième point : la nécessité d'attribuer des permissions aux procédures et fonctions que je crée là où je ne veux pas le faire. Je ne veux pas définir, puis changer, les permissions des utilisateurs pour la procédure et la fonction. Pourquoi, si je n'ai pas explicitement écrit des Grant, le système ne pourrait-il pas vérifier les objets concernés et, en fonction des droits d'action sur ceux-ci, accorder ou non aux utilisateurs le droit d'appeler la fonction ? Je suis prêt à écrire un mot clé pour cela lors de la rédaction des fonctions et procédures. Ou, encore mieux, que l'utilisateur commence l'exécution, et si le chemin algorithmique le conduit à une requête à laquelle l'utilisateur n'a pas accès, il serait éjecté avec une erreur.
Source : habr.com
