Mis deseos para el DBMS del futuro, así como para Rosreestr en términos de transaccionalidad.

Mis deseos para el DBMS del futuro, así como para Rosreestr en términos de transaccionalidad.
El cliente interactúa con la base de datos.
Del sitio http://corchaosis.ru, de Jonathan Tiong.

Además de ser programador (principalmente Delphi + todo tipo de DBMS diferentes, recientemente ORACLE, + un poco de PHP), tengo un pasatiempo: comprar y vender apartamentos. Compro un apartamento durante la etapa de construcción a un desarrollador más o menos confiable a buen precio (por ejemplo, ahora Samolet es un desarrollador de este tipo, se venden apartamentos cerca de la estación de metro Nekrasovka), espero a que me entreguen la casa (a menudo dos años después pasa lo mismo con ofertas económicas), lo renuevo y luego lo vendo al 95-100% de su precio de mercado.

Entonces, yo (como todos los demás) me enfrenté al problema de la falta de transaccionalidad de RosReestr.

El problema de la falta de transacciones transaccionales de Rosreestr

En programación es “Transacción”, y en bienes raíces es “Transacción con Alternativa” (y también, como parte de ella, “Acuerdo de Caja de Seguridad”), y es un poco más complicado. Te lo estoy diciendo.

Vasya vino a ver el apartamento que vendía Petya. Y a Vasya le gustó mucho 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 particularmente necesarios para él: Lomonosov vivía en la casa vecina, la altura del techo es de siete metros y medio, hay una base de frutas y verduras y el mercado Sadovod. cerca se puede tomar el Aeroexpress, debajo del apartamento hay un sótano de 1 metro de altura, encima del apartamento hay un ático conveniente para observaciones astronómicas. Vasya comprende que estas características aumentan el precio de su apartamento, pero no el de él. Y decide comprar el apartamento de Petya y vender el suyo. Pero vender precisamente para comprar el apartamento de Petya, y no solo. En el lenguaje de los agentes inmobiliarios, esto se llama "Se ha seleccionado una alternativa".

Ahora veamos esta situación desde el lado de Petya. El hecho es que Petya tampoco está interesado en quedarse con dinero depreciado, está vendiendo el apartamento para comprarse un apartamento en la ciudad élfica de Valinor, pero aún no ha mirado en cuál. En el lenguaje de los agentes inmobiliarios, esto se llama "acuerdo con una alternativa".

Dos elfos de la Tierra Media, Maglor y Maedhros, tienen bienes inmuebles adecuados (según el criterio de Petya) en la ciudad de Valinor, que se venden con urgencia, ya que van a servir a Melkor. En el lenguaje de los agentes inmobiliarios esto se llama “Venta Libre”.

Entonces Vasya encuentra un cliente, Seryozha. Ahora Petya encuentra dos opciones adecuadas para él en la ciudad de Valinor. Estamos a punto de cerrar el trato. Para simplificar, supongamos que ninguna de las partes de la transacción utiliza una hipoteca y no tiene menores como propietarios de acciones. Por lo tanto, ahora se deben realizar las siguientes acciones:
1. Seryozha le da dinero a Petya.
2. Vasya le da su apartamento a Seryozha.
3. Petya le da su apartamento a Vasya.
4. Maglor o Maedhros transfieren su apartamento en Valinor a Peta y reciben el dinero de Seryozha.
5. Malkor y Maedhros van a Mordor para servir a Melkor.

Lo ideal sería enviar el siguiente script a Rosreestr para su ejecución:

INICIAR TRANSACCIÓN
Dale el apartamento de Vasya a Seryozha.
Dale el apartamento de Petya a Vasya.
comenzar
Dale el apartamento de Malkor a Petya.
Dale el dinero de Seryozha a Malkor.
SI_ERROR:
Entrega el apartamento de Maedhros a Petya.
Dale el dinero de Seryozha a Maedhros.
final
TRANSACCIÓN DE COMPROMISO

Este es un guión de transacción simplificado con una alternativa, que supone que todos los apartamentos tienen un propietario adulto (y capaz), que sus valores son iguales y que los agentes inmobiliarios (si los hay) reciben su pago independientemente de las etapas de la transacción.

Sin embargo, Rosreestr no apoya la transaccionalidad. Todas las acciones se realizarán de forma secuencial e independiente, una tras otra, sin revertir la transacción en su conjunto si una de ellas falla. Lo máximo que se puede lograr - dado que Rosreestr y el MFC no trabajan con la transferencia de efectivo - es depositar el dinero en una caja de seguridad, con las condiciones para que Vasya, Petya, Seryozha puedan acceder a ella (si no hay transacción está registrado en absoluto), y otros actores, previa presentación de contratos registrados por Rosreestr. (Y, por cierto, los bancos no verifican de forma independiente la autenticidad de los contratos, es decir, confían en la autenticidad de los documentos de las partes de la transacción).

Además de los riesgos de que la transacción no se complete por completo, otro problema es que si otros participantes pueden mudarse a su nuevo hogar sin esperar el registro completo (¡hola, el problema del pago insuficiente de las facturas de servicios públicos!), entonces Maglor y Maedhros no irán pronto a servir a Melkor, y tal vez Maglor no pueda hacerlo, simplemente no tendrá tiempo para tener los Silmarils en sus manos. Las transacciones inmobiliarias se realizan de forma secuencial, y la ejecución de cada transacción tomará al menos 9 días hábiles.

Además, Rosreestr no apoya el gravamen de las viviendas que se construyen en el marco de la DDU, pero podría hacerlo; se trata de una acción elemental en relación con un futuro simple.

Pasemos ahora a las deficiencias y mis deseos sobre el DBMS.

1) La primera es la falta de un sistema de control de versiones. Si en el lado de Delphi desarrollo en mi propia zona de pruebas y los cambios que hago no aparecerán a otros programadores hasta que estén confirmados, entonces este no es el caso con el DBMS. E incluso si se me confía el acceso total (al menos dentro del alcance de lo necesario para la tarea que se me ha asignado) a la base de datos de combate, y esto sucede, no puedo desarrollarla. Mientras estoy depurando, todo colapsará. ¿Qué clase de Edad de Piedra es esta? Crea una zona de pruebas para desarrolladores.

2) El segundo es la falta de tablas estandarizadas predefinidas que describan el mundo real. ¡Cada empresa para la que he trabajado tiene su propio formato de tabla que describe los nombres (en ruso y (al menos) inglés, en diferentes casos de ruso) de doce meses!

3) En tercer lugar, y aquí usaré la terminología de Oracle, no hay forma de llamar a un script simple de Insertar o Actualizar que use Devolución, de la misma manera que llamamos Seleccionar. Quizás estos no sean problemas de Oracle, sino problemas en la interfaz Delphi + Oracle.

4) Cuarto: la necesidad de asignar poderes a los procedimientos y funciones que creo cuando no quiero hacerlo. No quiero configurar y luego cambiar los permisos de usuario para procedimientos y funciones. ¿Por qué, si no escribí explícitamente Grants, el propio sistema no podría mirar los objetos involucrados y, de acuerdo con los derechos para actuar con ellos, otorgar a ciertos usuarios el derecho de llamar a una función o no? Estoy listo para escribir una palabra clave para esto al escribir funciones y procedimientos. O, mejor aún, dejar que el usuario comience la ejecución, y si la rama del algoritmo lo lleva a una solicitud para la cual el usuario no tiene derechos, la descartará con un error.

Fuente: habr.com

Añadir un comentario