Le client interagit avec la base de données.
Sur le site http://corchaosis.ru , auteur de la photo Jonathan Tiong.
En plus d'être programmeur (principalement Delphi + toutes sortes de SGBD différents, récemment ORAKL, + un peu de PHP), j'ai un hobby - acheter et vendre des appartements. J'achète un appartement au stade de la construction à un promoteur plus ou moins fiable à un prix savoureux (par exemple, maintenant, un tel développeur est Avion, des appartements près du métro Nekrasovka sont à vendre), attendez la livraison de la maison (souvent deux ans plus tard, avec des offres bon marché cela se produit), je le fais en rénové puis vendu à 95-100% de son prix de marché.
Donc, j'ai (comme tout le monde) affronté le problème du manque de transactionnel de RosReestr.
Le problème du manque de transactions transactionnelles de Rosreestr
Dans la programmation "Transaction", et dans l'immobilier, c'est "Traiter avec une alternative" (ainsi que, dans le cadre de celui-ci, "Accord sur un coffre-fort"), et tout y est un peu plus compliqué. Je te dis.
Vasya est venue voir l'appartement que Petya vend. 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 des valeurs qui ne sont pas particulièrement nécessaires pour lui - Lomonosov vivait dans la maison voisine, la hauteur du plafond est de sept mètres et demi, il y a une base de culture de fruits et le marché du jardinier à proximité, vous pouvez marcher jusqu'à Aeroexpress, il y a un sous-sol d'une hauteur de 1 mètre, au-dessus de l'appartement il y a un grenier 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 appartement. Mais pour le vendre pour acheter l'appartement de Petit, et pas seulement. Dans le langage des agents immobiliers, cela s'appelle - «L'alternative est choisie».
Regardons maintenant cette situation du point de vue 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 un appartement pour 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 «Traiter avec une alternative».
Deux elfes de la Terre du Milieu, Maglor et Maedhros, ont un bien immobilier approprié (selon les critères de Petit) dans la ville de Valinor, qui est vendue de toute urgence, car ils sont envoyés pour desservir Melkor. Dans le langage des agents immobiliers, cela s'appelle la «vente libre».
Alors, Vasya trouve un client Seryozha. Maintenant, Petya trouve deux options qui lui conviennent dans la ville de Valinor. Nous allons à l'enregistrement de la transaction. Dans un souci de simplicité, disons qu'aucune des parties à la transaction n'utilise une hypothèque et n'a d'actionnaire minoritaire. Ainsi, les actions suivantes doivent maintenant avoir lieu:
1. Seryozha donne l'argent à Petya.
2. Vasya cède son appartement à Seryozha.
3. Petya cède son appartement à Vasya.
4. Soit Maglor, soit Maedhros, remettent leur appartement à Valinor à Pete et reçoivent l'argent de Seryozha.
5. Malkor et Maedhros vont au Mordor pour servir Melkor.
Il serait idéal d'envoyer le script suivant à Rosreestr pour exécution:
COMMENCER LA TRANSACTION
Donnez l'appartement de Vasya à Seryozha.
Donnez l'appartement de Petya à Vasya.
begin
Donner l'appartement de Malkor à Petya Donner
l'argent de Seryozha à Malkor IF_
ERROR: Donner
l'appartement de Maedhros à Petya's
Give l'argent de Seryozha à Maedhros
end
COMMIT TRANSACTION
Il s'agit d'un script de transaction simplifié avec une alternative, en supposant que tous les appartements ont un propriétaire adulte (et capable), que leurs prix sont égaux et que le paiement des agents immobiliers (le cas échéant) est payé en dehors des é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, l'une après l'autre, sans reculer l'ensemble de la transaction si l'une d'elles n'est pas terminée. Le maximum qui peut être atteint - étant donné que Rosreestr et le MFC ne travaillent pas avec le transfert d'espèces - est de mettre de l'argent dans un coffre-fort, avec les conditions d'accès pour Vasya, Petit, Seryozha (si aucune transaction n'est enregistrée du tout), et d'autres acteurs, sur présentation par eux des contrats enregistrés par Rosreestr. (Et en passant, les banques ne vérifient pas indépendamment l'authenticité des contrats, c'est-à-dire qu'elles font confiance à l'authenticité des titres des participants à la transaction).
Outre les risques d'exécution incomplète de la transaction, un autre problème est que si d'autres participants peuvent emménager dans leur nouveau logement sans attendre l'inscription complète (bonjour, la question du sous-paiement des factures de services publics!), Alors Maglor et Maedhros n'iront pas bientôt desservir Melkor, et peut-être que Maglor ne pourra pas tenir les Silmarils entre ses mains, il n'aura tout simplement pas le temps. Les transactions immobilières sont effectuées de manière séquentielle, et chaque transaction prendra au moins 9 jours ouvrables à compléter.
En outre, Rosreestr ne supporte pas la charge de logements en construction sous la DDU, mais pourrait, il s'agit d'une action élémentaire par rapport à un futur simple.
Passons maintenant aux inconvénients 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 mène le développement dans mon bac à sable, et que les modifications que j'ai apportées n'apparaissent pas dans les autres programmeurs jusqu'au moment de leur validation, alors ce n'est pas le cas avec le SGBD. Et même s'ils me font confiance avec un accès complet (au moins dans le cadre de la tâche requise pour ma tâche) à la base de données de combat, et cela arrive, je ne peux pas développer dessus. Pendant le débogage, tout va planter. Quel est cet âge de pierre ??? Sandbox les développeurs.
2) Le second est l'absence de tableaux standardisés prédéfinis décrivant le monde réel. Chaque entreprise où 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 la langue russe) pendant douze mois!
3) Troisièmement - et j'utiliserai ici la terminologie d'Orakl - il n'y a aucun moyen d'appeler un simple script d'insertion ou de mise à jour en utilisant Returning, comme nous l'appelons Select. Ce ne sont peut-être pas les problèmes d'Orakl, mais des problèmes de jonction Delphi + Oracle.
4) Quatrièmement - la nécessité d'attribuer une autorité aux procédures et aux fonctions que je crée là où je ne veux pas faire cela. Je ne souhaite pas définir, puis modifier, les droits d'utilisateur de la procédure et de la fonction. Pourquoi, si je n'écrivais pas explicitement Grants, le système ne pouvait pas lui-même regarder les objets impliqués et, conformément aux droits d'agir avec eux, accorder ou non à certains utilisateurs le droit d'appeler la 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 démarrer l'exécution, et si la branche de l'algorithme le conduit à une requête pour laquelle l'utilisateur n'a pas de droits, alors il la rejettera avec une erreur.