Convenções de nomeação de bancos de dados, tabelas e colunas? [fechadas]

791

Sempre que eu projeto um banco de dados, sempre me pergunto se existe uma melhor maneira de nomear um item no meu banco de dados. Muitas vezes, faço as seguintes perguntas:

  1. Os nomes das tabelas devem ser plurais?
  2. Os nomes das colunas devem ser singulares?
  3. Devo prefixar tabelas ou colunas?
  4. Devo usar algum caso para nomear itens?

Existem diretrizes recomendadas para nomear itens em um banco de dados?

GateKiller
fonte
7
Eu acho que devemos nomear plural para tabelas e singular para colunas.
AZ_
7
Eu vejo uma tabela como "armazenamento" com vários itens, não uma "entidade" única, então o nomeio plural. Quando mapeei tabelas em objetos, eu os nomeava como singulares. Esta é apenas a minha opinião pessoal.
dpp 19/07/2013
2
@Tryinko Usar ID em todo o lugar é LIVING HELL para quem faz junções de várias tabelas. Não há como a pequena vantagem de saber que isso é o PK supera o incrível aborrecimento de alterar o alias da coluna dang ID em todas as consultas sangrentas repetidas vezes. Se você quiser uma maneira de denotar PK em uma tabela, torne-a na primeira coluna. Além disso, denotar FKs nos nomes das colunas é, na minha opinião, outro anti-padrão solidamente mau.
ErikE 02/02
2
Dê uma olhada nesta resposta .
PerformanceDBA

Respostas:

315

Eu recomendo verificar os bancos de dados de exemplo do SQL Server da Microsoft: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

O exemplo AdventureWorks usa uma convenção de nomenclatura muito clara e consistente que usa nomes de esquema para a organização de objetos de banco de dados.

  1. Nomes singulares para tabelas
  2. Nomes singulares para colunas
  3. Nome do esquema para o prefixo de tabelas (por exemplo: SchemeName.TableName)
  4. Caixa em Pascal (também conhecida como caixa superior de camelo)
urini
fonte
14
wilsonmar.com/sql_adventureworks.htm é uma excelente análise do esquema AdventureWorks.
precisa saber é o seguinte
209
Eu não confiaria na Microsoft para nenhum padrão - se você olhar para o banco de dados northwind, verá que eles usam Tabelas Plurais, Nomes de Colunas Singulares, Prefixos de Esquema para Tabelas, Prefixos de Tabela para Colunas de Chave Primária, Prefixos de Restrições no Estilo Húngaro e o pior de todos os ESPAÇOS "" para nomes de tabelas com várias palavras. Além disso, as tabelas de sistema do SQLServer usam plurais, pelo que parece que o AdventureWorks era a ovelha negra nesse grupo.
Marcus Papa
63
Penso que a questão principal aqui é que a multidão de nomes de tabelas Singulares parece considerar a tabela como a entidade, e não a linha na tabela que a multidão de Plural faz. Você tem que se perguntar qual é. Se a tabela é apenas um contêiner de linhas, não é mais lógico usar a nomeação plural? Você nunca nomearia uma coleção no código singular; por que nomearia a tabela singular? Por que a inconsistência? Eu ouço todos os argumentos sobre como eles classificam e usam em junções, mas todos parecem argumentos muito frágeis. Se tudo se resume à preferência, irei com a consistência e pluralizar.
Jason
4
Considere também em qual direção a maré está indo. Parece que ele está indo na direção de nomes de tabelas plurais, especialmente porque todas as tabelas do sistema no SQL Server são plurais, e o padrão para o Entity Framework é plurificado. Se essa é a posição da Microsoft, quero ir na direção em que estaremos em 20 anos. Até as convenções de banco de dados da Oracle dizem nomes de tabelas plurais. Basta pensar quantos desenvolvedores de c # odiavam a palavra-chave "var" quando ela foi introduzida, agora é a maneira amplamente aceita de definir variáveis.
Jason
7
@ Jasmine - Eu vejo o seu ponto de vista, embora eu ache que você inadvertidamente nomeou sua tabela de exemplo para trás. "TableOfInvoices" deve ser abreviado para "Invoices", que é o que eu prefiro. Você provavelmente quis dizer "InvoiceTable", o que faz sentido abreviar "Invoice".
Derek
280

Resposta tardia aqui, mas em resumo:

  1. Minha preferência é plural
  2. sim
  3. Tabelas : * Normalmente * não há prefixos melhores. Colunas : Não.
  4. Tabelas e colunas: PascalCase.

Elaboração:

(1) O que você deve fazer. Há muito poucas coisas que você deve fazer de uma certa maneira, todas as vezes, mas há algumas.

  • Nomeie suas chaves primárias usando o formato "[singularOfTableName] ID". Ou seja, se o nome da sua tabela é Cliente ou Customers , a chave primária deve ser CustomerID .
  • Além disso, chaves estrangeiras devem ser nomeadas consistentemente em tabelas diferentes. Deve ser legal espancar alguém que não faz isso. Eu diria que, embora as restrições de chave estrangeira definidas sejam frequentemente importantes, a nomeação consistente de chave estrangeira é sempre importante
  • Seu banco de dados deve ter convenções internas . Embora nas seções posteriores você me veja sendo muito flexível, em uma nomeação de banco de dados deve ser muito consistente. Se sua tabela para clientes é chamada de Clientes ou Cliente é menos importante do que você faz da mesma maneira no mesmo banco de dados. E você pode jogar uma moeda para determinar como usar sublinhados, mas deve continuar usando-os da mesma maneira . Se você não fizer isso, é uma pessoa ruim e deve ter baixa auto-estima.

2) O que você provavelmente deve fazer.

  • Campos representando o mesmo tipo de dados em tabelas diferentes devem ter o mesmo nome. Não tem Zip em uma tabela e ZipCode em outra.
  • Para separar palavras nos nomes de suas tabelas ou colunas, use PascalCasing. Usar camelCasing não seria intrinsecamente problemático, mas essa não é a convenção e seria engraçado. Vou abordar sublinhados em um momento. (Você não pode usar ALLCAPS como antigamente. OBNOXIOUSTABLE.ANNOYING_COLUMN estava bem no DB2 há 20 anos, mas não agora.)
  • Não reduza ou abrevie artificialmente as palavras. É melhor que um nome seja longo e claro do que curto e confuso. Nomes ultra-curtos são um resquício de tempos mais sombrios e selvagens. Cus_AddRef. O que raios é aquilo? Referência do Destinatário da Custódia? Reembolso adicional do cliente? Referência de endereço personalizado?

(3) O que você deve considerar.

  • Eu realmente acho que você deveria ter nomes plurais para tabelas; alguns pensam singular. Leia os argumentos em outro lugar. Os nomes das colunas devem ser singulares, no entanto. Mesmo se você usar nomes de tabelas plurais, as tabelas que representam combinações de outras tabelas podem estar no singular. Por exemplo, se você tiver uma tabela Promoções e Itens , uma tabela que representa um item que faz parte de uma promoção pode ser Promotions_Items, mas também pode legitimamente ser Promotion_Items, eu acho (refletindo o relacionamento um para muitos).
  • Use sublinhados de forma consistente e para uma finalidade específica. Apenas nomes de tabelas gerais devem ser claros o suficiente com PascalCasing; você não precisa de sublinhados para separar as palavras. Salve os sublinhados (a) para indicar uma tabela associativa ou (b) para prefixar, que abordarei no próximo marcador.
  • Prefixar não é bom nem ruim. Ele normalmente não é o melhor. Nos seus primeiros dois bancos de dados, eu não sugeriria o uso de prefixos para o agrupamento temático geral de tabelas. As tabelas acabam não se ajustando facilmente às suas categorias e pode realmente tornar mais difícil encontrar tabelas. Com a experiência, você pode planejar e aplicar um esquema de prefixo que faz mais bem do que mal. Eu trabalhei em um banco de dados uma vez em que as tabelas de dados começaram com tbl , tabelas de configuração com ctbl , visualizações com vew , sp do proc e fn do udfe alguns outros; foi meticulosamente aplicado de maneira consistente e funcionou bem. A única vez que você PRECISA de prefixos é quando você realmente tem soluções separadas que, por algum motivo, residem no mesmo banco de dados; prefixá-los pode ser muito útil para agrupar as tabelas. A prefixação também é válida para situações especiais, como para tabelas temporárias que você deseja destacar.
  • Muito raramente (se alguma vez) você gostaria de prefixar colunas.
Patrick Karcher
fonte
11
"Os campos que representam o mesmo tipo de dados em tabelas diferentes devem ter o mesmo nome. Não há Zip em uma tabela e ZipCode em outra." Sim sim um milhão de vezes sim. Você pode dizer que nosso banco de dados não foi projetado dessa maneira? Um personid pode ser referido de várias maneiras diferentes, muito chato de manter. Eu sempre mantive essa regra em qualquer banco de dados que eu tinha controle sobre o design e isso torna a vida muito mais simples.
HLGEM 26/03/10
87
Eu acho que a chave primária deve ser apenas "ID". Uma convenção tão simples torna a chave primária previsível e rapidamente identificável. No entanto, prefiro o nome da tabela ("PersonID") quando usado como chave estrangeira em outras tabelas. Essa convenção pode ajudar a distinguir entre uma chave primária e chaves estrangeiras na mesma tabela.
Triynko
55
@Tryinko Usar ID em todo o lugar é LIVING HELL para quem faz junções de várias tabelas. Não há nenhuma maneira possível de que a pequena vantagem de saber isso seja a PK supera a incrível irritação de alterar o nome da coluna dang ID em todas as consultas sangrentas repetidas vezes. Se você quiser uma maneira de denotar PK em uma tabela, torne-a na primeira coluna. Além disso, denotar FKs nos nomes das colunas é, na minha opinião, outro anti-padrão solidamente mau.
ErikE
18
@Triynko, se você usar apenas "ID", também será programaticamente impossível determinar a tabela a que pertence. Com o prefixo do nome da tabela, você pode simplesmente cortar os dois últimos dígitos de uma chave primária e saber o nome da tabela à qual ela pertence via código. Muitas vezes, as pessoas de TI e DBA não percebem que existem vantagens de codificação para os programadores no design de bancos de dados de determinadas maneiras.
dallin
16
@ErikE Quero dizer que você não sabe se CustomerIDé a chave primária da Customertabela ou uma chave estrangeira em outra tabela. É uma questão menor. Por que você gostaria de usar nomes ruins como c? CustomerID = Customer.IDé muito claro que você vê que está ingressando em uma chave estrangeira com uma chave primária; não é redundante, pois os dois lados são duas coisas diferentes. A nomeação de caracteres únicos é uma prática ruim do IMO.
Dave Cousineau 02/02
100

Ok, já que estamos avaliando a opinião:

Eu acredito que os nomes das tabelas devem ser plurais. As tabelas são uma coleção (uma tabela) de entidades. Cada linha representa uma única entidade e a tabela representa a coleção. Então, eu chamaria uma tabela de entidades Pessoa de Pessoas (ou Pessoas, o que for necessário).

Para aqueles que gostam de ver "nomes de entidades" singulares em consultas, é para isso que eu usaria aliases de tabela:

SELECT person.Name
FROM People person

Um pouco como os LINQs "de pessoa em pessoa, selecione person.Name".

Quanto a 2, 3 e 4, concordo com o @Lars.

Matt Hamilton
fonte
17
@Emtucifor: Em inglês, não dizemos "Olhe para toda a pessoa lá fora naquela multidão de pessoas!" É de se esperar um problema conceitual com coisas que são múltiplas, referidas por uma palavra singular. Não é usual nem apropriado. "Dados" é excepcional e costuma ser usado para se referir a um pedaço de um volume de substância, bem como "bolo". "Gostaria de um pedaço de bolo?" Nomear uma tabela como "Pessoas" porque contém informações sobre vários indivíduos faz muito mais sentido do que nomeá-la "Pessoa". Uma classe de dados denominada "Pessoa" para a ROW faz sentido, assim como nomes de colunas singulares.
Triynko
6
@Emtucifor: Em última análise, toda linguagem é arbitrária e convencional. Eu estava apenas argumentando que convencionalmente nos referimos a uma coleção de itens como o plural do tipo de item nela. Portanto, uma coleção de linhas em que cada linha tem informações sobre uma única pessoa seria referida como uma coleção de Pessoas. Mas se você quiser se referir a ele como uma coleção de Pessoa, vá em frente.
Triynko
3
@Emtucifor: Sim, lol. Nomear a tabela "PersonCollection" seria equivalente a nomear "Pessoas". Contraste isso com nomear tais coleção um pouco "Pessoa", que não faz sentido :)
Triynko
4
@Emtucifor: Vamos pensar de outro ângulo para colocar a convenção de nomenclatura em um contexto. Suponha que você tenha classes de objetos para representar a linha e a tabela. "Pessoa" obviamente faz sentido para a classe que representa uma linha de dados. Se a sua mesa também foi denominada "Pessoa", você pode ter um conflito de nomes ou alguma confusão. Apenas acho que faz mais sentido nomear objetos com pluralidade precisa. A linha com dados sobre uma pessoa deve ser chamado Pessoa, e uma tabela com informações sobre pessoas ou várias pessoas é chamado de Pessoas, PersonCollection, pessoas, etc.
Triynko
5
@ Josh M. Bem, de nenhuma maneira você vai. Se você seguir o meu caminho, poderá usar o alias da tabela People como "person" e selecionar SELECT person.Name. Problema resolvido. ;-)
Matt Hamilton
73

Eu trabalho em uma equipe de suporte de banco de dados com três DBAs e nossas opções consideradas são:

  1. Qualquer padrão de nomenclatura é melhor que nenhum padrão.
  2. Não existe um "padrão verdadeiro", todos temos nossas preferências
  3. Se já houver um padrão no local, use-o. Não crie outro padrão ou torne confuso os padrões existentes.

Usamos nomes singulares para tabelas. As tabelas tendem a ser prefixadas com o nome do sistema (ou seu acrônimo). Isso é útil se o sistema complexo, pois você pode alterar o prefixo para agrupar as tabelas logicamente (por exemplo, reg_customer, reg_booking e regadmin_limits).

Para os campos, esperamos que os nomes dos campos incluam o prefixo / acrônimo da tabela (ou seja, cust_address1) e também preferimos o uso de um conjunto padrão de sufixos (_id para o PK, _cd para "code", _nm para "name ", _nb para" número ", _dt para" Data ").

O nome do campo da chave estrangeira deve ser o mesmo que o campo da chave primária.

ie

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Ao desenvolver um novo projeto, recomendo que você escreva todos os nomes, prefixos e acrônimos de entidades preferenciais e forneça este documento aos seus desenvolvedores. Então, quando eles decidem criar uma nova tabela, eles podem se referir ao documento em vez de "adivinhar" como a tabela e os campos devem ser chamados.

Cara
fonte
9
Especialmente para o número 3, tínhamos um grupo de pessoas que foram contratadas na mesma empresa e elas tentaram impor seu antigo padrão de nomes (que nenhum de nós usava) em tudo o que faziam. Muito irritante.
HLGEM
40
Certamente torna o SQL ilegível; mas acho que posso traduzir. cust_nm deve ser CustomerName , booking_dt deve ser BookingDate . reg_customer, bem, eu não tenho idéia do que é isso.
Ian Boyd
3
@Ian. A intenção é que você se atenha à convenção de nomes a que está acostumado e mantenha-a consistente. SEMPRE sei que qualquer campo de data é _dt, qualquer campo de nome é _nm. 'reg' é um exemplo de sistema de "registro" (reservas, clientes etc.) e todas as tabelas relacionadas teriam o mesmo prefixo. Mas cada um por sua própria ...
Guy
7
Concordo que um padrão específico não é tão importante quanto ter um padrão consistente. Mas alguns padrões estão errados. Nomes de colunas e DB2 como CSPTCN, CSPTLN, CSPTMN, CSDLN. As pessoas devem aprender que nomes longos foram inventados - podemos dar ao luxo de tornar as coisas legíveis.
Ian Boyd
17
Ao longo dos anos, adicionei novas colunas no final de minhas tabelas no aplicativo que desenvolvi e comercializei. Às vezes, uso nomes em inglês em minhas colunas, às vezes uso espanhol e às vezes reutilizo colunas para outra coisa, em vez de excluí-las e adicionar uma nova coluna com um nome descritivo adequado para o que é usado. Eu propositadamente fiz isso para obfuscar meu código-fonte, caso alguém tente invadir ou fazer engenharia reversa do meu código. Só eu posso entender, alguém ficará frustrado! .. Dessa forma, eles sempre precisam confiar em mim para qualquer coisa!
Frank R.
47
  1. Não. Uma tabela deve ser nomeada após a entidade que representa. Pessoa, não pessoas, é como você se referiria a quem representa um dos registros.
  2. Mais uma vez, a mesma coisa. A coluna FirstName realmente não deve ser chamada FirstNames. Tudo depende do que você deseja representar com a coluna.
  3. NÃO.
  4. Sim. Caso por clareza. Se você precisar ter colunas como "Nome", a caixa facilitará a leitura.

Está bem. Thats my $ 0.02

Lars Mæhlum
fonte
5
Adicionar clareza ao número 3 - prefixos é uma maneira de incorporar metadados ao nome da coluna. Não deve haver necessidade de fazer isso em nenhum banco de dados moderno pelos mesmos motivos que (uso excessivo) da notação húngara.
MarkDonald4
21
`selecionar 15 melhores do pedido 'ou' selecionar 15 dos pedidos '? O último é a minha preferência (humana).
Ian Boyd
8
@Ian Boyd: Sim: SELECIONE OS 100 MELHORES DO RELATÓRIO INTRODUÇÃO VisitReport VR ON R.ReportID = VR.ReportID. Tudo depende de como você pensa sobre isso. Se você colocar uma foto de limão em uma vasilha, saberia que havia limões dentro, sem precisar de dois limões na parte externa para indicar que poderia ser plural. Claro, você pode rotulá-lo com a palavra escrita "limões". Mas pode muito bem ser "limão". Para adquirir o recurso chamado "limão", clique aqui.
ErikE
6
adicione US $ 0,01 pelo uso do UpperCase nos nomes das colunas e adicione outro US $ 0,01 pelo uso do sublinhado nos nomes das colunas, para facilitar a distinção dos nomes das colunas à vista. Total = Minha doação de US $ 0,02 para você!
Frank R.
6
"Uma tabela deve ter o nome da entidade que representa" Uma tabela é uma coleção de entidades. Enquanto uma tabela também é uma entidade, é uma entidade do tipo "Tabela" que não faz sentido adicionar ao seu nome.
Trisped
34

Também sou a favor de uma convenção de nomenclatura no estilo ISO / IEC 11179, observando que elas são diretrizes e não prescritivas.

Consulte Nome do elemento de dados na Wikipedia :

"As tabelas são coleções de entidades e seguem as diretrizes de nomenclatura das coleções. Idealmente, um nome coletivo é usado: por exemplo, pessoal. O plural também está correto: funcionários. Os nomes incorretos incluem: funcionário, tblEmployee e EmployeeTable."

Como sempre, há exceções às regras, por exemplo, uma tabela que sempre possui exatamente uma linha pode ser melhor com um nome singular, como uma tabela de configuração. E a consistência é de extrema importância: verifique se você compra uma convenção e, se houver, siga-a; se você não gostar, faça um caso de negócios para que ele seja alterado, em vez de ser o único patrulheiro.

um dia quando
fonte
-1: o texto referenciado não tem nada a ver com a ISO / IEC 11179. A página da Wikipédia referenciada não deve ser confiável; leia o padrão real em vez ( metadata-standards.org/11179/#A5 )
mkadunc
@ onedaywhen: não sei o suficiente sobre o assunto para corrigir a página da Wikipedia; Além disso, a página da Wikipedia não é tão errada quanto enganosa - não diz explicitamente que a ISO / IEC 11179 inclui as convenções de nomenclatura de banco de dados, apenas diz que "ISO / IEC 11179 é aplicável ao nomear tabelas e colunas dentro de um banco de dados relacional ". Em seguida, ele fornece um exemplo de convenções de nomenclatura que podem ser usadas para banco de dados relacional. Isso permite que você pense que o exemplo é algo retirado do padrão, quando na verdade é algo inventado pelo autor do artigo da wikipedia.
Mkadunc
27

Eu ouço o argumento o tempo todo de que a pluralização ou não de uma mesa é uma questão de gosto pessoal e não há práticas recomendadas. Eu não acredito que isso seja verdade, especialmente como programador em oposição a um DBA. Tanto quanto sei, não há motivos legítimos para pluralizar um nome de tabela além de "Isso só faz sentido para mim porque é uma coleção de objetos", enquanto há ganhos legítimos no código por ter nomes de tabelas singulares. Por exemplo:

  1. Evita bugs e erros causados ​​por ambiguidades plurais. Os programadores não são exatamente conhecidos por sua experiência em ortografia, e a pluralização de algumas palavras é confusa. Por exemplo, a palavra plural termina em 'es' ou apenas 's'? São pessoas ou pessoas? Quando você trabalha em um projeto com grandes equipes, isso pode se tornar um problema. Por exemplo, uma instância em que um membro da equipe usa o método incorreto para pluralizar uma tabela que ele cria. No momento em que interajo com essa tabela, ela é usada em todo o código ao qual não tenho acesso ou levaria muito tempo para corrigir. O resultado é que devo me lembrar de escrever a tabela incorretamente toda vez que a uso. Algo muito parecido com isso aconteceu comigo. Quanto mais fácil você facilitar a utilização consistente e fácil de todos os membros da equipe, corrija nomes de tabelas sem erros ou tenha que procurar nomes de tabelas o tempo todo, melhor. A versão singular é muito mais fácil de manusear em um ambiente de equipe.

  2. Se você usa a versão singular de um nome de tabela E prefixa a chave primária com o nome da tabela, agora você tem a vantagem de determinar facilmente um nome de tabela a partir de uma chave primária ou vice-versa apenas por código. Você pode receber uma variável com um nome de tabela, concatenar "Id" até o final, e agora você tem a chave primária da tabela via código, sem precisar fazer uma consulta adicional. Ou você pode cortar "Id" no final de uma chave primária para determinar o nome de uma tabela por código. Se você usar "id" sem um nome de tabela para a chave primária, não poderá, via código, determinar o nome da tabela a partir da chave primária. Além disso, a maioria das pessoas que pluraliza nomes de tabelas e prefixa colunas PK com o nome da tabela usa a versão singular do nome da tabela na PK (por exemplo, status e status_id),

  3. Se você tornar os nomes das tabelas singulares, faça com que eles correspondam aos nomes de classe que eles representam. Mais uma vez, isso pode simplificar o código e permitir que você faça coisas realmente legais, como instanciar uma classe, tendo apenas o nome da tabela. Isso também torna seu código mais consistente, o que leva a ...

  4. Se você tornar o nome da tabela singular, ele tornará seu esquema de nomeação consistente, organizado e fácil de manter em todos os locais. Você sabe que em todas as instâncias do seu código, seja no nome de uma coluna, no nome da classe ou no nome da tabela, é o mesmo nome exato. Isso permite fazer pesquisas globais para ver em todos os lugares que os dados são usados. Quando você pluraliza um nome de tabela, haverá casos em que você usará a versão singular desse nome de tabela (a classe na qual ele se transforma, na chave primária). Apenas faz sentido não ter algumas instâncias em que seus dados são referidos como plural e algumas instâncias, singular.

Para resumir, se você pluralizar os nomes de suas tabelas, estará perdendo todo tipo de vantagens ao tornar seu código mais inteligente e fácil de manusear. Pode até haver casos em que você precise ter tabelas / matrizes de pesquisa para converter os nomes das tabelas em objetos ou nomes de códigos locais que você poderia ter evitado. Os nomes de tabelas singulares, embora pareçam um pouco estranhos a princípio, oferecem vantagens significativas sobre nomes pluralizados e acredito que sejam as melhores práticas.

Dallas
fonte
26

nossa preferência:

  1. Os nomes das tabelas devem ser plurais?
    Nunca. Os argumentos para ser uma coleção fazem sentido, mas você nunca sabe o que a tabela conterá (0,1 ou muitos itens). Regras plurais tornam a nomeação desnecessariamente complicada. 1 casa, 2 casas, rato x rato, pessoa x pessoa, e nem sequer vimos outras línguas.

    Update person set property = 'value'atua sobre cada pessoa na mesa.
    Select * from person where person.name = 'Greg'retorna uma coleção / conjunto de linhas de linhas pessoais.

  2. Os nomes das colunas devem ser singulares?
    Normalmente, sim, exceto onde você está violando as regras de normalização.

  3. Devo prefixar tabelas ou colunas?
    Principalmente uma preferência de plataforma. Preferimos prefixar colunas com o nome da tabela. Não prefixamos tabelas, mas fazemos visualizações de prefixos (v_) e stored_procedures (sp_ ou f_ (function)). Isso ajuda as pessoas que desejam tentar atualizar v_person.age, que na verdade é um campo calculado em uma exibição (que não pode ser UPDATEd de qualquer maneira).

    Também é uma ótima maneira de evitar a colisão de palavras-chave (delivery.from breaks, mas delivery_from não).

    Isso torna o código mais detalhado, mas geralmente ajuda na legibilidade.

    bob = new person()
    bob.person_name = 'Bob'
    bob.person_dob = '1958-12-21'
    ... é muito legível e explícito. Isso pode ficar fora de controle:

    customer.customer_customer_type_id

    indica um relacionamento entre o cliente e a tabela customer_type, indica a chave primária na tabela customer_type (customer_type_id) e se você vir 'customer_customer_type_id' durante a depuração de uma consulta, saberá instantaneamente de onde é (tabela do cliente).

    ou onde você tem um relacionamento MM entre customer_type e customer_category (somente determinados tipos estão disponíveis para determinadas categorias)

    customer_category_customer_type_id

    ... está um pouco (!) do lado comprido.

  4. Devo usar algum caso para nomear itens? Sim - minúsculas :), com sublinhados. Estes são muito legíveis e multiplataforma. Juntamente com os 3 acima, também faz sentido.

    A maioria delas são preferências. - Desde que você seja consistente, deve ser previsível para quem precisar lê-lo.

Albert
fonte
1
SELECT * FROM people AS person WHERE person.name = 'Greg'parece o mais natural para mim.
Kenmore
1
@Zuko Principalmente, a convenção de nomenclatura para a chave primária da tabela é <table name><id>, por exemplo PersonIDou Person_IDetc. Portanto, faz mais sentido que você NÃO nomeie suas tabelas no plural, pois cada registro é uma pessoa separada e não uma pessoa.
Mr. Blond
15

Sei que está atrasado para o jogo e a pergunta já foi respondida muito bem, mas quero oferecer minha opinião sobre o # 3 sobre o prefixo dos nomes das colunas.

Todas as colunas devem ser nomeadas com um prefixo exclusivo da tabela em que estão definidas.

Por exemplo, dadas as tabelas "cliente" e "endereço", vamos usar os prefixos "cust" e "addr", respectivamente. "customer" teria "cust_id", "cust_name" etc. etc. "address" teria "addr_id", "addr_cust_id" (retorno do cliente ao FK), "addr_street" etc. etc.

Quando fui apresentado a esse padrão pela primeira vez, eu estava contra ele; Eu odiava a ideia. Eu não suportava a idéia de toda essa digitação e redundância extras. Agora, já tive experiência suficiente para nunca mais voltar.

O resultado disso é que todas as colunas no esquema do banco de dados são exclusivas. Há um grande benefício nisso, que supera todos os argumentos contra ele (na minha opinião, é claro):

Você pode pesquisar toda a sua base de códigos e encontrar com segurança todas as linhas de código que tocam uma coluna específica.

O benefício do nº 1 é incrivelmente grande. Posso descontinuar uma coluna e saber exatamente quais arquivos precisam ser atualizados antes que a coluna possa ser removida com segurança do esquema. Posso alterar o significado de uma coluna e saber exatamente qual código precisa ser refatorado. Ou posso simplesmente dizer se os dados de uma coluna estão sendo usados ​​em uma parte específica do sistema. Não posso contar o número de vezes que isso transformou um projeto potencialmente grande em um projeto simples, nem a quantidade de horas que economizamos no trabalho de desenvolvimento.

Outro benefício relativamente menor é que você só precisa usar aliases de tabela quando faz uma associação automática:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';
Granger
fonte
1
Então você não pode mais reliably find every line of code that touches a particular column... Não é esse o ponto?
raveren
6
@ Raveren - Você ainda pode. Se tudo o que você faz é "SELECT *", a consulta é irrelevante para essa finalidade. Quando / Se posteriormente, você usar os resultados dessa consulta, precisará usar o nome da coluna para fazer algo com seus dados, para que este seja o local em que você precisa se preocupar em seu código, não na instrução SQL.
precisa
Gostaria de saber quais situações exigem SELECT *? Eu certamente não gostaria que alguém usasse isso no código de produção. Sim, é útil para consultas ad hoc e para descobrir quais dados estão fazendo com que seus vários resultados de consulta de junção sejam ímpares, mas não consigo pensar em nenhum lugar no código de produção onde é necessário.
HLGEM
2
A menos que você esteja codificando todo o aplicativo em uma linguagem não OO, ter uma camada ORM decente torna esse argumento redundante.
Adam
6
Portanto, devido a essa resposta, decidi tentar usar prefixos de tabela em um projeto grande e pensei em apresentar um relatório. Tornou as tabelas de refatoração extremamente fáceis, o que foi incrível! No entanto, foi uma dor maior do que eu previa. Nosso banco de dados tinha muitas tabelas nomeadas complexas. É fácil lembrar que Cust é o prefixo do Cliente, mas não é tão fácil lembrar o prefixo de HazardVerificationMethod. Toda vez que escrevi uma tabela ou campo, tive que fazer uma pausa para pensar no prefixo. No final, decidi que velocidade e conveniência eram mais importantes que a capacidade de busca, mas achei que era uma experiência valiosa.
dallin 12/0318
15

Minhas opiniões são:

1) Não, os nomes das tabelas devem ser singulares.

Embora pareça fazer sentido para a seleção simples ( select * from Orders), faz menos sentido para o equivalente OO ( Orders x = new Orders).

Uma tabela em um banco de dados é realmente o conjunto dessa entidade; faz mais sentido quando você usa a lógica de conjunto:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Essa última linha, a lógica real da junção, parece confusa com nomes de tabelas plurais.

Não tenho certeza de sempre usar um alias (como Matt sugere) esclarece isso.

2) Eles devem ser singulares, pois possuem apenas 1 propriedade

3) Nunca, se o nome da coluna for ambíguo (como acima, onde ambos têm uma coluna chamada [Key]), o nome da tabela (ou seu apelido) pode distingui-los suficientemente bem. Você deseja que as consultas sejam rápidas de digitar e simples - prefixos adicionam complexidade desnecessária.

4) O que você quiser, sugiro CapitalCase

Não acho que exista um conjunto de diretrizes absolutas em nenhuma delas.

Desde que o que você escolher seja consistente no aplicativo ou no banco de dados, não acho que isso realmente importe.

Keith
fonte
3
O que diabos é CapitalCase?
ViRuSTriNiY
@ViRuSTriNiTy ele provavelmente quis dizerpascal case
marctrem
Keith, no número # 3, faço as duas coisas e sou inconsistente (mas discordo), mas não entendo por que é ruim ter um nome de coluna descritivo, desde que não exagere, mesmo com uma tabela, um variável, etc.
johnny
@ johnny não é ruim, como tal, apenas não é necessário. Por que digitar coisas que você não precisa? Também a maioria intellisense utiliza principalmente o início do nome, por isso, se você tem Product.ProductName, Product.ProductID, Product.ProductPriceetc digitação Product.Pdá-lhe todos os campos prefixados.
Keith
13

Na minha opinião:

  1. Os nomes das tabelas devem ser plurais.
  2. Os nomes das colunas devem ser singulares.
  3. Não.
  4. CamelCase (meu preferido) ou underscore_separated para nomes de tabelas e nomes de colunas.

No entanto, como já foi mencionado, qualquer convenção é melhor do que nenhuma convenção. Não importa como você escolha fazê-lo, documente-o para que futuras modificações sigam as mesmas convenções.

Thomas Owens
fonte
1
sobre # 4, PascalCase ... camelCase ... snake_case ...
Andrew
11

Acho que a melhor resposta para cada uma dessas perguntas seria dada por você e sua equipe. É muito mais importante ter uma convenção de nomenclatura do que exatamente a convenção de nomenclatura é.

Como não há resposta certa para isso, você deve levar algum tempo (mas não muito) e escolher suas próprias convenções e - aqui está a parte importante - cumpri-lo.

É claro que é bom procurar informações sobre padrões sobre isso, que é o que você está perguntando, mas não fique ansioso ou preocupado com o número de respostas diferentes que você pode obter: escolha a que lhe parecer melhor.

Apenas no caso, aqui estão minhas respostas:

  1. Sim. Uma tabela é um grupo de registros , professores ou atores , tão ... plural.
  2. Sim.
  3. Eu não os uso.
  4. O banco de dados que eu uso com mais freqüência - Firebird - mantém tudo em maiúsculas, portanto não importa. De qualquer forma, quando estou programando, escrevo os nomes de uma maneira que seja mais fácil de ler, como releaseYear .
Mario Marinato
fonte
11
  1. Definitivamente mantenha os nomes das tabelas singulares, pessoa e não pessoas
    1. O mesmo aqui
    2. Não. Eu já vi alguns prefixos terríveis, chegando ao ponto de declarar que estávamos lidando com uma tabela (tbl_) ou um procedimento de armazenamento de usuário (usp_). Isto seguido pelo nome do banco de dados ... Não faça isso!
    3. Sim. Tendo a PascalCase todos os meus nomes de tabela
Sino
fonte
28
AMD. NÃO. Nomes das tabelas DEFINITIVAMENTE plural. É uma COLEÇÃO. Tem várias coisas nele. "selecione * de PESSOAS". Você não está selecionando entre uma única pessoa, está selecionando entre várias pessoas!
Triynko
4
Eu sempre gostei da maneira como a instrução select soa melhor se for plural. SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'tabelas no plural, colunas no singular. Novamente sempre uma questão de opinião pessoal.
Scunliffe
prefixar tbl, qry etc pode ser extremamente útil ao lidar com metadados do banco de dados. Se você estiver examinando o objeto em um banco de dados com uma convenção de nomenclatura rápida e simples, pode acelerar drasticamente a compreensão.
Cruachan
9

As convenções de nomenclatura permitem que a equipe de desenvolvimento projete a capacidade de descoberta e manutenção no centro do projeto.

Uma boa convenção de nomenclatura leva tempo para evoluir, mas uma vez implementada, permite que a equipe avance com um idioma comum. Uma boa convenção de nomenclatura cresce organicamente com o projeto. Uma boa convenção de nomenclatura lida facilmente com as mudanças durante a fase mais longa e mais importante do ciclo de vida do software - gerenciamento de serviços em produção.

Aqui estão as minhas respostas:

  1. Sim, os nomes das tabelas devem ser plurais quando se referem a um conjunto de negociações , valores mobiliários ou contrapartes, por exemplo.
  2. Sim.
  3. Sim. As tabelas SQL são prefixadas com tb_, as visualizações são prefixadas vw_, os procedimentos armazenados são prefixados usp_ e os gatilhos são prefixados tg_ seguidos pelo nome do banco de dados.
  4. O nome da coluna deve estar em minúsculas, separado por sublinhado.

A nomeação é difícil, mas em toda organização existe alguém que pode nomear coisas e em toda equipe de software deve haver alguém que se responsabilize pelos padrões de nomeação e garanta que os nomes sejam sec_id , sec_value e security_id sejam resolvidos mais cedo antes de serem inseridos no projeto .

Então, quais são os princípios básicos de uma boa convenção e padrões de nomenclatura:

  • Use o idioma do seu cliente e o domínio da sua solução
  • Seja descritivo
  • Ser consistente
  • Desambiguar, refletir e refatorar
  • Não use abreviações, a menos que sejam claras para todos
  • Não use palavras-chave reservadas SQL como nomes de colunas
winsql
fonte
3
tabelas são por definição relações. que são de fato singulares. prefixos sugam. Você já precisou mudar uma tabela para uma visão ou vice-versa? tente isso com prefixos. que diferença faz se é uma visão ou uma tabela?
21717 William
O prefixo pode ajudar onde temos o mesmo nome para dois objetos - como função e procedimento armazenado. Eu teria uma função com o nome 'GetApproverList' e, com o mesmo nome, gostaria de criar um procedimento armazenado que chamará essa função internamente. Sql não permitirá a criação de dois objetos com o mesmo nome.
Ravinder Singh
9

Aqui está um link que oferece algumas opções. Eu estava procurando por uma especificação simples que eu pudesse seguir, em vez de ter que confiar em uma especificação parcialmente definida.

http://justinsomnia.org/writings/naming_conventions.html

Chris
fonte
7
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName
Ian Boyd
fonte
2
Observe os padrões utilizados: as tabelas contêm várias coisas, os usuários têm um primeiro nome, as palavras-chave T-SQL em maiúsculas, as definições de tabela no caso Pascal.
Ian Boyd
3
erro de digitação: Lastnameshould beLastName
aminimalanimal
1
O nome da tabela deve ser singular, ou seja: Usuário em vez de Usuários
AZ_
E observe como os nomes das tabelas são plurais; enquanto eles mantêm Usuários , não Usuário .
Ian Boyd
5

Os nomes das tabelas devem sempre ser singulares, porque representam um conjunto de objetos. Como você diz, o rebanho para designar um grupo de ovelhas, ou o rebanho designa um grupo de pássaros. Não há necessidade de plural. Quando um nome de tabela é composto por dois nomes e a convenção de nomenclatura é plural, torna-se difícil saber se o nome plural deve ser a primeira palavra ou a segunda palavra ou ambas. É a lógica - Object.instance, não objects.instance. Ou TableName.column, não TableNames.column (s). O Microsoft SQL não diferencia maiúsculas de minúsculas, é mais fácil ler os nomes das tabelas, se forem usadas letras maiúsculas, para separar os nomes de tabelas ou colunas quando elas são compostas por dois ou mais nomes.

Annie
fonte
2
Um rebanho é um grupo de ovelhas . A nãoUser é um grupo de usuários.
11117 Eric ClobertBrewer
4

Nome da tabela: deve ser singular, pois é uma entidade singular que representa um objeto do mundo real e não objetos, que é singular.

Nome da coluna: Deve ser singular apenas para transmitir que manterá um valor atômico e confirmará a teoria da normalização. Se, no entanto, houver n número do mesmo tipo de propriedades, elas deverão ser sufixadas com 1, 2, ..., n, etc.

Prefixando tabelas / colunas: é um tópico enorme, que será discutido mais adiante.

Invólucro: deve ser o caso Camel

Meu amigo, Patrick Karcher , peço que você não escreva nada que possa ser ofensivo para alguém, como você escreveu: "• Além disso, as chaves estrangeiras devem ser nomeadas consistentemente em tabelas diferentes. Deve ser legal espancar alguém que não faça isso.". Nunca cometi esse erro, meu amigo Patrick, mas estou escrevendo em geral. E se eles planejarem vencê-lo por isso? :)

vishesh marwah
fonte
2
Então você está dizendo que a tabela é a entidade? Ou a linha na tabela é a entidade? Para mim, uma tabela é uma coleção de linhas - portanto, uma coleção de entidades que implica plural.
Jason
4

Muito tarde para a festa, mas eu ainda queria adicionar meus dois centavos sobre prefixos de coluna

Parece haver dois argumentos principais para o uso do padrão de nomeação table_column (ou tableColumn) para colunas, ambos com base no fato de que o nome da coluna em si será exclusivo em todo o banco de dados:

1) Você não precisa especificar nomes de tabelas e / ou aliases de coluna em suas consultas o tempo todo

2) Você pode pesquisar facilmente todo o código pelo nome da coluna

Eu acho que os dois argumentos são falhos. A solução para os dois problemas sem usar prefixos é fácil. Aqui está a minha proposta:

Sempre use o nome da tabela no seu SQL. Por exemplo, sempre use table.column em vez de coluna.

Obviamente resolve 2), pois agora você pode procurar table.column em vez de table_column.

Mas eu posso ouvir você gritar, como isso resolve 1)? Era exatamente sobre evitar isso. Sim, era, mas a solução era terrivelmente falha. Por quê? Bem, a solução do prefixo se resume a:
Para evitar precisar especificar table.column quando houver ambiguidade, você nomeia todas as suas colunas table_column!
Mas isso significa que, a partir de agora, você sempre terá que escrever o nome da coluna toda vez que especificar uma coluna. Mas se você precisar fazer isso de qualquer maneira, qual é o benefício de sempre escrever explicitamente table.column? Exatamente, não há benefício, é exatamente o mesmo número de caracteres para digitar.

edit: sim, eu sei que nomear as colunas com o prefixo impõe o uso correto, enquanto minha abordagem depende dos programadores

janb
fonte
1
Como você mencionou, não é possível confiar em todos os casos que possuem table.column. Os programadores esquecerão em um só lugar e, em seguida, sua localização e substituição global quebraram todo o programa. Ou você fará uma regra e alguém pensará que está cumprindo a regra usando um alias da tabela, frustrando novamente uma descoberta global. Além disso, se você deseja organizar seu código com algum tipo de classe de banco de dados (que qualquer bom programador fará), haverá momentos em que você passará o nome de uma coluna para uma função db ou apenas o nome da coluna em si. uma variável.
dallin
2
@janb: Apoio totalmente a sua resposta. Também quero acrescentar que o uso da pesquisa de texto para encontrar dependências é uma maneira bárbara de navegar pelo código. Quando as pessoas se livrarem dessa prática de pesquisa bárbara - elas começarão a usar uma boa nomeação, que é table.column. Portanto, o problema não é o estilo de nomeação, o problema são as más ferramentas feitas para os bárbaros.
alpav
Seu argumento é falho. O problema é que ele funciona nos dois sentidos e não adiciona nenhuma vantagem. Você diz que, para resolver isso, sempre escreva table.column, pois você já está escrevendo table_column. Bem, você também pode dizer apenas escreva table_column porque você já está escrevendo table.column. Em outras palavras, não há diferença entre sua resposta, além de apresentar possíveis erros e não aplicar convenções. É por isso que temos uma palavra-chave 'privada'. Poderíamos confiar que os programadores sempre usem variáveis ​​de classe corretamente, mas a palavra-chave a aplica e elimina possíveis erros.
dallin 8/09/2015
3

Convenções essenciais de nomenclatura de banco de dados (e estilo) (clique aqui para obter uma descrição mais detalhada)

os nomes de tabelas escolhem nomes curtos e inequívocos, o uso de no máximo uma ou duas palavras distingue tabelas facilita facilmente a nomeação de nomes de campos únicos, bem como as tabelas de pesquisa e vinculação fornecem nomes únicos às tabelas, nunca no plural (atualização: eu ainda concordo com as razões apresentadas para esta convenção, mas a maioria das pessoas realmente gosta de nomes de tabelas plurais, então suavizei minha postura) ... siga o link acima, por favor

AZ_
fonte
1
embora o que a Oracle sugira seja totalmente oposto ao link do linke acima. encontre o que a Oracle diz aqui .. ss64.com/ora/syntax-naming.html
AZ_
A convenção de nomes da Oracle foi a mais engraçada de todas ... e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
Nawfal
2

Nomes de tabela no singular. Digamos que você estivesse modelando um relacionamento entre alguém e o endereço dele. Por exemplo, se você estiver lendo um modelo de dados, prefere 'cada pessoa pode morar com 0,1 ou muitos endereços'. ou "cada pessoa pode morar em 0,1 ou muitos endereços". Eu acho que é mais fácil pluralizar o endereço do que ter que reformular as pessoas como pessoa. Além disso, os substantivos coletivos são muitas vezes diferentes da versão singular.

paul444
fonte
-4

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Essas são as convenções que aprendi, mas você deve se adaptar ao que quer que use como mangueira de desenvolvimento.

  1. Plural. É uma coleção de entidades.
  2. Sim. O atributo é uma representação da propriedade singular de uma entidade.
  3. Sim, o nome da tabela de prefixo permite a nomeação facilmente rastreável de todos os índices de restrições e alias de tabela.
  4. Pascal Case para nomes de tabelas e colunas, prefixo + ALL caps para índices e restrições.
Senhor Futuro
fonte
6
ChristianName ... é uma convenção estranha.
BobbyShaftoe
3
Números de série em suas mesas? Alguém pensa seriamente que isso faz sentido funciona para os desenvolvedores?
ErikE
Como esse exemplo o trouxe à tona ... Sou pessoalmente contra siglas maiúsculas nos nomes de tabelas ou colunas, pois acho que é mais difícil de ler. Portanto, neste caso, eu diria que StudentId é preferível ao StudentID. Não é grande coisa quando o acrônimo está no final, mas vi inúmeros exemplos no meu trabalho em que os acrônimos estavam na frente ou no meio do nome, e tornou mais difícil analisar sua mente. Ex: StudentABCSSN vs StudentAbcSsn.
precisa saber é o seguinte