Uma das questões mais desconcertantes com as quais tive que lidar tem a ver com grupos de procedimentos armazenados. Dado um procedimento armazenado, usp_DoSomethingAwesomeposso criar esse proc em outro grupo chamando-o usp_DoSomethingAwesome;2.
Descobri isso ao solucionar alguns problemas de replicação (Editor: SQL 2000 Ent., Dist/Sub: 2008 R2 Ent.) que surgiram com alguns dos procedimentos armazenados de replicação Inserir, Atualizar e Excluir gerados pelo sistema.
Qual é o propósito/pensamento por trás dessa habilidade de "agrupamento"?
Isso é como sobrecarregar um método. Essencialmente, você pode criar duas ou mais versões de seu procedimento armazenado, onde cada uma faz coisas diferentes - pega um número diferente de parâmetros, opera em tabelas diferentes, tem saída diferente, etc.
Eles são chamados de Procedimentos Numerados e estão absolutamente obsoletos ( anunciados desde 2005 ). Eles ainda têm suporte no SQL Server 2012, mas alguns recursos não funcionam bem com eles. Por exemplo, eles são considerados uma violação de contenção em bancos de dados contidos, e qualquer procedimento numerado > 1 não será criado:
A capacidade (obsoleta) de agrupar Stored Procedures parece existir para um único (e um tanto bobo) propósito: a capacidade de deletar em massa por meio de uma única
DROPinstrução. De acordo com a documentação do MSDN do SQL Server 2000 para criar um procedimento armazenado :Não há benefícios adicionais em usar essa construção, pois usar o mesmo nome de base nem permite sobrecarga (assinaturas não precisam ser únicas e nenhum roteamento de execução automática para um "número" específico) e, portanto, você ainda precisa use o "número" ao executar. Daí a determinação de "bobo" (e isso provavelmente é ser muito legal sobre isso ;-).