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

122

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.

DOK
fonte
1
Usp de quê?
Midhat
2
Eu acredito que usp é a abreviação de "user procedure". Isso o distingue dos procedimentos do sistema com o prefixo "sp_". Essa é uma distinção importante, como você pode ler nas respostas.
DOK
obrigado dok. grazie mille
Midhat
1
Estou votando nisso apenas porque está fechado, espero mostrar os poderes de que perguntas como essa são úteis para a comunidade.
tsilb

Respostas:

66

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.

dnolan
fonte
3
E se mais de um objeto estiver envolvido? Por exemplo, e se o sproc consultar informações da tabela Customer e Orders?
DOK
2
Obrigado Mitch, vamos esclarecer. Esse prefixo "App" é um espaço reservado para outra abreviação, indicando o nome (ou acrônimo) real do aplicativo. Com três aplicativos que compartilham um banco de dados, pode haver ICA_Product_Add, CRM_Product_Add e BPS_Product_Add.
DOK
2
Por que você duplicaria todos os procedimentos três vezes para três aplicativos? O ponto principal dos procedimentos de armazenamento é ter um único local onde uma determinada ação acontece. "ICA_Product_Add, CRM_Product_Add e BPS_Product_Add" destrói isso.
Jason Kester
3
Jason, esses sprocs podem estar inseridos em tabelas diferentes. Eles podem ter diferentes parâmetros de entrada ou valores de retorno. Ou eles podem ter um comportamento diferente. Se os sprocs fazem a mesma coisa, eu concordo, deve haver apenas uma versão. Como alguém sugeriu, sprocs compartilhados podem não ter prefixo.
DOK
1
Se você tiver vários aplicativos chamando o mesmo procedimento, precisará ter cuidado extra, qualquer modificação nesse processo poderá interromper esses vários aplicativos. Em termos de nomes, é uma área cinzenta, mas você pode chamá-la de comum / global ou qualquer coisa que achar melhor. @ localocal: obrigado por ser informativo.
27568 dnolan
36

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.

DOK
fonte
Hmm, eu não entendo. Por que sp dá um impacto no desempenho? Usp ou gsp estão bem?
Erwin Rooijakkers
1
@ user2609980 DOK diz pesquisas SQL Server para sp_proc prefixado no Master DB primeiro, depois no DB atual se não for encontrado
Goto
+1 por declarar claramente algo que tem explicações mais complicadas em outros lugares. Não é novidade para mim, mas acho que essa é uma explicação simples e concisa para alguém que está começando.
undrline
O link para a demonstração do resultado do desempenho é de um artigo escrito em 2001. Foi alterado desde então. Aqui está um artigo mais completo (de 2012) de Aaron Bertrand: sqlperformance.com/2012/10/t-sql-queries/sp_prefix
Michael J Swart
16

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?
Sören Kuklau
fonte
1
Então, como você sabe se está interagindo com um procedimento, uma função, uma exibição, uma tabela ou qualquer outra coisa?
Ant
1
Eu imagino que as funções possam começar com "Get" ou ser um nome que não comece com um verbo. Tudo o resto seria um procedimento porque, afinal, eles são chamados de procedimentos armazenados. Os procedimentos ocultam os detalhes, como visualizações, tabelas e qualquer outra coisa.
Mark Stock
3
Mas não é húngaro. O "usp" não é uma declaração de variável húngara. O "u" não significa "atualização", significa "usuário", como em "procedimento armazenado definido pelo usuário" e está apenas protegendo do SQL Server que procura no Master DB toda vez que procura seu procedimento armazenado. Naturalmente, existem outras maneiras, mas "usp" é geralmente considerado um padrão em muitos corpos e, pelo que vi, funciona bem. Também é ensinado pela Microsoft, e Microsoft recomenda convenção de nomenclatura: msdn.microsoft.com/en-us/library/ms124456(v=SQL.100).aspx
asus3000
10

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
Pittsburgh DBA
fonte
4
Agora, há uma visão interessante do prefixo. Parece uma boa maneira de segregar sprocs pelo uso.
DOK
10

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.

Jason Kester
fonte
Segregar os itens "z" dos demais parece uma ótima idéia.
DOK
Eu gosto desse método Eles precisam ser fáceis de encontrar. Quando olho uma lista dos primeiros sprocs de verbo e vejo 200 Gets, 200 Inserts, 200 updates, é difícil encontrar todos para uma tabela ou agrupamento específico. Eu usei o método do verbo primeiro, e isso acaba se tornando uma bagunça. O nome da tabela resolve primeiro esse problema. Por exemplo, na resposta acima, todos os seus comentários ou clientes seriam agrupados, fáceis de encontrar.
Astrosteve
1
E se você tiver uma consulta juntando várias tabelas?
leandronn
10

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.

ConcernedOfTunbridgeWells
fonte
2
Nomear sprocs "sp_" também é uma péssima idéia para velocidade, porque o SQL Server tenta otimizar suas pesquisas para aquelas com base no pressuposto de que são procedimentos do sistema. Dê uma olhada aqui, quinto ponto abaixo: rakph.wordpress.com/2008/04/19/tips-store-procedure
Ant
4

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.

Gabriele D'Antona
fonte
Pacotes são bons. A partir do SQL Server 2005, o Management Studio permite criar "soluções" para armazenar sprocs relacionados e outras instruções SQL.
DOK
2
@DOK - observe que esses pacotes não têm pegada no próprio banco de dados. Eles são puramente artefatos da ferramenta front-end. Você não pode consultar por pacote no dicionário de dados. Pacotes Oracle são objetos de primeira classe no dicionário de dados do sistema e têm seu próprio escopo.
ConcernedOfTunbridgeWells
4

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)

Steven A. Lowe
fonte
Sim, obrigado especialmente por abordar as abreviações.
DOK
@ [DOK]: não tem de que? ;-)
Steven A. Lowe
Steve, você recebeu um voto positivo. Eu estava muito ocupado lendo a enxurrada de respostas e comentários e agonizando sobre qual resposta é "melhor".
DOK
@ [DOK]: obrigado; a melhor resposta provavelmente é a combinação que faz sentido para a sua situação.
Steven A. Lowe
4

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.
pearcewg
fonte
2

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.

Formiga
fonte
2

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.

Russ Cam
fonte
Geralmente detesto o uso de sublinhados, mas a maneira como você o usa - não apenas para segregar o prefixo, mas também para segregar a operação - facilitaria a localização ao digitalizar uma lista de centenas de sprocs. Pretty_neat_idea.
DOK
2

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

tsilb
fonte
1

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 ;-)

Dave Markle
fonte
1
Prefixar cada sproc com _usp não ajuda a distinguir entre eles. Eu acho que alguns DBAs gostam desse prefixo porque indica o tipo de objeto de banco de dados. Talvez tenhamos notícias de um deles que goste.
DOK
1

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
driis
fonte
Bem, você nunca sabe, quando você está trabalhando em um banco de dados dedicado a um aplicativo, se haverá outro aplicativo posteriormente usando o mesmo banco de dados. Na sua situação, com certeza ajuda a segregar os sprocs.
DOK
1

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

Cruachan
fonte
spu_, interessante. Esquiva o problema sp_ do SQL Server.
DOK
1

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.

vida de computação
fonte
1

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
Gaurav Aroraa
fonte
Interessante. Nunca vi isso acontecer dessa maneira, mas é fácil lembrar ou adivinhar os nomes corretos.
DOK
1
Graças DOK, Sim, é fácil de lembrar e nós desenvolvedor se sentir livre de qualquer complexidade em nomes
Gaurav Aroraa
9
Por que não _C _R _U _D?
onedaywhen
@ onedaywhen - é uma boa ideia, vou sugerir ao nosso DBA para que possamos manter as conversões de nomes em conformidade. Mas, o principal motivo para essa convenção de nomenclatura para apresentar todos os objetos corretamente, a menos que eu perdi alguma coisa ...
Gaurav Aroraa
1
O prefixo "sp_" não é recomendado.
Piyey