El cliente interactúa con la base de datos.
Del sitio web , el autor de la pintura Jonathan Tiong.
Además de ser programador (principalmente en Delphi + varias bases de datos, últimamente ORACLE, + un poco de PHP), tengo un pasatiempo: la compra y venta de apartamentos. Compro un apartamento en la etapa de construcción de un constructor relativamente fiable a un buen precio (por ejemplo, ahora ese constructor es Samolët, apartamentos cerca de la estación de metro Nekrasovka están a la venta), espero la finalización del edificio (que frecuentemente sucede dos años después, con las ofertas económicas esto ocurre), hago renovaciones y luego lo vendo por el 95-100% de su precio de mercado.
Así que me encontré con el problema de la falta de transaccionalidad en el RosReestr.
El problema de la falta de transaccionalidad en las transacciones del RosReestr
En programación, 'Transacción', y en bienes raíces eso es 'Transacción con alternativa' (y también, como parte de ello, 'Contrato sobre caja de seguridad bancaria'), y allí las cosas son un poco más complicadas. Voy a contar.
Vasya llegó a ver un apartamento que está vendiendo Petya. Y a Vasya le gustó todo, incluido el precio, pero Vasya no tiene dinero. Así comienza nuestra historia.
Vasya tiene su propia propiedad, que tiene algunos valores que no son muy útiles para él: en la casa de al lado vivió Lomonosov, la altura del techo es de siete metros y medio, cerca hay una base de frutas y verduras y el mercado Sadovod, se puede llegar a pie al Aeroexpreso, bajo el apartamento hay un sótano de un metro de altura, y sobre el apartamento hay un ático conveniente para la observación astronómica. Vasya entiende que estas características aumentan el precio de su apartamento, pero no para él mismo. Y decide comprar el apartamento de Petya y vender el suyo. Pero lo vende precisamente para comprar el apartamento de Petya, y no solo por ello. En el lenguaje de los agentes inmobiliarios esto se llama 'Alternativa seleccionada'.
Ahora miremos esta situación desde el lado de Petya. La cuestión es que a Petya tampoco le interesa tener dinero devaluándose, él está vendiendo su apartamento para comprar uno en la ciudad élfica de Valinor, pero cuál exactamente - aún no lo ha mirado. En el lenguaje de los agentes inmobiliarios esto se llama 'Transacción con alternativa'.
Dos elfos de la Tierra Media, Maglor y Maedhros, tienen propiedades adecuadas (según los criterios de Petya) en la ciudad de Valinor, que están en venta urgente porque se van a servir a Melkor. En el lenguaje de los agentes inmobiliarios, esto se llama 'venta libre'.
Así que, Vasya encuentra un cliente, Seryozha. Ahora, Petya encuentra dos opciones que le convienen en la ciudad de Valinor. Pasamos a la formalización del trato. Supongamos, por simplicidad, que ninguno de los participantes en la transacción utiliza una hipoteca y que ninguno tiene a menores como copropietarios. Así, las siguientes acciones deben llevarse a cabo:
1. Seryozha le entrega el dinero a Petya.
2. Vasya le entrega su apartamento a Seryozha.
3. Petya le entrega su apartamento a Vasya.
4. O bien Maglor, o bien Maedhros, le entregan su apartamento en Valinor a Petya y reciben el dinero de Seryozha.
5. Malcor y Maedhros van a Mordor a servir a Melkor.
Lo ideal sería presentar en el Registro de la Propiedad el siguiente script para su ejecución:
INICIAR TRANSCACCIÓN
El apartamento de Vasya va a Seryozha.
El apartamento de Petya va a Vasya.
begin
El apartamento de Malcor va a Petya.
El dinero de Seryozha va a Malcor.
SI_ERROR:
El apartamento de Maedhros va a Petya.
El dinero de Seryozha va a Maedhros.
end
CONFIRMAR TRANSCACCIÓN
Este es un script simplificado de la transacción con una alternativa, suponiendo que todos los apartamentos tienen un solo propietario adulto (y capaz), que sus valores son iguales y que los honorarios de los agentes inmobiliarios (si los hay) se pagan independientemente de las etapas de la transacción.
Sin embargo, el Registro de la Propiedad no admite la transaccionalidad. Todas las acciones se llevarán a cabo de manera secuencial e independiente, una tras otra, sin revertir la transacción en su totalidad si una de ellas no se completa. Lo máximo que se puede lograr, considerando que el Registro de la Propiedad y el MFC no manejan la entrega de efectivo, es depositar el dinero en una caja de seguridad bancaria, con condiciones de acceso para Vasya, Petya, Seryozha (si ninguna transacción ha sido registrada) y otros participantes, haciendo valer su contrato registrado en el Registro de la Propiedad. (Y, por cierto, los bancos no realizan la verificación de autenticidad de los contratos por sí mismos, es decir, confían en la autenticidad de los documentos de los participantes en la transacción).
Además de los riesgos de una transacción incompleta, otro problema es que si otros participantes pueden mudarse a su nueva vivienda sin esperar la finalización total (¡hola, cuestión de pago de servicios públicos!), Maglor y Maedhros no irán pronto a servir a Melkor, y es posible que Maglor no pueda sostener los silmarils en sus manos, simplemente no tendrá tiempo. Las transacciones inmobiliarias se llevan a cabo de manera secuencial, y la formalización de cada transacción tomará no menos de 9 días laborables.
Además, el registro de la propiedad no admite la carga de una vivienda construida bajo un contrato de participación en la construcción, cuando podría hacerlo; es una acción elemental en relación con un simple futuro.
Ahora pasemos a las desventajas y mis deseos sobre el SGBD.
1) Primero, es la falta de un sistema de control de versiones. Si en Delphi desarrollo en mi entorno de pruebas, y los cambios que realizo no aparecerán para otros programadores hasta que se realice su confirmación, con el SGBD no es así. Y aunque me confíen un acceso completo (al menos dentro del marco necesario para la tarea que me han encomendado) a la base de datos en producción, algo que sucede, no puedo desarrollar en ella. Mientras estoy depurando, todo se colapsará. ¿Qué es esto, la Edad de Piedra? Crea un entorno de pruebas para los desarrolladores.
2) Segundo, es la falta de tablas estandarizadas preinstaladas que describan el mundo real. En cada empresa en la que he trabajado, hay su propio formato de tabla que describe los nombres (en ruso y (al menos) en inglés, en diferentes casos del ruso) de los doce meses.
3) Tercero, y aquí utilizaré la terminología de Oracle: no hay posibilidad de llamar a un simple script de Insert o Update utilizando Returning, como llamamos a Select. Puede que esto no sea un problema de Oracle, sino un problema de la integración entre Delphi y Oracle.
4) La cuarta es la necesidad de asignar a los procedimientos y funciones que creo permisos en aquellos casos donde no quiero hacerlo. No quiero establecer y luego cambiar los permisos de los usuarios para el procedimiento y la función. ¿Por qué, si no escribí claramente los Grant, el sistema no podría mirar los objetos involucrados y, de acuerdo con los derechos de acción sobre ellos, otorgar o no a ciertos usuarios el derecho a llamar a la función? Estoy dispuesto a escribir una palabra clave para esto al crear funciones y procedimientos. O, mejor aún, que el usuario comience la ejecución, y si el camino del algoritmo lo lleva a una solicitud para la que no tiene derechos, entonces que se genere un error.
Fuente: habr.com
