O cliente interage com o banco de dados.
Do site , de Jonathan Tiong.
Além de ser programador (principalmente Delphi + todos os tipos de SGBDs diferentes, recentemente ORACLE, + um pouco de PHP), tenho um hobby - comprar e vender apartamentos. Eu compro um apartamento durante a fase de construção de um desenvolvedor mais ou menos confiável por um bom preço (por exemplo, agora Samolet é um desenvolvedor, apartamentos perto da estação de metrô Nekrasovka estão à venda), espero a entrega da casa (geralmente dois anos depois, isso acontece com ofertas baratas), eu o renovo e depois vendo por 95-100% do preço de mercado.
Então, eu (como todo mundo) enfrentei o problema da falta de transacionalidade do RosReestr.
O problema da falta de transações transacionais de Rosreestr
Na programação é “Transação”, e no imobiliário é “Transação com Alternativa” (e também, como parte dela, “Contrato de Cofre”), e é um pouco mais complicado. Estou dizendo a você.
Vasya veio ver o apartamento que Petya estava vendendo. E Vasya gostou muito de tudo, inclusive do preço, mas Vasya não tem dinheiro. É assim que nossa história começa.
Vasya tem uma propriedade própria, que tem alguns valores que não são particularmente necessários para ele - Lomonosov morava na casa vizinha, o pé-direito é de sete metros e meio, há uma base de frutas e vegetais e o mercado Sadovod nas proximidades você pode caminhar pelo Aeroexpress, embaixo do apartamento há um porão com 1 metro de altura, acima do apartamento há um sótão conveniente para observações astronômicas. Vasya entende que esses recursos aumentam o preço de seu apartamento, mas não para si mesmo. E ele decide comprar o apartamento de Petya e vender seu próprio apartamento. Mas vender justamente para comprar o apartamento de Petya, e não apenas. Na linguagem dos corretores de imóveis, isso se chama “Uma alternativa foi selecionada”.
Agora vamos analisar esta situação do lado de Petya. O fato é que Petya também não está interessado em desvalorizar o dinheiro, ele está vendendo o apartamento para comprar um apartamento na cidade élfica de Valinor, mas ainda não olhou qual. Na linguagem dos corretores de imóveis, isso é chamado de “acordo com uma alternativa”.
Dois elfos da Terra Média, Maglor e Maedhros, possuem imóveis adequados (aos critérios de Petya) na cidade de Valinor, que são vendidos com urgência, pois vão servir Melkor. Na linguagem dos corretores de imóveis isso se chama “Venda Gratuita”.
Então, Vasya encontra um cliente, Seryozha. Agora Petya encontra duas opções adequadas para ele na cidade de Valinor. Estamos prestes a finalizar o acordo. Suponhamos, para simplificar, que nenhuma das partes da transação utilize hipoteca e não tenha menores como acionistas. Assim, as seguintes ações devem agora ser executadas:
1. Seryozha dá dinheiro a Petya.
2. Vasya dá seu apartamento para Seryozha.
3. Petya dá seu apartamento para Vasya.
4. Maglor ou Maedhros transferem seu apartamento em Valinor para Peta e recebem o dinheiro de Seryozha.
5. Malkor e Maedhros vão para Mordor para servir Melkor.
Seria ideal enviar o seguinte script ao Rosreestr para execução:
INICIAR TRANSAÇÃO
Dê o apartamento de Vasya para Seryozha.
Dê o apartamento de Petya para Vasya.
começar
Dê o apartamento de Malkor para Petya
Dê o dinheiro de Seryozha para Malkor
SE_ERRO:
Dê o apartamento de Maedhros para Petya
Dê o dinheiro de Seryozha para Maedhros
final
COMPROMETE A TRANSACÇÃO
Este é um script de transação simplificado com uma alternativa, que pressupõe que todos os apartamentos tenham um proprietário adulto (e capaz), que seus valores sejam iguais e que os corretores de imóveis (se houver) sejam pagos independentemente das etapas da transação.
No entanto, Rosreestr não oferece suporte à transacionalidade. Todas as ações serão realizadas de forma sequencial e independente, uma após a outra, sem reverter a transação como um todo caso uma delas falhe. O máximo que pode ser alcançado - visto que Rosreestr e o MFC não trabalham com transferência de dinheiro - é depositar o dinheiro em um cofre, com as condições de acesso a ele por Vasya, Petya, Seryozha (se não houver transação está registrado) e outros atores, mediante apresentação de contratos registrados pela Rosreestr. (E por falar nisso, os bancos não verificam de forma independente a autenticidade dos contratos, ou seja, confiam na autenticidade dos papéis das partes na transação).
Além dos riscos de conclusão incompleta da transação, outro problema é que se outros participantes puderem se mudar para sua nova casa sem esperar pelo registro completo (olá, a questão do pagamento insuficiente de contas de serviços públicos!), então Maglor e Maedhros não irão em breve para servir Melkor, e talvez Maglor não consiga, ele simplesmente não terá tempo de segurar as Silmarils em suas mãos. As transações imobiliárias são realizadas de forma sequencial e a execução de cada transação levará no mínimo 9 dias úteis.
Além disso, Rosreestr não apoia o ônus da construção de moradias sob o DDU, mas poderia, esta é uma ação elementar em relação a um simples futuro.
Agora vamos passar para as deficiências e meus desejos sobre o SGBD
1) A primeira é a falta de um sistema de controle de versão. Se no lado Delphi eu desenvolvo em minha própria sandbox e as alterações que faço não aparecerão para outros programadores até que sejam confirmadas, então este não é o caso do SGBD. E mesmo que me seja confiado o acesso total (pelo menos no âmbito do que é necessário para a tarefa que me foi atribuída) à base de dados de combate, e isso aconteça, não posso desenvolvê-la. Enquanto estou depurando, tudo entrará em colapso. Que tipo de Idade da Pedra é essa??? Faça uma sandbox para desenvolvedores.
2) A segunda é a falta de tabelas padronizadas predefinidas que descrevam o mundo real. Cada empresa em que trabalhei tem seu próprio formato de tabela descrevendo os nomes (em russo e (pelo menos) em inglês, em diferentes casos de russo) de doze meses!
3) Terceiro - e aqui usarei a terminologia Oracle - não há como chamar um script simples de Insert ou Update que utilize Returning, da mesma forma que chamamos Select. Talvez estes não sejam problemas do Oracle, mas sim problemas na interface Delphi + Oracle.
4) Quarto – a necessidade de atribuir poderes aos procedimentos e funções que crio onde não quero fazê-lo. Não quero definir e alterar as permissões do usuário para procedimentos e funções. Por que, se eu não escrevi explicitamente Grants, o próprio sistema não poderia olhar para os objetos envolvidos e, de acordo com os direitos de agir com eles, conceder ou não a determinados usuários o direito de chamar uma função? Estou pronto para escrever uma palavra-chave para isso ao escrever funções e procedimentos. Ou, melhor ainda, deixe o usuário iniciar a execução, e se a ramificação do algoritmo o levar a uma solicitação para a qual o usuário não tem direitos, ele a descartará com erro.
Fonte: habr.com