Procedimentos armazenados ou consultas em linha?

StackOverflow https://stackoverflow.com/questions/252230

  •  05-07-2019
  •  | 
  •  

Pergunta

Antes de tudo há um pergunta parcial sobre isso, mas não é exatamente o que eu estou pedindo, por isso, tenha comigo e ir para ele.

A minha pergunta é, depois de olhar para o que SubSonic faz e os excelentes vídeos de Rob Connery eu preciso perguntar: usaremos uma ferramenta como esta e fazer consultas em linha ou vamos fazer as consultas usando uma chamada para o procedimento de armazenados?

Eu não quero minimizar qualquer trabalho de Rob (que eu acho que é incrível), mas eu só quero a sua opinião sobre esta causa que eu preciso para iniciar um novo projeto e eu estou no meio da linha; devo usar SubSonic (ou outro como ferramenta, como NHibernate) ou eu continuar o meu método que é sempre chamar um procedimento armazenado mesmo que seja um simples como 

Select this, that from myTable where myStuff = StackOverflow;
Foi útil?

Solução

Ele não precisa ser um ou o outro. Se é uma consulta simples, use a ferramenta de consulta subsônico. Se é mais complexa, use um procedimento armazenado e carregar uma coleção ou criar um conjunto de dados a partir dos resultados.

Veja aqui: Quais são os prós e contras de manter o SQL na Stored Procs contra Código e aqui SubSonic e Stored Procedures

Outras dicas

Veja as respostas aqui e aqui . Eu uso sprocs sempre que posso, exceto quando os meios burocracia leva uma semana para fazê-lo no banco de dados.

Os procedimentos armazenados são de ouro quando você tem várias aplicações que dependem do mesmo banco de dados. Ele permite que você definir e manter consulta lógica uma vez, em vez de vários lugares.

Por outro lado, é muito fácil para os próprios procedimentos armazenados para se tornar uma grande bagunça confusa no banco de dados, já que a maioria dos sistemas não têm um bom método para organizá-los de forma lógica. E eles podem ser mais difíceis de versão e registar alterações.

Eu pessoalmente não seguir regras rígidas. Certamente, durante as fases de desenvolvimento, você quer ser capaz de mudar rapidamente suas consultas por isso gostaria de in-line los.

Mais tarde, eu iria passar para procedimentos armazenados, porque eles oferecem as duas vantagens seguintes. Estou certo de que há mais, mas estes dois me conquistar.

1 / armazenado grupo procedimentos os dados e o código para manipular / extracção que os dados em um ponto. Isso faz com que a vida de seu DBA muito mais fácil (assumindo que a sua aplicação é suficiente considerável para justificar um DBA) uma vez que podem otimizar com base em fatores conhecidos.

Uma das grandes bugbears de um DBA é-consultas ad hoc (especialmente por palhaços que não sabem o que é uma varredura completa da tabela é). DBAs preferem ter consultas consistentes bom que eles podem sintonizar o banco de dados.

2 / procedimentos armazenados podem conter lógica que é melhor deixar no banco de dados. Eu vi procedimentos armazenados em DB2 / z, com muitas dezenas de linhas, mas todos o cliente tem que código é uma única linha como "dê-me essa lista".

Porque a lógica de "que lista" é armazenado no banco de dados, os DBAs podem modificar a forma como ele é armazenado e extraído à vontade sem comprometer ou alterar o código do cliente. Isto é semelhante ao encapsulamento que fizeram linguagem objeto-orientado a 'mais limpa' do que o que veio antes.

Eu fiz uma mistura de consultas em linha e procedimentos armazenados. Eu prefiro mais a abordagem procedimento / fotografia armazenada como ele ganha um local agradável para você fazer uma mudança se necessário. Quando você tem consultas em linha você sempre tem que ir e mudar o código para alterar uma consulta em linha e, em seguida, re-roll da aplicação. Você também pode ter a consulta em linha em vários lugares para que você teria que mudar um código muito mais do que com um procedimento armazenado.

Então, novamente, se você tem que adicionar um parâmetro para um procedimento armazenado, o seu ainda mudar um monte de código de qualquer maneira.

Outra nota é a forma como muitas vezes as alterações de dados por trás do procedimento armazenado, onde eu trabalho, temos mesas de terceiros que podem quebrar-se em tabelas normalizadas, ou uma tabela torna-se obsoleto. Nesse caso, um procedimento / fotografia armazenada pode minimizar a exposição que você tem a essa mudança.

Eu também tenho escrito um aplicativo inteiro sem procedimentos armazenados. Ele tinha três classes e 10 páginas, não valia a pena em tudo. Acho que chega um ponto quando o seu exagero, ou pode ser justificada, mas também se resume a sua opinião pessoal e preferência.

Você vai sempre apenas acessar seu banco de dados que um aplicativo?

Se não, então você é provavelmente melhor fora de usar procedimentos armazenados de modo que você pode ter uma interface consistente para o seu banco de dados.

Existe algum custo significativo para distribuir seu aplicativo se você precisar fazer uma mudança?

Se sim, então você é provavelmente melhor fora de usar procedimentos armazenados que podem ser alteradas no servidor e essas alterações não deverão ser distribuídos.

Você está em todos preocupados com a segurança de seu banco de dados?

Se sim, então você provavelmente vai querer usar procedimentos armazenados para que você não tem que conceder acesso direto a tabelas para um usuário.

Se você estiver escrevendo um pequeno aplicativo, sem um grande público, para um sistema que não será usado ou acessado fora do seu aplicativo, em seguida, SQL embutido pode ser ok.

Com Subsonic você vai usar em linha, visualizações e procedimentos armazenados. dados subsônicas torna o acesso mais fácil, mas você não pode fazer Everthing em uma consulta subsônico. Embora a versão mais recente, 2.1 está ficando melhor.

Para operações básicas CRUD, SQL embutido vai ser para a frente. Para as necessidades de dados mais complexos, uma visão terá de ser feita e, em seguida, você vai fazer uma consulta Subsonic na vista.

procedimentos armazenados são boas para cálculos de dados mais duras e recuperação de dados. Definir a recuperação com base é geralmente sempre mais rápido, então o processamento processual.

aplicação Subsonic atual utiliza todas as três opções com grandes resultados.

Eu prefiro sql em linha a menos que o procedimento armazenado tem uma lógica real (variáveis, cursores, etc) envolvidos. Tenho vindo a utilizar LINQ to SQL ultimamente, e tomar as classes geradas e adicionando classes parciais que têm alguns pré-definidos, consultas LINQ comuns. Eu sinto isso contribui para um desenvolvimento mais rápido.

Edit: Eu sei que eu vou ser downmodded para isso. Se você nunca falar para baixo em chaves estrangeiras ou procedimentos armazenados, você vai ficar downmodded. DBAs segurança necessidade de trabalho eu acho ...

As vantagens do procedimento armazenado (a minha mente)

  1. O SQL está em um lugar
  2. Você é capaz de obter planos de consulta.
  3. Você pode modificar a estrutura de banco de dados, se necessário para melhorar o desempenho
  4. Eles são compilados e, portanto, esses planos de consulta não tem que se construiu na mosca
  5. Se você usar permissões -. Você pode ter certeza das consultas que o aplicativo fará

  1. armazenado grupo procedimentos os dados e o código para manipular / extracção que os dados em um ponto. Isso faz com que a vida de seu DBA muito mais fácil (assumindo que a sua aplicação é suficiente considerável para justificar um DBA) uma vez que podem otimizar com base em fatores conhecidos.

  2. Os procedimentos armazenados podem conter lógica que é melhor deixar no banco de dados. Eu vi procedimentos armazenados em DB2 / z, com muitas dezenas de linhas, mas todos o cliente tem que código é uma única linha como "me dar essa lista".

  3. a melhor vantagem de usar procedimentos armazenados que encontrei é que quando queremos mudar na lógica, em caso de consulta em linha é preciso ir a todo lugar e alterá-lo and roll re- a cada aplicação, mas no caso de mudança proc armazenado só é necessário em um lugar.

Assim consultas uso em linha quando você tem lógica clara; caso contrário preferem procs armazenados.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top