Meus desejos para o SGBD do futuro, bem como para Rosreestr em termos de transacional



O cliente interage com o banco de dados.

Do site http://corchaosis.ru , autor da imagem Jonathan Tiong.



Além de ser um programador (principalmente Delphi + todos os tipos de DBMS diferentes, recentemente ORAKL, + um pouco de PHP), tenho um hobby - comprar e vender apartamentos. Compro um apartamento em fase de construção de um incorporador mais ou menos confiável a um preço gostoso (por exemplo, agora esse incorporador é Avião, apartamentos perto do metrô Nekrasovka estão sendo vendidos), espero a entrega da casa (muitas vezes dois anos depois, com ofertas baratas isso acontece), eu faço em renovado e depois vendido por 95-100% do seu 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 mercado imobiliário é "Lidar com uma alternativa" (e também, como parte dela, "Acordo sobre um cofre"), e tudo é um pouco mais complicado aí. Estou te dizendo.



Vasya veio ver o apartamento que Petya está vendendo. E Vasya realmente gostou de tudo, incluindo o preço, mas Vasya não tem dinheiro. É assim que nossa história começa.



Vasya tem sua própria propriedade, que tem alguns valores que não são particularmente necessários para ele - Lomonosov morava na casa ao lado, a altura do teto é de sete metros e meio, há uma base de fruticultura e o mercado do jardineiro nas proximidades, você pode ir a pé ao Aeroexpress, há um porão com altura de 1 metros, 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 apartamento. Mas vendê-lo para comprar o apartamento de Petit, e não só. Na linguagem dos corretores de imóveis, isso é chamado - "A alternativa está selecionada."



Agora vamos olhar para esta situação da perspectiva de Petya. O fato é que Petya também não está interessado em sentar-se na depreciação do dinheiro, ele vende um apartamento para comprar um apartamento na cidade élfica de Valinor, mas ele ainda não olhou para qual. Na linguagem dos corretores de imóveis, isso é chamado de “Lidar com uma alternativa”.



Dois elfos da Terra-média, Maglor e Maedhros, têm imóveis adequados (de acordo com os critérios de Petit) na cidade de Valinor, que são vendidos com urgência, pois são enviados para servir Melkor. Na linguagem dos corretores de imóveis, isso é chamado de "Venda Gratuita".



Então, Vasya encontra um cliente Seryozha. Agora, Petya encontra duas opções adequadas para ele na cidade de Valinor. Vamos para o registro da transação. Para simplificar, digamos que nenhum dos participantes da transação use hipoteca e não tenha um acionista minoritário. Portanto, as seguintes ações devem ocorrer:

1. Seryozha dá o dinheiro a Pete.

2. Vasya entrega seu apartamento para Seryozha.

3. Petya entrega seu apartamento para Vasya.

4. Maglor ou Maedhros entregam seu apartamento em Valinor para Pete e recebem o dinheiro de Seryozha.

5. Malkor e Maedhros vão para Mordor para servir Melkor.



Seria ideal enviar o seguinte script para Rosreestr para execução:

COMECE A TRANSAÇÃO

Dê o apartamento de Vasya para Seryozha.

Dê o apartamento de Petya para Vasya.

begin

Dê o apartamento de Malkor para Petya Dê

o dinheiro de Seryozha para Malkor IF_

ERRO: Dê

o apartamento de Maedhros para Petya

Dê o dinheiro de Seryozha para Maedhros

fim

COMPROMETE TRANSAÇÃO



Este é um script de transação simplificado com uma alternativa, assumindo que todos os apartamentos têm um proprietário adulto (e capaz), que seus preços são iguais e que o pagamento dos corretores de imóveis (se houver) é pago fora dos estágios 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 toda a transação se uma delas não tiver sido concluída. O máximo que pode ser alcançado - dado que Rosreestr e o MFC não trabalham com transferência de dinheiro - é colocar o dinheiro em um cofre, com as condições de acesso para Vasya, Petit, Seryozha (se nenhuma transação for registrada), e outros atores, mediante apresentação por eles de contratos registrados pela Rosreestr. (E, aliás, os bancos não verificam de forma independente a autenticidade dos contratos, ou seja, confiam na autenticidade dos títulos dos participantes da transação).



Além dos riscos de execução incompleta da transação, outro problema é que se outros participantes puderem se mudar para suas novas moradias sem esperar pelo registro completo (olá, a questão do pagamento insuficiente de contas de serviços públicos!), Maglor e Maedhros não irão atender Melkor em breve, e talvez Maglor não seja capaz segurar as Silmarils em suas mãos, ele simplesmente não terá tempo. As transações imobiliárias são realizadas sequencialmente e cada transação levará pelo menos 9 dias úteis para ser concluída.



Além disso, Rosreestr não suporta o ônus de moradias em construção sob o DDU, mas poderia, esta é uma ação elementar em relação a um simples futuro.



Agora vamos passar para as desvantagens e meus desejos sobre o SGBD



1) O primeiro é a falta de um sistema de controle de versão. Se do lado do Delphi eu conduzo o desenvolvimento na minha sandbox, e as mudanças que eu fiz não aparecem nos outros programadores até o momento de seu commit, então este não é o caso com o DBMS. E mesmo que confiem em mim com total (pelo menos no quadro do necessário para a tarefa que me foi atribuída) acesso à base de dados de combate, e isso acontece, não consigo desenvolver. Enquanto estou depurando, tudo irá travar. O que é esta Idade da Pedra ??? Sandbox os desenvolvedores.



2) O segundo é a ausência de tabelas padronizadas predefinidas que descrevam o mundo real. Cada empresa onde trabalhei tem seu próprio formato de tabela descrevendo os nomes (em russo e (pelo menos) inglês, em diferentes casos em russo) por doze meses!



3) Terceiro - e aqui vou usar a terminologia de Orakl - não há como chamar um simples script de Insert ou Update usando Returning, como chamamos Select. Talvez esses não sejam os problemas de Orakl, mas problemas de junção Delphi + Oracle.



4) Quarto - a necessidade de atribuir autoridade aos procedimentos e funções que crio onde não quero fazer isso. Não quero definir e, em seguida, alterar a autoridade do usuário do procedimento e função. Por que, se eu não escrevesse explicitamente Grants, o sistema não poderia ele próprio 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 a 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 o desvio do algoritmo o levar a uma solicitação para a qual o usuário não tem direitos, ele a descartará com um erro.



All Articles