É estúpido para escrever uma grande processamento em lote programa totalmente em PL/SQL?

https://stackoverflow.com/questions/78626

09-06-2019
|

Pergunta

Eu estou começando a trabalhar em um programa que é talvez o mais naturalmente descrito como uma série de cálculos em tabelas de banco de dados, e que será executado uma vez por mês.Todas as entradas em tabelas de banco de dados Oracle, e toda a saída será para tabelas de banco de dados Oracle.O programa deve ficar fácil de manter por muitos anos para vir.

Parece straight-forward para implementar isso como uma série de procedimentos armazenados, cada um executando uma sensível transformação, por exemplo, a distribuição de custos entre os departamentos, de acordo com algumas regras de negócio.Eu, em seguida, pode escrever testes de unidade para verificar se a saída de cada transformação é como eu esperava.

É uma má idéia para fazer isso tudo em PL/SQL?Você gostaria de fazer pesados lote cálculos em uma típica orientada a objeto, linguagem de programação, como C#?Não é mais expressivas para utilizar uma base de dados centralizada linguagem de programação, como PL/SQL?

Solução

Normalmente eu digo colocar tão pouco em PL/SQL possível - é, normalmente, muito menos passível de manutenção - em um dos meus últimos trabalhos que eu realmente vi o quão confuso e difícil de trabalhar com ele poderia obter.

No entanto, uma vez que é o processamento em lote e, uma vez que a entrada e a saída estão o DB - isso faz sentido colocar a lógica em PL/SQL - para minimizar as "partes móveis".No entanto, se fosse lógica de negócios ou componentes utilizados por outras partes do seu sistema - eu diria que não fazê-lo..

Outras dicas

Você descreve os seguintes requisitos

a) Deve ser capaz de implementar o Processamento em Lote b) Resultado deve ser fácil de manter

Minha Resposta:

PL/SQL foi projetado para obter exatamente o que você descreve.Também é importante notar que existem ganhos de eficiência em PL/SQL que não estão disponíveis em outras ferramentas.Um procedimento armazenado idioma coloque o processamento junto aos dados - que é onde o lote de processamento deve sentar-se.
É fácil o suficiente para escrever pouco código passível de manutenção em qualquer idioma.

Tendo dito acima, a sua implementação dependerá, as habilidades disponíveis, um bom design e a adesão a boas processos de qualidade.

Para ser eficiente, a sua implementação deve processar dados em lotes ( selecione na lotes e inserção/atualização em lotes ).O perigo com um OO abordagem é que ela é fácil de ser conduzida no sentido de uma concepção de que os processos de dados linha por linha.Este tipo de abordagem contém uma sobrecarga desnecessária, e vai ser muito menos eficiente do que um design que processa os dados em lotes de linhas.

É possível utilizar as duas abordagens com êxito.

Mateus Butler

Algo para outros comentadores de observação - a pergunta é sobre PL/SQL, não sobre SQL.Algumas das respostas têm sido, obviamente, sobre SQL, não de PL/SQL.PL/SQL é um sistema totalmente funcional do banco de dados de linguagem, e é madura bem.Há algumas limitações, mas para o tipo de coisa que o cartaz quer fazer, é muito bom.

Não, ele não é necessariamente uma má ideia.Se a solução parece simples para você e permite que você teste e verificar cada processo, o seu parece ser uma boa idéia.OO plataformas pode ser (embora eles não têm de ser ruim para grandes conjuntos de dados, como a criação do objeto e a sobrecarga pode matar o desempenho.

Oracle projetado PL/SQL com problemas como o seu em mente, se há suficiente conhecimento corporativo do banco de dados e PL/SQL esta parece ser uma solução razoável.Manter grandes lotes define em mente, que cada chamada de PL/SQL para o SQL real do motor é um parâmetro de contexto, de modo único registro de processos deve estar em lotes juntos sempre que possível para melhorar o desempenho.

Apenas certifique-se de que você, de alguma forma, registrar o que está acontecendo enquanto ele está trabalhando.Caso contrário, você vai ter uma caixa preta e se ficar preso em algum lugar por horas, você vai estar se perguntando se a pará-lo ou deixá-lo trabalhar 'um pouco mais'.

PL/SQL é a maturidade de uma linguagem que se integra bem com o SQL.Com cada versão do Oracle torna-se mais e mais poderosa.Também a partir do Oracle 11, PL/SQL compila para código de máquina por padrão.

Eu escrevi uma enorme quantidade de processamento em lote e a geração de relatórios de programas tanto em PL/SQL e ProC para um projeto.Eles geralmente preferido eu escrevo em PL/SQL, como a seus próprios desenvolvedores que iria manter no futuro descobriu que mais fácil de entender do que ProC código.

Acabou sendo apenas o que é realmente muito funky processamento ou relatórios que acabou de ser escrito em Pro*C.

Ele não é necessário para escrever esses procedimentos armazenados como outras pessoas já aludido, eles podem ser apenas arquivos de script que são executados como necessário, como uma espécie de script shell.Tornar fonte de código de controle de revisão e de migração entre o teste e sistemas de produção de um heck de muito mais fácil, também.

Enquanto os cálculos que você precisa para executar pode ser adequadamente E legívelmente capturado em PL/SQL, em seguida, usando apenas PL/SQL faria mais sentido.

O verdadeiro problema é a manutenção -- é muito fácil escrever unmaintainable SQL, se apenas porque cada SGBDR tem uma sintaxe diferente, e diferente conjunto de função uma vez que você pisa fora do simples SQL DML, e não reais normas para a formatação.comentando, etc.

Eu criei programas em lote usando C# e SQL.

Prós do C#:

Você tem toda a biblioteca de .NET e todo o poder de uma linguagem OO.

Contras do C#:

*Programa de lote e db separados - isto significa que você vai ter que gerir o seu programa em lote separado do banco de dados.

*Você precisa para escapar de tudo o que dang código sql.

Prós do SQL:

*Integra-se bem com o SGBD.Se este trabalho só manipula o banco de dados, não faria sentido incluí-lo com o banco de dados.Você acaba com um único banco de dados e todos os seus componentes em um único pacote.

*Não há necessidade de escapar código sql

*mantê-lo real - você está programando em seu domínio do problema

Contras do SQL:

Seu SQL e eu, pessoalmente, só não sei bem como SQL.

Em geral, eu iria ficar com o uso de SQL por causa das Vantagens descritas acima.

Esta é uma pergunta capciosa :) Há um par de programação de banco de dados arquitetura de design que você deve conhecer, e que os seus custos/benefícios.2 Nível em geral significa que você tem um cliente que está se conectando a um banco de dados, emissão direta de chamadas SQL.3 Nível em geral significa que você tem um "servidor de aplicação" que é a emissão direta de chamadas SQL para o banco de dados, mas o cliente está falando para o aplicativo de servidor.Geralmente, este proporciona "escala".Finalmente, você tem 2 1/2 camadas de aplicações que empregam um 2 Camadas, como formato, somente o trabalho é compartimentado em procedimentos armazenados.

O processo soa como um "back office" tipo de coisa, e os clientes/processos só precisa de resultados que estão sendo agregadas e armazenados em cache em um uma vez por mês.Isto é, não há nenhum agente que se conecta e liga-se muitas vezes, e diz: "fazer estes cálculos".Em vez disso, você alude a um processo que acontece de vez em quando, e você pode começar afastado com o tempo não real.

Portanto, dada a esses requisitos, eu diria que, geralmente, ele será mais rápido para estar mais perto de dados, e permitir que o SQL server fazer todos os cálculos.Eu acho que você vai achar que a proximidade aos dados irá atendê-lo bem.

No entanto, para a realização destes cálculos, você pode descobrir que alguns cálculos não são passíveis de Servidores SQL.Tomemos, por exemplo, calcular os juros acumulados de um título, ou de qualquer de renda fixa de instrumento.Não muito bonita no SQL, e muito mais adequada para uma rica linguagem de programação.No entanto, se você só tiver médias simples e outro relativamente sã agregados, eu vara para procedimentos armazenados no SQL lado.

Então, novamente, não há informações suficientes quanto à natureza de seus cálculos, ou o que a sua casa mandatos em termos de SQL capacidades dos devs para suporte, ou o que seu chefe diz...mas desde que eu sei o meu caminho de SQL, e gosta de ficar perto de dados, que eu ia ficar de SQL puro/Procedimentos Armazenados para uma tarefa como essa.

YMMV :)

Não é, normalmente, mais expressivo, porque a maioria procedimento armazenado línguas chupar por design.Mas ele provavelmente irá correr mais rápido do que em um aplicativo externo.

Eu acho que tudo se resume a forma como você está familiarizado com PL/SQL, quanto tempo você tem para escrever isso, o quão importante é o desempenho e se você pode esperar de mantenedores de estar familiarizado o suficiente com PL/SQL para manter um grande programa escrito nele.

Se a velocidade não é relevante e mantenedores serão provavelmente não PL/SQL proficiente, você pode ser melhor utilizar uma linguagem "tradicional".

Você também pode usar uma abordagem híbrida, onde você usa PL/SQL para gerar dados intermediários (por exemplo, a tabela de associações e somas ou o que quer) e um aplicativo separado para fluxo de controle e de verificação de valores e erros.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow