O cliente interactúa coa base de datos.
Dende o sitio , por Jonathan Tiong.
Ademais de que son programador (principalmente Delphi + todo tipo de DBMS diferentes, recentemente ORACLE, + un pouco de PHP), teño un hobby: comprar e vender pisos. Merco un apartamento durante a fase de construción dun promotor máis ou menos fiable a un bo prezo (por exemplo, agora Samolet é un promotor deste tipo, apartamentos preto da estación de metro de Nekrasovka están á venda), agarde a que se entregue a casa (moitas veces dous anos despois, isto ocorre con ofertas baratas), renovono e véndoo por un 95-100% do seu prezo de mercado.
Entón, eu (como todos) enfrontábame ao problema da falta de transaccionalidade de RosReestr.
O problema da falta de transaccións transaccionais de Rosreestr
Na programación é "Transacción", e no sector inmobiliario é "Transacción con Alternativa" (e tamén, como parte dela, "Acordo de caixa de seguridade"), e é un pouco máis complicado. Dígocho.
Vasya veu ver o apartamento que Petya estaba a vender. E a Vasya gustoulle moito todo, incluído o prezo, pero Vasya non ten diñeiro. Así comeza a nosa historia.
Vasya ten a súa propia propiedade, que ten algúns valores que non son especialmente necesarios para el - Lomonosov vivía na casa veciña, a altura do teito é de sete metros e medio, hai unha base de froitas e verduras e o mercado de Sadovod. preto, podes camiñar no Aeroexpress, debaixo do apartamento hai un soto cunha altura de 1 metro, hai un faiado enriba do apartamento conveniente para observacións astronómicas. Vasya entende que estas características aumentan o prezo do seu apartamento, pero non por si mesmo. E decide comprar o apartamento de Petya e vender o seu propio apartamento. Pero vendendo precisamente para comprar o apartamento de Petya, e non só. Na linguaxe dos axentes inmobiliarios, isto chámase "Seleccionouse unha alternativa".
Agora vexamos esta situación desde o lado de Petya. O feito é que Petya tampouco está interesado en sentarse a depreciar o diñeiro, está a vender o apartamento para comprarse un apartamento na cidade elfica de Valinor, pero aínda non mirou cal. Na linguaxe dos corretores de inmobles, isto chámase "Trato cunha alternativa".
Dous elfos da Terra Media, Maglor e Maedhros, teñen bens inmobles axeitados (segundo o criterio de Petya) na cidade de Valinor, que se venden con urxencia, xa que van servir a Melkor. Na linguaxe dos corretores de inmobles, isto chámase "Venda gratuíta".
Entón, Vasya atopa un cliente, Seryozha. Agora, Petya atopa dúas opcións adecuadas para el na cidade de Valinor. Estamos a piques de finalizar o acordo. Supoñamos por simplicidade que ningunha das partes da transacción utiliza unha hipoteca e non ten menores como accionistas. Polo tanto, agora deben realizarse as seguintes accións:
1. Seryozha dálle diñeiro a Petya.
2. Vasya dálle o seu apartamento a Seryozha.
3. Petya dálle o seu apartamento a Vasya.
4. Maglor ou Maedhros transfieren o seu apartamento en Valinor a Peta e reciben o diñeiro de Seryozha.
5. Malkor e Maedhros van a Mordor para servir a Melkor.
O ideal sería enviar o seguinte script a Rosreestr para a súa execución:
INICIO A TRANSACCIÓN
Dálle o apartamento de Vasya a Seryozha.
Dálle o apartamento de Petya a Vasya.
comezar
Dálle o apartamento de Malkor a Petya
Dálle o diñeiro de Seryozha a Malkor
IF_ERROR:
Dálle o apartamento de Maedhros a Petya
Dálle o diñeiro de Seryozha a Maedhros
final
COMPROMETAR TRANSACCIÓN
Este é un script de transacción simplificado cunha alternativa, que supón que todos os apartamentos teñen un propietario adulto (e capaz), que os seus valores son iguais e que se paga aos axentes inmobiliarios (se os houber) independentemente das fases da transacción.
Non obstante, Rosreestr non admite a transaccionalidade. Todas as accións realizaranse de forma secuencial e independente, unha tras outra, sen que a transacción se retrotraiga no seu conxunto se unha delas falla. O máximo que se pode acadar -dado que Rosreestr e o MFC non funcionan coa transferencia de efectivo- é depositar o diñeiro nunha caixa de seguridade, coas condicións de acceso a ela por Vasya, Petya, Seryozha (se non hai transacción). está rexistrado), e outros actores, previa presentación de contratos rexistrados por Rosreestr. (E por certo, os bancos non verifican de forma independente a autenticidade dos contratos, é dicir, confían na autenticidade dos papeis das partes da transacción).
Ademais dos riscos de finalización incompleta da transacción, outro problema é que se outros participantes poden mudarse á súa nova casa sen esperar o rexistro completo (¡ola, o problema do pago insuficiente das facturas de servizos públicos!), Maglor e Maedhros non irán pronto a servir a Melkor, e quizais Maglor non poida, simplemente non terá tempo de manter os Silmarils nas súas mans. As transaccións inmobiliarias realízanse de forma secuencial e a execución de cada transacción levará polo menos 9 días hábiles.
Ademais, Rosreestr non apoia o gravame de vivendas que se están construíndo baixo a DDU, pero podería, esta é unha acción elemental en relación a un simple futuros.
Agora pasemos ás carencias e aos meus desexos sobre o DBMS
1) O primeiro é a falta dun sistema de control de versións. Se no lado de Delphi desenvolvo no meu propio sandbox e os cambios que fago non aparecerán a outros programadores ata que estean comprometidos, entón este non é o caso do DBMS. E aínda que se me confíe o acceso total (polo menos no ámbito do necesario para a tarefa que se me encomenda) á base de datos de combate, e isto ocorre, non podo desenvolver nela. Mentres estou depurando, todo colapsará. Que tipo de Idade de Pedra é esta??? Fai un sandbox para desenvolvedores.
2) O segundo é a falta de táboas estandarizadas predefinidas que describan o mundo real. Cada empresa para as que traballei ten o seu propio formato de táboa que describe os nomes (en ruso e (polo menos) en inglés, en diferentes casos de ruso) de doce meses.
3) En terceiro lugar, e aquí vou usar a terminoloxía de Oracle, non hai forma de chamar a un simple script de Inserción ou Actualización que use Retorno, do mesmo xeito que chamamos Select. Quizais estes non sexan problemas de Oracle, senón problemas na interface de Delphi + Oracle.
4) Cuarto - a necesidade de asignar poderes aos procedementos e funcións que creo onde non quero facelo. Non quero configurar e despois cambiar os permisos dos usuarios para procedementos e funcións. Por que, se non escribín de forma explícita Grants, o propio sistema non podería mirar os obxectos implicados e, de acordo cos dereitos para actuar con eles, conceder ou non a determinados usuarios o dereito de chamar a unha función? Estou preparado para escribir unha palabra clave para isto ao escribir funcións e procedementos. Ou, mellor aínda, deixar que o usuario inicie a execución, e se a rama do algoritmo o leva a unha solicitude para a que o usuario non ten dereitos, tiraraa cun erro.
Fonte: www.habr.com