O cliente interage com o banco de dados.
Do site , autor da pintura Jonathan Tiong.
Além de ser programador (principalmente, Delphi + vários SGBDs, mais recentemente ORACLE, + um pouco de PHP), tenho um hobby — compra e venda de apartamentos. Compro um apartamento na fase de construção de um construtor mais ou menos confiável a um preço atrativo (por exemplo, atualmente, esse construtor é a Samolet, apartamentos perto da estação de metrô Nekrasovka estão à venda), espero a entrega do prédio (frequentemente dois anos depois, isso acontece com ofertas mais baratas), reformo o apartamento e então vendo por 95-100% do seu preço de mercado.
Assim, eu (como todos) enfrentei o problema da falta de transacionabilidade no Rosreestr.
O problema da falta de transacionabilidade de negócios no Rosreestr
Na programação, "Transação", e no setor imobiliário, isso é "Negócio com alternativa" (e, como parte disso, “Contrato de caixa bancária”), e tudo é um pouco mais complicado. Vou explicar.
Vasya veio ver um apartamento que Petya está vendendo. E Vasya gostou muito, inclusive do preço, mas ele não tem dinheiro. Assim começa nossa história.
Vasya possui seu imóvel, que tem algumas características não muito necessárias para ele — na casa vizinha viveu Lomonossov, a altura do teto é de sete metros e meio, há uma base de frutas e vegetais e o mercado Sadovod nas proximidades, é possível ir a pé até o Aeroexpress, abaixo do apartamento há um porão com um metro de altura, e acima do apartamento há um sótão adequado para observações astronômicas. Vasya entende que essas características aumentam o valor do seu apartamento, mas não para ele mesmo. E ele decide comprar o apartamento de Petya e vender o seu. Mas vender exatamente para poder comprar o apartamento de Petya, e não apenas assim. Na linguagem dos corretores, isso é chamado de "Alternativa selecionada".
Agora vamos olhar essa situação do ponto de vista de Petya. O fato é que Petya também não está interessado em ficar com dinheiro desvalorizado, ele vende o apartamento para poder comprar um apartamento na cidade élfica de Valinor, mas qual exatamente — ainda não olhou. Na linguagem dos corretores, isso é chamado de "Negócio com alternativa".
Dois elfos da Terra-média, Maglor e Maedhros, possuem imóveis adequados (aos critérios de Petya) na cidade de Valinor, que estão sendo vendidos urgentemente, pois partirão para servir a Melkor. Em termos de corretores, isso é chamado de 'venda livre'.
Assim, Vasya encontra o cliente Seryozha. Agora, Petya encontra duas opções que se adequam a ele na cidade de Valinor. Vamos prosseguir com a formalização do negócio. Suponhamos, para simplificar, que nenhum dos participantes da transação utiliza hipoteca e que não possui coproprietários menores de idade. Assim, agora devem ocorrer as seguintes ações:
1. Seryozha entrega o dinheiro a Petya.
2. Vasya entrega seu apartamento a Seryozha.
3. Petya entrega seu apartamento a Vasya.
4. Ou Maglor ou Maedhros entregam seu apartamento em Valinor a Petya e recebem o dinheiro de Seryozha.
5. Malcor e Maedhros vão para Mordor servir a Melkor.
Seria ideal enviar ao Registro de Imóveis o seguinte script para execução:
START TRANSACTION
Entregar o apartamento de Vasya a Seryozha.
Entregar o apartamento de Petya a Vasya.
begin
Entregar o apartamento de Malcor a Petya.
Entregar o dinheiro de Seryozha a Malcor.
SE_ERRO:
Entregar o apartamento de Maedhros a Petya.
Entregar o dinheiro de Seryozha a Maedhros.
end
COMMIT TRANSACTION
Este é um script simplificado da transação com alternativas, assumindo que todos os apartamentos têm um único proprietário adulto (e capaz), que seus valores são iguais, e que a remuneração dos corretores (se houver) é paga independentemente das etapas da transação.
No entanto, o Registro de Imóveis não suporta transações. Todas as ações serão executadas sequencialmente e de forma independente, uma após a outra, sem o rollback da transação como um todo, caso uma delas não seja realizada. O máximo que pode ser alcançado — considerando que o Registro de Imóveis e os centros de atendimento ao cidadão não trabalham com a transferência de dinheiro em espécie — é colocar dinheiro em uma caixa bancária, com as condições de acesso para Vasya, Petya, Seryozha (caso nenhum negócio esteja registrado), e outras partes envolvidas, no momento em que apresentarem os contratos registrados pelo Registro de Imóveis. (E, a propósito, os bancos não realizam a autenticação dos contratos, ou seja, confiam na autenticidade dos documentos apresentados pelos participantes da transação).
Além dos riscos de transações incompletas, outro problema é que, se outros participantes podem se mudar para a sua nova casa sem esperar a finalização completa (olá, a questão do pagamento em atraso dos serviços públicos!), então Maglor e Maedhros não irão servir a Melkor tão cedo, e talvez Maglor não consiga segurar os Silmarils em suas mãos, simplesmente não haverá tempo. Os negócios imobiliários são realizados sequencialmente, e a formalização de cada transação levará no mínimo 9 dias úteis.
Além disso, o Rosreestre não suporta a oneração de imóveis em construção sob um contrato de adesão, mas poderia, pois é uma ação elementar em relação a um simples futuro.
Agora vamos passar para as desvantagens e as minhas preocupações sobre o SGBD
1) Primeiro — é a ausência de um sistema de controle de versões. Se, do lado do Delphi, eu desenvolvimento em meu ambiente isolado, e as mudanças feitas por mim não aparecem para os outros programadores até que sejam commitadas, com o SGBD isso não acontece. E mesmo que eu tenha total confiança (pelo menos, no que é necessário para a tarefa que me foi dada) acesso ao banco de dados de produção, o que acontece às vezes, não posso desenvolver neles. Enquanto eu estiver depurando, tudo desmorona. Que era da pedra é essa??? Criem um ambiente isolado para os desenvolvedores.
2) Segundo — é a falta de tabelas padronizadas pré-instaladas que descrevem o mundo real. Em cada empresa onde trabalhei, havia seu próprio formato de tabela, descrevendo os nomes (em russo e (pelo menos) em inglês, em diferentes casos do russo) dos doze meses!
3) Terceiro — e aqui vou usar a terminologia da Oracle — falta a capacidade de chamar um simples script Insert ou Update com Returning, da mesma forma que chamamos um Select. Isso pode não ser um problema da Oracle, mas sim um problema da integração Delphi + Oracle.
4) A quarta questão é a necessidade de atribuir poderes às rotinas e funções que crio, onde não quero fazer isso. Eu não quero definir e depois mudar os direitos dos usuários nas rotinas e funções. Por que, se não escrevi explicitamente os Grants, o sistema não poderia verificar os objetos envolvidos e, de acordo com os direitos de ação sobre eles, conceder ou não a certos usuários o direito de chamar a função? Estou disposto a escrever uma única palavra-chave para isso ao criar funções e rotinas. Ou, melhor ainda, que o usuário inicie a execução e, se o ramo do algoritmo o levar a uma solicitação para a qual ele não tem direitos, que seja gerada uma mensagem de erro.
Fonte: habr.com
