El cliente interactúa con la base de datos.
Del sitio http://corchaosis.ru , autor de la imagen Jonathan Tiong.
Además de ser programador (principalmente Delphi + todo tipo de DBMS diferentes, recientemente ORAKL, + un poco de PHP), tengo un hobby: comprar y vender apartamentos. Compro un apartamento en la etapa de construcción de un desarrollador más o menos confiable a un precio delicioso (por ejemplo, ahora un desarrollador de este tipo es Avión, los apartamentos cerca del metro Nekrasovka están a la venta), espero la entrega de la casa (a menudo dos años después, con ofertas económicas, esto sucede), lo hago en renovado y luego vendido por 95-100% de su precio de mercado.
Entonces, yo (como todos los demás) enfrenté el problema de la falta de transaccionalidad de RosReestr.
El problema de la falta de transacciones transaccionales de Rosreestr en la
programación de "Transacción", y en el sector inmobiliario es "Tratar con una alternativa" (y también, como parte de ella, "Acuerdo sobre una caja de seguridad"), y todo es un poco más complicado allí. Te lo estoy diciendo.
Vasya vino a ver el apartamento que vende Petya. Y a Vasya realmente 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 particularmente necesarios para él: Lomonosov vivía en la casa de al lado, la altura del techo es de siete metros y medio, hay una base de cultivo de frutas y el mercado Gardener cerca, se puede caminar hasta Aeroexpress, hay un sótano con una altura de 1 metro, 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 para él. Y decide comprar el apartamento de Petya y vender su apartamento. Pero venderlo para comprar el piso de Petit, y no solo. En el lenguaje de los agentes inmobiliarios, esto se llama - "Se selecciona la alternativa".
Ahora veamos esta situación desde la perspectiva de Petya. El hecho es que Petya tampoco está interesado en sentarse en depreciar el dinero, vende un apartamento para comprarse un apartamento en la ciudad élfica de Valinor, pero aún no ha mirado cuál. En el lenguaje de los agentes inmobiliarios, esto se llama - "Tratar con una alternativa".
Dos elfos de la Tierra Media, Maglor y Maedhros, tienen un inmueble adecuado (según el criterio de Petit) en la ciudad de Valinor, que se vende con urgencia, ya que son enviados 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. Pasamos al registro de la transacción. En aras de la simplicidad, digamos que ninguna de las partes de la transacción utiliza una hipoteca y no tiene un accionista minoritario. Por lo tanto, ahora deben llevarse a cabo las siguientes acciones:
1. Seryozha le da el dinero a Petya.
2. Vasya entrega su apartamento a Seryozha.
3. Petya le entrega su apartamento a Vasya.
4. O Maglor o Maedhros, entregan su apartamento en Valinor a Pete y reciben el dinero de Seryozha.
5. Malkor y Maedhros van a Mordor para servir a Melkor.
Sería ideal enviar el siguiente script a Rosreestr para su ejecución:
INICIAR TRANSACCIÓN
Entréguele el apartamento de Vasya a Seryozha.
Dale el apartamento de Petya a Vasya.
begin
Dale el apartamento de Malkor a Petya Dale
el dinero de Seryozha a Malkor IF_
ERROR: Dale
el apartamento de Maedhros a Petya
Dale el dinero de Seryozha a Maedhros
end COMPROMETE LA
TRANSACCIÓN
Este es un script de transacción simplificado con una alternativa, asumiendo que todos los apartamentos tienen un propietario adulto (y capaz), que sus precios son iguales y que el pago de los agentes inmobiliarios (si corresponde) se paga fuera de las etapas de la transacción.
Sin embargo, Rosreestr no admite la transaccionalidad. Todas las acciones se realizarán de forma secuencial e independiente, una tras otra, sin revertir la transacción en su totalidad si una de ellas no se ha completado. Lo máximo que se puede lograr, dado que Rosreestr y el MFC no trabajan con la transferencia de efectivo, es poner dinero en una caja de seguridad, con las condiciones de acceso a ella para Vasya, Petit, Seryozha (si no se registra ninguna transacción) y otros actores, previa presentación por ellos de los 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 valores de los participantes en la transacción).
Además de los riesgos de ejecución incompleta de la transacción, otro problema es que si otros participantes pueden mudarse a su nueva vivienda 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 a atender a Melkor pronto, y tal vez Maglor no pueda sostenga los Silmarils en sus manos, simplemente no tendrá tiempo. Las transacciones inmobiliarias se llevan a cabo de forma secuencial y cada transacción tardará al menos 9 días hábiles en completarse.
Además, Rosreestr no apoya el gravamen de viviendas en construcción bajo el DDU, pero podría, esta es una acción elemental en relación con un futuro simple.
Ahora pasemos a las desventajas y mis deseos sobre el DBMS.
1) El primero es la ausencia de un sistema de control de versiones. Si desde el lado de Delphi realizo el desarrollo en mi caja de arena y los cambios que hice no aparecen en otros programadores hasta el momento de su confirmación, entonces este no es el caso con el DBMS. E incluso si me confían acceso completo (al menos en el marco de lo necesario para la tarea que se me ha asignado) a la base de datos de combate, y esto sucede, no puedo desarrollarlo. Mientras depuro, todo se bloqueará. ¿Qué es esta Edad de Piedra ??? Sandbox a los desarrolladores.
2) El segundo es la ausencia de tablas estandarizadas predefinidas que describan el mundo real. Cada empresa en la que trabajé tiene su propio formato de tabla que describe los nombres (en ruso y (al menos) en inglés, en diferentes casos en ruso) durante doce meses.
3) Tercero, y aquí usaré la terminología de Orakl, no hay forma de llamar a un script simple de Insertar o Actualizar usando Retornar, como llamamos Seleccionar. Quizás estos no sean problemas de Orakl, sino problemas de unión de Delphi + Oracle.
4) Cuarto - la necesidad de asignar autoridad a los procedimientos y funciones que creo donde no quiero hacer esto. No quiero establecer, y luego cambiar, la autoridad del usuario del procedimiento y la función. ¿Por qué, si no escribí explícitamente Grants, el sistema por sí mismo no podría mirar los objetos involucrados y, de acuerdo con los derechos para actuar con ellos, otorgar o no a ciertos usuarios el derecho de llamar a la función? Estoy listo para escribir una palabra clave para esto al escribir funciones y procedimientos. O, mejor aún, deje que el usuario inicie la ejecución, y si la rama del algoritmo lo lleva a una solicitud para la que el usuario no tiene permiso, la arrojará con un error.