Qual é a sua convenção de nomenclatura para procedimentos armazenados? [fechadas]

Eu já vi várias regras para nomear procedimentos armazenados.

Algumas pessoas prefixam o nome do sproc com usp_, outras com uma abreviação para o nome do aplicativo e outras com o nome do proprietário. Você não deve usar sp_ no SQL Server, a menos que realmente esteja falando sério.

Alguns iniciam o nome do processo com um verbo (obter, adicionar, salvar, remover). Outros enfatizam o nome da entidade.

Em um banco de dados com centenas de sprocs, pode ser muito difícil rolar e encontrar um sproc adequado quando você acha que ele já existe. As convenções de nomenclatura podem facilitar a localização de um sproc.

Você usa uma convenção de nomenclatura? Descreva-o e explique por que você o prefere a outras opções.

Resumo das respostas:

• Todo mundo parece defender a consistência da nomeação, para que possa ser mais importante que todos usem a mesma convenção de nomeação do que qual é usada em particular.
• Prefixos: Embora muitas pessoas usem usp_ ou algo semelhante (mas raramente sp_), muitas outras usam o banco de dados ou o nome do aplicativo. Um DBA inteligente usa gen, rpt e tsk para distinguir sprocs CRUD gerais daqueles usados ​​para relatórios ou tarefas.
• Verbo + Substantivo parece ser um pouco mais popular que Substantivo + Verbo. Algumas pessoas usam as palavras-chave SQL (Selecionar, Inserir, Atualizar, Excluir) para os verbos, enquanto outras usam verbos não-SQL (ou abreviações para eles) como Obter e Adicionar. Alguns distinguem entre substantivos singluar e plural para indicar se um ou mais registros estão sendo recuperados.
• Uma frase adicional é sugerida no final, quando apropriado. GetCustomerById, GetCustomerBySaleDate.
• Algumas pessoas usam sublinhados entre os segmentos de nome e outras evitam sublinhados. app_ Get_Customer vs. appGetCustomer - acho que é uma questão de legibilidade.
• Grandes coleções de sprocs podem ser segregadas em pacotes Oracle ou soluções e projetos do Management Studio (SQL Server) ou esquemas do SQL Server.
• Abreviações inescrutáveis ​​devem ser evitadas.

Por que escolhi a resposta que fiz: Existem TANTAS boas respostas. Obrigado a todos! Como você pode ver, seria muito difícil escolher apenas um. O que eu escolhi ressoou comigo. Eu segui o mesmo caminho que ele descreve - tentando usar Verbo + Substantivo e, em seguida, não conseguindo encontrar todos os sprocs que se aplicam ao Cliente.

Ser capaz de localizar um sproc existente ou determinar se ele existe, é muito importante. Problemas graves podem surgir se alguém inadvertidamente criar um sproc duplicado com outro nome.

Como geralmente trabalho em aplicativos muito grandes com centenas de sprocs, tenho preferência pelo método de nomeação mais fácil de encontrar. Para um aplicativo menor, eu poderia defender Verbo + Substantivo, pois segue a convenção geral de codificação para nomes de métodos.

Ele também defende a prefixação com o nome do aplicativo em vez do usp_ não muito útil. Como várias pessoas apontaram, às vezes o banco de dados contém sprocs para vários aplicativos. Portanto, prefixar o nome do aplicativo ajuda a segregar os sprocs E ajuda os DBAs e outros a determinar para qual aplicativo o sproc é usado.

No meu último projeto, usei usp_ [Action] [Object] [Process], por exemplo, usp_AddProduct ou usp_GetProductList, usp_GetProductDetail. No entanto, agora o banco de dados tem mais de 700 procedimentos, fica muito mais difícil encontrar todos os procedimentos em um objeto específico. Por exemplo, agora eu tenho que procurar 50 procedimentos ímpares de adição para o produto adicionar e 50 ímpares para obter etc.

Por causa disso, no meu novo aplicativo, estou planejando agrupar nomes de procedimentos por objeto, também removendo o usp porque sinto que é um pouco redundante, exceto para me dizer que é um procedimento, algo que posso deduzir do nome de o próprio procedimento.

O novo formato é o seguinte

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Ajuda a agrupar as coisas para facilitar a localização mais tarde, especialmente se houver uma grande quantidade de sprocs.

Em relação a onde mais de um objeto é usado, acho que a maioria das instâncias tem um objeto primário e secundário; portanto, o objeto primário é usado na instância normal e o secundário é referido na seção do processo, por exemplo, App_Product_AddAttribute.

Aqui estão alguns esclarecimentos sobre o problema do prefixo sp_ no SQL Server.

Os procedimentos armazenados nomeados com o prefixo sp_ são sprocs do sistema armazenados no banco de dados Mestre.

Se você der esse prefixo ao sproc, o SQL Server os procurará primeiro no banco de dados Mestre, depois no banco de dados de contexto, desperdiçando recursos desnecessariamente. E, se o sproc criado pelo usuário tiver o mesmo nome que um sproc do sistema, o sproc criado pelo usuário não será executado.

O prefixo sp_ indica que o sproc está acessível em todos os bancos de dados, mas que deve ser executado no contexto do banco de dados atual.

Aqui está uma boa explicação, que inclui uma demonstração do desempenho atingido.

Aqui está outra fonte útil fornecida por Ant em um comentário.

Sistemas húngaros (como o prefixo "usp" acima) me fazem estremecer.

Compartilhamos muitos procedimentos armazenados em diferentes bancos de dados estruturados de maneira semelhante; portanto, nos específicos de bancos de dados, usamos um prefixo do nome do banco de dados; procedimentos compartilhados não têm prefixo. Suponho que usar esquemas diferentes possa ser uma alternativa para se livrar de tais prefixos um tanto feios.

O nome real após o prefixo dificilmente é diferente da nomeação de funções: normalmente um verbo como "Adicionar", "Conjunto", "Gerar", "Calcular", "Excluir" etc. etc., seguido por vários substantivos mais específicos, como "Usuário" "," DailyRevenues "e assim por diante.

Respondendo ao comentário de Ant:

1. A diferença entre uma tabela e uma visualização é relevante para quem cria o esquema do banco de dados, não para quem acessa ou modifica seu conteúdo. No raro caso de precisar de detalhes do esquema, é fácil encontrá-lo. Para a consulta SELECT casual, é irrelevante. De fato, considero ser capaz de tratar tabelas e visualizações da mesma forma que uma grande vantagem.
2. Diferentemente das funções e procedimentos armazenados, é improvável que o nome de uma tabela ou exibição comece com um verbo ou seja qualquer coisa, exceto um ou mais substantivos.
3. Uma função requer que o prefixo do esquema seja chamado. De fato, a sintaxe da chamada (que usamos de qualquer maneira) é muito diferente entre uma função e um procedimento armazenado. Mas, mesmo que não fosse, o mesmo que 1. se aplicaria: se eu posso tratar as funções e procedimentos armazenados da mesma forma, por que não deveria?

Eu usei praticamente todos os diferentes sistemas ao longo dos anos. Finalmente desenvolvi este, que continuo usando hoje:

Prefixo:

• gen - Geral: CRUD, principalmente
• rpt - Relatório: auto-explicativo
• tsk - Tarefa: geralmente algo com lógica processual, executada através de trabalhos agendados

Especificador de ação:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(Nos casos em que o procedimento faz muitas coisas, o objetivo geral é usado para escolher o especificador de ação. Por exemplo, um INSERT do cliente pode exigir uma grande quantidade de trabalho de preparação, mas o objetivo geral é INSERT, então "Ins" é escolhido.

Objeto:

Para gen (CRUD), esta é a tabela ou o nome da exibição que está sendo afetado. Para rpt (relatório), esta é uma breve descrição do relatório. Para tsk (Tarefa), esta é uma breve descrição da tarefa.

Clarificadores opcionais:

Essas são informações opcionais usadas para aprimorar o entendimento do procedimento. Os exemplos incluem "Por", "Para" etc.

Formato:

[Prefixo] [Especificador de ação] [Entidade] [Clarificadores opcionais]

Exemplos de nomes de procedimentos:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Lista de clientes

• UserPreference_DeleteByUserID

Nenhum prefixo ou bobagem húngara. Apenas o nome da tabela à qual está mais associado e uma descrição rápida do que ela faz.

Uma ressalva ao que foi dito acima: eu sempre prefixo pessoalmente todo o meu CRUD gerado automaticamente com zCRUD_ para que ele seja classificado no final da lista, onde não preciso olhar para ele.

Iniciar um nome de procedimento armazenado com sp_é inválido no SQL Server porque todos os sprocs do sistema iniciam com sp_. A nomeação consistente (mesmo na extensão do hobgoblin-dom) é útil porque facilita tarefas automatizadas com base no dicionário de dados. Os prefixos são um pouco menos úteis no SQL Server 2005, pois oferecem suporte a esquemas, que podem ser usados ​​para vários tipos de namespaces da mesma maneira que prefixa os nomes. Por exemplo, em um esquema em estrela, pode-se ter esquemas obscuros e factuais e consultar as tabelas desta convenção.

Para procedimentos armazenados, a prefixação é útil com o objetivo de identificar os sprocs de aplicativos dos sprocs do sistema. up_vs. sp_torna relativamente fácil identificar procedimentos armazenados que não são do sistema a partir do dicionário de dados.

Eu sempre encapsulo os procedimentos armazenados em pacotes (estou usando Oracle, no trabalho). Isso reduzirá o número de objetos separados e ajudará a reutilizar o código.

A convenção de nomenclatura é uma questão de gosto e algo que você deve concordar com todos os outros desenvolvedores no início do projeto.

para bancos de dados pequenos, eu uso uspTableNameOperationName, por exemplo, uspCustomerCreate, uspCustomerDelete, etc. Isso facilita o agrupamento por entidade 'principal'.

para bancos de dados maiores, adicione um nome de esquema ou subsistema, por exemplo, Recebimento, Compra, etc. para mantê-los agrupados (já que o servidor sql gosta de exibi-los em ordem alfabética)

tento evitar abreviações nos nomes, para maior clareza (e as novas pessoas no projeto não precisam se perguntar o que significa 'UNAICFE' porque o nome da pasta é uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Atualmente, uso um formato semelhante ao seguinte

Notação:

[PREFIXAR] [APLICATIVO] [MÓDULO] _ [NOME]

Exemplo:

P_CMS_USER_UserInfoGet

Gosto dessa notação por alguns motivos:

• começar com um prefixo muito simples permite que o código seja gravado para executar apenas objetos que começam com o prefixo (para reduzir a injeção de SQL, por exemplo)
• em nosso ambiente maior, várias equipes estão trabalhando em aplicativos diferentes executados na mesma arquitetura de banco de dados. A notação de aplicativo designa qual grupo possui o SP.
• As seções Módulo e Nome simplesmente completam a hierarquia. Todos os nomes devem poder corresponder ao grupo / aplicativo, módulo, função da hierarquia.

Eu sempre uso:

usp [Nome da tabela] [Ação] [Detalhes adicionais]

Dada uma tabela chamada "tblUser", isso me dá:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Os procedimentos são classificados em ordem alfabética por nome da tabela e por funcionalidade, portanto é fácil ver o que posso fazer com qualquer tabela. O uso do prefixo "usp" me permite saber o que estou chamando se estiver escrevendo (por exemplo) um procedimento de 1000 linhas que interaja com outros procedimentos, várias tabelas, funções, visualizações e servidores.

Até que o editor no SQL Server IDE seja tão bom quanto o Visual Studio, estou mantendo os prefixos.

prefixo do aplicativo_ prefixo da operação_ descrição dos objetos de banco de dados envolvidos (menos os espaços entre os sublinhados - foi necessário colocar espaços para que eles aparecessem) .

prefixos de operação que usamos -

• " Get " - retorna um conjunto de registros
• " Ins " - insere dados
• " Upd " - atualiza dados
• " Del " - exclui dados

por exemplo

wmt_ ins _ detalhes do cliente

"ferramenta de gerenciamento de força de trabalho, insira detalhes na tabela do cliente"

vantagens

Todos os procedimentos armazenados relacionados ao mesmo aplicativo são agrupados por nome. Dentro do grupo, os procedimentos armazenados que realizam o mesmo tipo de operação (por exemplo, inserções, atualizações etc.) são agrupados.

Este sistema funciona bem para nós, tendo aprox. 1000 procedimentos armazenados em um banco de dados em cima da minha cabeça.

Até agora, não encontramos nenhuma desvantagem nessa abordagem.

GetXXX - Obtém XXX com base no @ID

GetAllXXX - Obtém todas as XXX

PutXXX - Insere XXX se @ID passado for -1; mais atualizações

DelXXX - Exclui XXX com base em @ID

Acho que a convenção de nomes usp_ não serve para nada.

No passado, eu usei os prefixos Get / Update / Insert / Delete para operações CRUD, mas agora como uso o Linq to SQL ou o EF para fazer a maior parte do meu trabalho CRUD, eles desapareceram completamente. Como tenho tão poucos procs armazenados em meus novos aplicativos, as convenções de nomenclatura não importam mais como costumavam ;-)

Para o aplicativo atual em que estou trabalhando, temos um prefixo que identifica o nome do aplicativo (quatro letras minúsculas). A razão para isso é que nosso aplicativo deve coexistir com um aplicativo herdado no mesmo banco de dados, portanto, o prefixo é obrigatório.

Se não tivéssemos a restrição herdada, tenho certeza de que não usaríamos um prefixo.

Após o prefixo, geralmente iniciamos o nome do SP com um verbo que descreve o que o procedimento faz e, em seguida, o nome da entidade em que operamos. A pluralização do nome da entidade é permitida - Tentamos enfatizar a legibilidade, para que seja óbvio o que o procedimento faz somente com o nome.

Os nomes típicos de procedimentos armazenados em nossa equipe seriam:

shopGetCategories
shopUpdateItem

Eu não acho que realmente importe exatamente qual é o seu prefixo, desde que você seja lógico e consistente. Pessoalmente eu uso

spu_ [descrição da ação] [descrição do processo]

onde a descrição da ação é uma de um pequeno intervalo de ações típicas, como obter, configurar, arquivar, inserir, excluir etc. A descrição do processo é algo curto, mas descritivo, por exemplo

spu_archiveCollectionData 

ou

spu_setAwardStatus

Eu nomeio minhas funções da mesma forma, mas prefixo udf_

Vi pessoas tentando usar a notação pseudo-húngara para nomear procedimentos, o que, na minha opinião, oculta mais do que revela. Enquanto eu listar meus procedimentos em ordem alfabética, posso vê-los agrupados por funcionalidade e, para mim, esse parece ser o ponto ideal entre ordem e rigor desnecessário

Evite sp_ * no servidor SQl, porque todas as predições armazenadas no sistema começam com sp_ e, portanto, fica mais difícil para o sistema encontrar o objeto correspondente ao nome.

Portanto, se você começar com algo diferente de sp_, as coisas se tornarão mais fáceis.

Portanto, usamos uma nomeação comum de Proc_ para começar. Isso facilita a identificação dos procedimentos se apresentados com um grande arquivo de esquema.

Além disso, atribuímos um prefixo que identifica a função. Gostar

Proc_Poll_Interface, Proc_Inv_Interface etc.

Isso nos permite encontrar todos os procs armazenados que realizam o trabalho de POLL versus inventário etc.

De qualquer forma, o sistema de prefixos depende do domínio do seu problema. Mas tudo dito e feito algo semelhante deveria estar presente, mesmo que seja apenas para permitir que as pessoas localizem rapidamente o procedimento armazenado no menu suspenso explorere para edição.

outros eg's de função.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Seguimos a nomenclatura baseada em função, pois os procs são semelhantes ao código / função, em vez de objetos estáticos, como tabelas. Não ajuda que os Procs possam trabalhar com mais de uma tabela.

Se o proc executou mais funções do que as que podem ser tratadas em um único nome, significa que o proc está fazendo muito mais do que o necessário e é hora de dividi-las novamente.

Espero que ajude.

Entrei tarde no tópico, mas quero inserir minha resposta aqui:

Nos meus dois últimos projetos, existem tendências diferentes, como em um que usamos:

Para obter dados: s <nome do arquivo> _G
Para excluir dados: s <nome do nome> _D
Para inserir dados: s <nome do nome> _I
Para atualizar dados: s <nome do nome> _U

Essas convenções de nomenclatura também são seguidas no front-end, prefixando a palavra dt .

Exemplo:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Com a ajuda das convenções de nomenclatura acima em nosso aplicativo, temos um bom e fácil de lembrar nomes.

Enquanto no segundo projeto, usamos as mesmas convenções de nomenclatura com pouca diferença:

Para obter dados: sp_ <nome_da_tabela> G
Para excluir dados: sp_ <nome_da_tabela> D
Para inserir dados: sp_ <nome_da_tabela> I
Para atualizar dados: sp_ <nome_da_tabela> U

Exemplo:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU