Reutilização de SQL procedimentos armazenados em aplicativos

Question

Estou curioso sobre abordagens das pessoas para utilizar procedimentos armazenados em um banco de dados que é acessado por muitas aplicações. Especificamente, você tende a manter diferentes conjuntos de procedimentos armazenados para cada aplicação, você tentar usar um conjunto compartilhado, ou você faz uma mistura?

Por um lado, a reutilização de SPs permite menos alterações quando há uma mudança de modelo ou algo similar e, idealmente, menos manutenção. Por outro lado, se as necessidades das aplicações divergem, alterações de um procedimento armazenado para uma aplicação pode quebrar outras aplicações. Devo observar que em nosso meio, cada aplicativo tem sua própria equipe de desenvolvimento, com pouca comunicação entre eles. A equipe de dados tem uma melhor comunicação, porém, e é principalmente encarregado com o processo de escrita armazenado.

Obrigado!

Answer 1

Tudo depende de sua estratégia de abstração. São os procedimentos armazenados tratados como um ponto discreto de abstração, ou são tratados como apenas uma outra parte do aplicativo que chama-los.

A resposta para isso irá dizer-lhe como gerenciá-los. Se eles são uma abstração discreta, eles podem ser compartilhados, como se você precisa de uma nova funcionalidade, você vai adicionar novos procedimentos. Se eles fazem parte do aplicativo que chama-los, eles não devem ser compartilhadas.

Answer 2

Os procedimentos armazenados devem ser criados com base nos dados que você pretende retorno, não a aplicação fazendo a solicitação. Se você tiver um procedimento armazenado que é getTodosOsItens, ele deve retornar todos os itens no banco de dados. Se uma das aplicações gostaria de obter todos os itens por categoria, criar GetAllItemsByCategory. Não há nenhuma razão para as regras de negócio de um procedimento armazenado para a mudança com base na aplicação solicitando os dados.

Answer 3

Minha experiência tem sido que ter SPs compartilhados por vários aplicativos é uma causa de dor. Na verdade, eu diria que ter um banco de dados que é acessado diretamente por mais de um aplicativo não é a melhor arquitetura de longo prazo.

O padrão que eu recomendo e implementaram é que somente um aplicativo deve "próprio" cada banco de dados, e fornecer APIs (serviços, etc.) para outros aplicativos para acessar e modificar dados.

Isto tem várias vantagens:

1. O aplicativo proprietário pode aplicar qualquer lógica de negócios, registro, etc, para se certificar de que permanece estável
2. Se o esquema for alterado, todas as interfaces são conhecidos e podem ser testados para garantir que as aplicações externas continuará a funcionar

Answer 4

Os procedimentos armazenados devem expor as regras de negócios que não mudam, dependendo da aplicação de usá-los. Isso permite que as regras sejam armazenadas e atualizadas uma vez, em vez de todos os lugares que eles são usados, o que é um pesadelo.

Answer 5

Pense nisso desta maneira: os procedimentos armazenados são sobre os dados que estão sob eles, e não deve realmente saber sobre as aplicações acima deles. É possível que um aplicativo precisa ler ou atualização de dados de uma forma que outro não faz, e assim pode-se usar SPs que o outro não iria.

Se fosse minha aplicação / banco de dados / etc, e muda para uma SP para melhorar uma aplicação quebrou outro, eu consideraria que a evidência de um problema de design mais profundo.

Answer 6

A última parte da sua pergunta eu acredito em si respondeu.

Com já pobre comunicação, partilha de procedimentos entre as equipes de desenvolvimento seria apenas adicionar aos possíveis pontos de falha e pode causar tanto sofrimento equipe.

Se eu estou na mesma equipe trabalhando em vários projetos que irá poupar alguns procedimentos de tempo e ação, mas normalmente eu descobri que um pouco de duplicação (Alguns procedimentos aqui e ali) ajuda a evitar a alterações catastróficas / duplicação necessário mais tarde quando as aplicações começam a divergir.

LordScarlet também aponta um elemento-chave, bem como, se for genérico com o compartilhamento de nenhuma lógica de negócios não deve ser um problema.

Answer 7

Sempre que tinha armazenado procedimentos que eram comuns a várias aplicações, gostaríamos de criar um banco de dados apenas para esses procedimentos (e pontos de vista e mesas, etc). Esse banco de dados (que chamado "base") teria, então, um desenvolvedor (ou equipe) responsável por ela (manutenção e testes).

Se uma equipe diferente necessária nova funcionalidade, que poderia escrevê-lo eo desenvolvedor de base seria ou implementá-lo na base DB ou sugerir uma maneira mais simples.

Answer 8

Tentamos usar um único, proc armazenados compartilhada, sempre que possível, mas tenho que correr para a situação que você descreve tão bem. Nós lidamos com isso, adicionando um prefixo de aplicação aos procedimentos armazenados (ApplicationName_StoredProcName).

Muitas vezes, estes procedimentos armazenados chamar o centralizada ou "mestre" proc armazenados, mas esta sala folhas método para específica aplicativo muda abaixo da estrada.

Answer 9

Eu não acho que partilha Sprocs entre múltiplas aplicações faz sentido.

Eu posso ver o caso para a partilha de um banco de dados em aplicações relacionadas, mas, presumivelmente, essas aplicações são separados em grande parte porque eles tratam os dados de forma muito diferente um do outro.

Usando a mesma arquitetura poderia trabalhar em aplicativos, mas imaginar a tentar usar a mesma camada de lógica de negócios em múltiplas aplicações. "Mas espere!" você diz: "Isso é bobagem ... se eu estou usando o mesmo BLL, por que eu tenho um aplicativo separado? Eles fazem a mesma coisa!"

QED.

Answer 10

O ideal é usar um proc não várias versões. Se você precisar de versões por cliente, investigar a idéia de 1 db por cliente em oposição a 1 db para todos os clientes. Isso também permite alguma encenação interessante de db de em servidores diferentes (alocar os mais pesados ??maiores / uso para servidores maiores, enquanto os mais pequenos podem compartilhar hardware)

Answer 11

Se você olhar para a capacidade de compartilhar a tentativa de código SQL a construção de uma biblioteca de funções abstratas. Desta forma, você pode reutilizar algum código que faz as coisas genéricas e manter a lógica de negócios separada para cada aplicação. O mesmo poderia ser feito com os pontos de vista -. Eles poderiam ser mantidos bastante genérico e útil para muitas aplicações

Você provavelmente vai descobrir que não há que muitos usos para comum procedimentos armazenados como você vá junto.

Dito que, uma vez implementado um projeto que estava trabalhando com um banco de dados legado muito mal projetado. Nós implementamos um conjunto de procedimentos armazenados que fez a recuperação de informação fácil. Quando outras pessoas de outras equipes queriam usar a mesma informação que refactored nossos procedimentos armazenados para torná-los mais genérico, acrescentou uma camada extra de comentários e documentação e permitiu que outras pessoas usem nossos procedimentos. Essa solução funcionou muito bem.

Answer 12

Muitos procedimentos armazenados são independentes aplicação, mas pode haver alguns que são dependentes da aplicação. Por exemplo, o CRUD (criar, Select, Update, Delete) procedimentos armazenados pode ir entre aplicativos. Em particular, você pode jogar em lógica de auditoria (por vezes feito em gatilhos, mas há um limite para o quão complicado pode entrar em gatilhos). Se você tem algum tipo de arquitetura padrão em seu software de compras a camada intermediária pode exigir um procedimento armazenado para criar / select / update / delete do banco de dados, independentemente da aplicação, caso em que o procedimento é compartilhado.

Ao mesmo tempo, pode haver algumas maneiras úteis de visualizar os dados, ou seja, GetProductsSoldBySalesPerson, etc .. que também será independente da aplicação. Você pode ter um monte de tabelas de pesquisa para alguns campos, como departamento, endereço, etc. portanto, pode haver um procedimento para retornar uma exibição da tabela com todos os campos do texto. Ou seja, em vez de SalesPersonID, SaleDate, Cliente, DepartmentID, CustomerAddressID o procedimento retorna uma vista SalesPersonName, SaleDate, CustomerName, DepartmentName, CustomerAddress. Isso também poderia ser utilizado em todas as aplicações. Um sistema de relacionamento com o cliente iria querer nome do cliente / Endereço / Outros atributos como faria com um sistema de faturamento. Então, alguma coisa que fez toda a junta e tem todas as informações do cliente em uma consulta provavelmente ser utilizado em todas as aplicações. É certo criando maneiras de exibir os dados são o domínio de um ponto de vista, mas muitas vezes as pessoas usavam procedimentos armazenados para fazer isso.

Então, basicamente, ao excluir da sua mesa você precisa apagar a partir de 3 ou 4 outras mesas para garantir a integridade dos dados. é a lógica muito complicado para um gatilho? Em seguida, um procedimento armazenado que todos os aplicativos usam para fazer exclusões podem ser importantes. O mesmo vale para as coisas que precisam ser feitas na criação. Se houver comum junta-se que são sempre fez, pode fazer sentido ter um procedimento armazenado para fazer toda a junta. Então, se mais tarde você alterar as tabelas em torno de você poderia manter o processo o mesmo e apenas mudar a lógica lá.

Answer 13

O conceito de partilha de um esquema de dados através de múltiplas aplicações é uma pergunta difícil. Invariavelmente, o esquema fica comprometido por motivos de desempenho: desnormalização, que índices para criar. Se você pode cortar o tamanho de uma linha no meio, você pode dobrar o número de linhas por página e, provavelmente, reduzir pela metade o tempo que leva para fazer a varredura da tabela. No entanto, se você incluir apenas 'comum' apresenta na mesa principal e manter apenas os dados de interesse para aplicações específicas em diferentes (mas relacionadas) tabelas, você tem que juntar todos os lugares para voltar para a idéia 'single table'.

Mais índices para suportar diferentes aplicações causarão tempo cada vez maior de inserção, atualização e os dados de exclusão de cada tabela.

O servidor de banco de dados, muitas vezes, se tornar um gargalo, bem como, porque bancos de dados não pode ser com balanceamento de carga. Você pode particionar seus dados através de múltiplos servidores, mas que fica muito complicado também.

Finalmente, o grau de coordenação necessário é geralmente enorme, sem dúvida com lutas entre diferentes departamentos sobre cujos requisitos têm prioridade, e novos desenvolvimentos vão se atolar.

Em geral, os 'dados isolados silo por aplicativo' modelo funciona melhor. Quase tudo o que fazemos - trabalho que para uma casa de software contrato -. Baseia-se importar dados de e exportação de dados para outros sistemas, com os próprios bancos de dados de nossos aplicativos

Pode muito bem ser mais fácil em sistemas de suporte de data warehouse / decisões; Eu geralmente trabalho em sistemas OLTP onde o desempenho de transações é fundamental.