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

Question

Eu tenho visto várias regras para nomear procedimentos armazenados.

Algumas pessoas prefixar o nome do sproc com usp_, outros com uma abreviação para o nome do aplicativo, e outros ainda com um nome de proprietário. Você não deve usar sp_ no SQL Server a menos que você realmente quer dizer isso.

Alguns começam o nome proc com um verbo (Get, Adicionar, Salvar, Remover). Outros enfatizam o nome (s) entidade.

Em um banco de dados com centenas de sprocs, pode ser muito difícil para se deslocar ao redor e encontrar um sproc adequado quando você pensa que já existe. Convenções de nomenclatura pode fazer a localização de um sproc mais fácil.

Do que você usar uma convenção de nomenclatura? Por favor descrevê-lo, e explicar por que você preferem sobre outras opções.

Síntese das respostas:

• Todos parecem consistência defensor da nomenclatura, que poderia ser mais importante para que todos possam usar a mesma convenção de nomenclatura de que um particular é usado.
• Prefixos: Enquanto um monte de gente usar usp_ ou algo semelhante (mas raramente sp_), muitos outros usam banco de dados ou nome do aplicativo. Um DBA inteligente usa gen, rpt e tsk distinguir sprocs gerais CRUD dos utilizados para relatórios ou tarefas.
• verbo + substantivo parece ser um pouco mais popular do que substantivo + verbo. Algumas pessoas usam as palavras-chave SQL (SELECT, INSERT, UPDATE, DELETE) para os verbos, enquanto outros usam verbos não-SQL (ou abreviaturas para eles) como Get e em Adicionar. Alguns distinguir entre singluar e substantivos no plural para indicar se um ou muitos registros estão sendo recuperados.
• Uma frase adicional é sugerido no final, se for o caso. GetCustomerById, GetCustomerBySaleDate.
• Algumas pessoas usam sublinhados entre os segmentos nome, e alguns sublinhados a evitar. App_ get_cliente vs. appGetCustomer - Eu acho que é uma questão de legibilidade
.
• As grandes coleções de sprocs podem ser agrupadas em pacotes Oracle ou esquemas soluções Management Studio (SQL Server) e projetos, ou SQL Server.
• abreviaturas Inescrutável deve ser evitado.

Por que escolher a resposta que eu fiz: Há tantas respostas boas. Obrigado a todos! Como você pode ver, seria muito difícil escolher apenas um. O que eu escolhi me marcou. Tenho seguido o mesmo caminho que ele descreve - tentando usar verbo + substantivo e depois não ser capaz de encontrar todos os sprocs que se aplicam ao Cliente.

Ser capaz de localizar um sproc existente, ou para determinar se um ainda existe, é muito importante. sérios problemas podem surgir se alguém, inadvertidamente cria um sproc duplicado com outro nome.

Desde que geralmente trabalham em grandes aplicativos com centenas de sprocs, eu tenho uma preferência para o método mais fácil de encontrar nomear. Para uma aplicação menor, eu poderia defender verbo + substantivo, uma vez que segue a convenção geral de codificação de nomes de métodos.

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

Answer 1

Para o meu último projeto eu usei usp_ [Action] [objeto] [Process] Assim, por exemplo, usp_AddProduct ou usp_GetProductList, usp_GetProductDetail. No entanto, agora o banco de dados está em 700 procedimentos mais, torna-se muito mais difícil de encontrar todos os procedimentos sobre um objeto específico. Por exemplo i agora tem que procurar 50 procedimentos estranhos adição para o suplemento de produto e 50 ímpares para o Obter etc.

Devido a isso no meu novo aplicativo Estou pensando em agrupar nomes de procedimentos por objeto, eu também estou soltando a USP como eu sinto que é um pouco redundante, além de me dizer seu um procedimento, algo que eu posso deduzir o nome do procedimento em si.

O novo formato é o seguinte

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Ela ajuda a agrupar as coisas para constatação mais fácil mais tarde, especialmente se houver uma grande quantidade de sprocs.

Em relação onde mais do que um objecto é usado, descobri que a maioria dos casos, de um objecto primário e secundário, de modo que o objecto principal é utilizado no exemplo normal, e o secundário é referido na secção de processos, por exemplo App_Product_AddAttribute.

Answer 2

Eis alguns esclarecimentos sobre a questão sp_ de prefixo no SQL Server.

Os procedimentos armazenados nomeado com o sp_ de prefixo são sprocs sistema armazenadas no banco de dados mestre.

Se você dá o seu sproc esse prefixo, o SQL Server procura por eles no banco de dados mestre em primeiro lugar, em seguida, o banco de dados de contexto, desperdiçando assim desnecessariamente recursos. E, se o sproc criado pelo usuário tem o mesmo nome como um sproc sistema, o sproc criado pelo usuário não será executado.

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

Aqui está uma explicação agradável, que inclui uma demonstração do desempenho hit.

Aqui está outra fonte útil fornecida pelo Ant em uma comentário.

Answer 3

Sistemas Húngaro (como o acima "USP" prefixo) me faz tremer.

Nós compartilhamos muitos procedimentos armazenados em diferentes bancos de dados, semelhante estruturados, então para aqueles específicos do banco de dados, usamos um prefixo do nome próprio banco de dados; procedimentos compartilhados têm nenhum prefixo. Suponho utilizando diferentes esquemas pode ser uma alternativa para se livrar de tais prefixos pouco feias por completo.

O nome real após o prefixo não é muito diferente de nomeação função: tipicamente um verbo como "Add", "Set", "Gerar", "Calcular", "Delete", etc., seguido por vários nomes mais específicos tais como "Usuário", "DailyRevenues", e assim por diante.

Respondendo ao comentário de Ant:

1. A diferença entre uma tabela e uma vista é relevante para aqueles que projetar o esquema de banco de dados, e não aqueles que o acesso ou modificar seu conteúdo. No caso raro de precisar detalhes do esquema, é fácil o suficiente para encontrar. Para a consulta SELECT casual, é irrelevante. Na verdade, eu considero ser capaz de tabelas tratar e vê o mesmo que uma grande vantagem.
2. Ao contrário, com funções e procedimentos armazenados, o nome de uma tabela ou exibição é improvável que começar com um verbo, ou ser qualquer coisa, mas um ou mais substantivos.
3. A função requer o prefixo esquema a ser chamado. Na verdade, a sintaxe de chamada (que usamos, pelo menos) é muito diferente entre uma função e um procedimento armazenado. Mas mesmo se não fosse, o mesmo que seria aplicável 1.:? Se eu posso tratar funções e procedimentos armazenados o mesmo, por que não me

Answer 4

Iniciando um nome de procedimento withsp_ armazenado é ruim em SQL Server porque os sprocs sistema tudo começa com sp_. nomenclatura consistente (mesmo para a extensão de hobgoblin-DOM) é útil porque facilititates tarefas automatizadas com base no dicionário de dados. Prefixos são um pouco menos útil no SQL Server 2005, pois suporta esquemas, que podem ser utilizados para vários tipos de namespaces na maneira que prefixos sobre nomes usados ??para. Por exemplo, em um esquema em estrela, um poderia ter dim e fato esquemas e consulte as tabelas por esta convenção.

Para procedimentos armazenados, prefixação é útil para o propósito de identificando sprocs aplicação de sprocs sistema. up_ vs sp_ faz com que seja relativamente fácil de identificar procedimentos armazenados fora do sistema a partir do dicionário de dados.

Answer 5

TableName_WhatItDoes

• Comment_GetByID

• CUSTOMER_LIST

• UserPreference_DeleteByUserID

Não há prefixos ou absurdo húngara bobo. Apenas o nome da tabela é mais associado com, e uma breve descrição do que ele faz.

Uma ressalva ao acima:. Eu, pessoalmente, sempre prefixo toda a minha gerada automaticamente CRUD com zCRUD_ para que ele classifica para a final da lista, onde eu não tenho de olhar para ele

Answer 6

Eu tenho usado praticamente todos os diferentes sistemas ao longo dos anos. I finalmente desenvolveu este, que eu continuo a uso hoje:

Prefixo:

• gen - Geral: CRUD, principalmente
• rpt - Relatório: auto-explicativo
• tsk - Tarefa: geralmente algo com a lógica processual, executado através de tarefas agendadas

Ação especificador:

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 INSERIR cliente pode exigir uma boa dose de trabalho de preparação, mas o objetivo geral é INSERT, tão "Ins" é escolhido.

Objeto:

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

Opcional clarificadores:

Estes são pedaços opcionais de informação utilizadas para melhorar a compreensão do procedimento. Exemplos incluem "por", "For", etc.

Formato:

[Prefixo] [Ação especificador] [Entidade] [Opcional clarificadores]

Os exemplos de nomes de procedimentos:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Answer 7

Eu sempre encapsular os procedimentos armazenados no pacotes (estou usando o Oracle, no trabalho). Isso vai reduzir o número de objetos separados e reutilização de código ajuda.

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.

Answer 8

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

para bancos de dados maiores, adicionar um nome de esquema ou subsistema, por exemplo, Receber, Compras, etc. para mantê-los agrupados (desde sql server gosta de exibi-los em ordem alfabética)

i tentar evitar abreviaturas nos nomes, para maior clareza (e novas pessoas sobre o projeto não tem que saber o que 'UNAICFE' significa porque o sproc é nomeado uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Answer 9

Eu uso atualmente um formato que é parecido com o seguinte

Notação:

[PREFIX] [aplicação] [Módulo] _ [NOME]

Exemplo:

P_CMS_USER_UserInfoGet

Eu como esta notação por alguns motivos:

• começando com muito simples Prefixo permite que o código a serem escritos para executar somente objectos, começando logo com o prefixo (para reduzir a injecção SQL, por exemplo)
• em nosso ambiente maior, várias equipes estão trabalhando em diferentes aplicativos que funcionam da mesma arquitetura de banco de dados. Os designados notação Aplicação que grupo possui o SP.
seções
• O módulo e nome simplesmente completar a hierarquia. Todos os nomes devem ser capazes de ser compensada com Grupo / App, módulo, função da hierarquia.

Answer 10

Eu sempre uso:

usp [Nome da Tabela] [Action] [detalhe extra]

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

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Os procedimentos são ordenadas alfabeticamente pelo nome da tabela e pela funcionalidade, por isso é fácil de ver o que posso fazer para qualquer mesa. Usando o prefixo "USP" permite-me saber o que eu estou chamando se eu sou (por exemplo) escrevendo um procedimento 1000-line que interage com outros procedimentos, várias tabelas, funções, pontos de vista e servidores.

Até o editor no Servidor de IDE SQL é tão bom quanto o Visual Studio Estou mantendo os prefixos.

Answer 11

prefix_ aplicação descrição da operação prefix_ de banco de dados de objetos envolvidos (menos os espaços entre sublinhados - tive que colocar espaços para que eles apareçam).

prefixos operação que usamos -

• “ get ” - retorna um conjunto de registros
• “ ins ” - insere dados
• “ upd ” - atualiza dados
• “ del ” - dados Exclui

por exemplo

ins wmt_ _ _details clientes

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

vantagens

Todos os procedimentos armazenados relacionados com a mesma aplicação são agrupados pelo nome. Dentro do grupo, os procedimentos que realizam o mesmo tipo de funcionamento (por exemplo, inserções, de actualização, etc.) armazenados são agrupados em conjunto.

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

não têm se deparar com quaisquer desvantagens para esta abordagem até agora.

Answer 12

getXXX - Obtém XXX baseado em @ID

GetAllXXX - Obtém todos XXX

PutXXX - Insere XXX se @ID passado é 1; atualizações else

DelXXX - Exclui XXX baseado em @ID

Answer 13

Eu acho que a convenção de nomenclatura usp_ faz ninguém qualquer bom.

No passado, eu usei Get / Atualizar / Inserir / prefixos de exclusão para operações CRUD, mas agora desde que eu usar LINQ to SQL ou o EF para fazer a maioria do meu trabalho CRUD, estes são completamente desaparecido. Desde que eu tenho tão poucos procedimentos armazenados em minhas novas aplicações, as convenções de nomenclatura não importa mais como antigamente; -)

Answer 14

Para a corrente, aplicação que eu estou trabalhando, temos um prefixo que identifica o nome do aplicativo (quatro letras minúsculas). A razão para isso é que a nossa aplicação deve ser capaz de co-existir com um aplicativo de legado na mesma base de dados, de modo que o prefixo é uma obrigação.

Se não tivéssemos a restrição legado, tenho a certeza de que não estaria usando um prefixo.

Depois do prefixo que geralmente começam o nome SP com um verbo que descreve que o procedimento faz, em seguida, o nome da entidade que operar. Pluralização do nome da entidade é permitido - Tentamos enfatizar a leitura, de modo que é óbvio que o procedimento faz do nome sozinho

.

nomes de procedimento armazenado típicas em nossa equipe seria:

shopGetCategories
shopUpdateItem

Answer 15

Eu não acho que realmente importa exatamente o que o seu prefixo é tão longo como você está lógica e consistente. Pessoalmente uso I

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

onde descrição da ação é parte de um pequeno conjunto de acções típicas, como get, set, arquivo, inserir, excluir etc. A descrição do processo é algo curto, mas descritivo, por exemplo

spu_archiveCollectionData 

ou

spu_setAwardStatus

eu nomeio minhas funções de forma semelhante, mas prefixo com UDF _

pessoas

eu vi tentar usar a notação de pseudo-húngaro para o procedimento de nomeação, que na minha opinião esconde mais do que revela. Enquanto quando eu listar meus procedimentos em ordem alfabética eu posso vê-los agrupados por funcionalidade, então para mim isso parece ser o ponto ideal entre ordem e rigor desnecessário

Answer 16

Evite sp_ * no SQL Server coz todos prcedures armazenados do sistema começa com sp_ e, portanto, torna-se mais difícil para o sistema para encontrar o objeto correspondente ao nome.

Então, se você começar com algo diferente de SP_ coisas tornam-se mais fácil.

Então, nós usamos uma nomenclatura comum de Proc_ para começar. Isso torna mais fácil para identificar os procedimentos se apresentou com um arquivo de esquema grande.

Para além de que vamos atribuir um prefixo que identifica a função. Como

Proc_Poll_Interface, Proc_Inv_Interface etc.

Isso nos permite encontrar todos os procedimentos armazenados que faz o trabalho de ENQUETE vs que faz Inventory etc.

De qualquer forma o sistema de prefixo depende do seu domínio do problema. Mas al dito e feito algo semelhante deve estar presente mesmo que seja apenas para permitir que as pessoas para quicly localizar o procedimento armazenado no Explorere suspensa para editar.

Outro exemplo é da função.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Nós seguimos a nomeação baseado em função coz Procs são semelhantes ao código / função em vez de objetos estáticos como tabelas. Ela não ajuda que Procs pode trabalhar com mais de uma tabela.

Se o proc realizada mais funções do que pode ser tratado em um único nome, significa que o proc está fazendo maneira muito mais do que o necessário e é hora de dividi-los novamente.

Espero que ajude.

Answer 17

Eu entrei final da discussão, mas eu quero entrar em minha resposta aqui:

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

Para obter dados: s _G
Para apagar dados: s _D
Para inserir dados: s _I
Para atualizar dados: s _U

A convenções de nomenclatura também é seguido em front-end pelo prefixo palavra dt .

Exemplo:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Com a ajuda de acima convenções de nomenclatura em nossa aplicação, temos uma boa e fácil de lembrar nomes.

Enquanto em segundo projeto foram utilizados os mesmos convenções de nomenclatura com diferença lill:

Para obter dados: sp_ G
Para apagar dados: sp_ D
Para inserir dados: sp_ I
Para atualizar dados: sp_ U

Exemplo:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU