DataSnap com Stored Procedures (1/3)
A natureza do Delphi DataSnap é utilizar SQL dinâmico, que é construído e enviado em tempo de execução para o servidor. Talvez por isso muita gente não se dê conta que pode usar Stored Procedures (SP) em um servidor de aplicação DataSnap. Na verdade, nada nos impede usar SP para obter dados ou para resolver atualizações no banco de dados e os SP podem ser muito úteis.
Vantagens de usar Stored Procedures:
- SP podem incluir lógica condicional, cursores, chamar outros SP, funções, etc.
- SP são parametrizáveis (TParams)
- SP são transações atômicas
- SP são escritos em SQL
- SP podem ser facilmente atualizados com o sistema no ar
- SP têm plano de execução previamente “compilado”
Desvantagens de usar Stored Procedures:
- SP não são portáveis entre bancos de dados diferentes
- SP são somente-leitura
- SP de SELECT dificultam a geração automática de SQL de atualização
Usar SP não fere nenhum princípio de desenvolvimento multicamadas. De fato, o SQL fica no servidor, não no cliente. Tem gente que prefere não ter nenhuma lógica no banco de dados e tratá-lo como um simples repositório de dados. Outros, pelo contrário, entendem que toda lógica de acesso a dados precisa estar no servidor de banco de dados. Finalmente, há aqueles, entre os quais eu me incluo, que preferem um equilíbrio, pesando custos e benefícios caso a caso.
Nos próximos artigos vou mostrar como usar SP para obter dados do servidor de aplicação e como usar SP para atualizar os dados em um ApplyUpdates.
Comments
3 Responses to “DataSnap com Stored Procedures (1/3)”
Deixe uma Resposta
-
-
Sobre
Malta on Delphi é um site de artigos técnicos originais sobre Delphi.
-
Blogroll
Bom, não sou muito fã de SP, portanto não posso opinar, mas o que são “transações atômicas”?
Google é seu amigo. ;)
http://en.wikipedia.org/wiki/Atomic_transaction
Daniel, estou aguardando ansiosamente pela conclusão desta matéria.. pois assim com você eu não deixo o Sql no client, no client somente a clausula where.
Excelente trabalho.
Fausto