database - tabelas - Convenções de nomenclatura de banco de dados, tabela e coluna?




tabela auxiliar banco de dados (16)

Sempre que eu desenho um banco de dados, sempre me pergunto se existe uma maneira melhor de nomear um item no meu banco de dados. Muitas vezes me 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 na nomenclatura de itens?

Há alguma orientação recomendada por aí para nomear itens em um banco de dados?


  1. Definitivamente, mantenha nomes de tabelas no singular, pessoas e não pessoas
    1. O mesmo aqui
    2. Não. Eu vi alguns prefixos terríveis, indo ao ponto de afirmar com o que estamos lidando é uma tabela (tbl_) ou um procedimento de armazenamento de usuário (usp_). Isso é seguido pelo nome do banco de dados ... Não faça isso!
    3. Sim. Eu cuido do PascalCase todos os nomes das minhas tabelas

  1. Não. Uma tabela deve ter o nome da entidade que representa. Pessoa, não pessoas, é como você se referiria a quem quer que um dos registros represente.
  2. Mais uma vez, a mesma coisa. A coluna FirstName realmente não deve ser chamada de FirstNames. Tudo depende do que você deseja representar com a coluna.
  3. NÃO.
  4. Sim. Case para maior clareza. Se você precisar de colunas como "FirstName", a caixa facilitará a leitura.

Está bem. Isso é meu $ 0,02



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 estabelecida, permite que a equipe avance com uma linguagem 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 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 e separado por sublinhado.

A nomeação é difícil, mas em toda organização há alguém que pode nomear as coisas e em qualquer equipe de software deve haver alguém que assuma os padrões de nomenclatura e garanta que os problemas de nomeação como sec_id , sec_value e security_id sejam resolvidos antes que eles entrem no projeto .

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

  • Use o idioma de seu cliente e seu domínio de solução
  • Seja descritivo
  • Ser consistente
  • Desambigua, reflete e refatora
  • Não use abreviaturas, a menos que estejam claras para todos
  • Não use palavras-chave reservadas do SQL como nomes de coluna

Eu ouço o argumento todo o tempo que se uma mesa está ou não pluralizada é tudo uma questão de gosto pessoal e não há melhor prática. Eu não acredito que isso seja verdade, especialmente como um programador em oposição a um DBA. Tanto quanto sei, não há razões legítimas para pluralizar um nome de tabela diferente de "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 erros e erros causados ​​por ambiguidades plurais. Os programadores não são exatamente conhecidos por seus conhecimentos de ortografia e pluralizar algumas palavras é confuso. Por exemplo, a palavra plural termina em 'es' ou apenas 's'? São pessoas ou pessoas? Quando você trabalha em um projeto com equipes grandes, 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 criada por ele. No momento em que interajo com essa tabela, ela é usada em todo o código que não tenho acesso ou que levaria muito tempo para corrigir. O resultado é que tenho que lembrar de escrever a tabela errado toda vez que a usar. Algo muito semelhante a isso aconteceu comigo. Quanto mais fácil você puder fazer para que todos os membros da equipe usem de forma consistente e fácil os nomes exatos e corretos das tabelas sem erros ou que precisem procurar nomes de tabelas o tempo todo, melhor. A versão singular é muito mais fácil de manipular em um ambiente de equipe.

  2. Se você usa a versão singular de um nome de tabela E prefixar 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 via código. Você pode receber uma variável com um nome de tabela, concatenar "Id" ao 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" do final de uma chave primária para determinar o nome de uma tabela por meio do código. Se você usar "id" sem um nome de tabela para a chave primária, não poderá, por meio do código, determinar o nome da tabela a partir da chave primária. Além disso, a maioria das pessoas que pluralizam nomes de tabelas e prefixam colunas PK com o nome da tabela usam a versão singular do nome da tabela no PK (por exemplo, status e statusId), tornando impossível fazer isso.

  3. Se você criar nomes de tabela no singular, poderá fazer 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 interessantes, 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 no singular, ele tornará seu esquema de nomenclatura consistente, organizado e fácil de manter em todos os locais. Você sabe que, em cada instância do seu código, seja em um nome de coluna, como um nome de classe ou como o nome da tabela, é o mesmo nome exato. Isso permite que você faça pesquisas globais para ver em todos os lugares que os dados são usados. Quando você pluralizar 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). Faz sentido não ter algumas instâncias onde seus dados são referidos como plural e algumas instâncias singulares.

Para resumir, se você pluralizar seus nomes de tabela, estará perdendo todos os tipos de vantagens para tornar seu código mais inteligente e fácil de manusear. Pode até haver casos em que você precisa ter tabelas / matrizes de pesquisa para converter seus nomes de tabela em nomes de código locais ou de objeto que você poderia ter evitado. Nomes de tabelas singulares, apesar de talvez parecerem um pouco estranhos no início, oferecem vantagens significativas em relação aos nomes pluralizados e acredito que sejam as melhores práticas.


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

A amostra AdventureWorks usa uma convenção de nomenclatura muito clara e consistente que usa nomes de esquemas 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 (ex: SchemeName.TableName)
  4. Invólucro Pascal (também conhecido como estojo de camelo superior)

Eu trabalho em uma equipe de suporte a 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 "um verdadeiro", todos nós temos nossas preferências
  3. Se já houver um padrão, use-o. Não crie outro padrão ou enlamear os padrões existentes.

Nós usamos nomes singulares para tabelas. Tabelas tendem a ser prefixadas com o nome do sistema (ou seu acrônimo). Isso é útil se o sistema for complexo, pois você pode alterar o prefixo para agrupar as tabelas logicamente (ou seja, reg_customer, reg_booking e regadmin_limits).

Para os campos, esperamos que os nomes dos campos incluam o prefixo / acrônimo da tabela (isto é, 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" number ", _dt para" Date ").

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

ou seja

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 de entidades, prefixos e acrônimos preferidos e forneça este documento para seus desenvolvedores. Então, quando eles decidem criar uma nova tabela, eles podem se referir ao documento em vez de "adivinhar" o que a tabela e os campos devem ser chamados.


Minhas opiniões sobre estes são:

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

Enquanto parece 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ê está usando o set-logic:

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 se estou sempre usando um alias (como o Matt sugere) esclarece isso.

2) Devem ser singulares, pois só possuem 1 imóvel

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 alias) pode distingui-los bem o suficiente. Você quer que as consultas sejam rápidas de digitar e simples - os prefixos adicionam complexidade desnecessária.

4) O que você quiser, eu sugiro que o CapitalCase

Eu não acho que há um conjunto de diretrizes absolutas em qualquer um destes.

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


Na minha opinião:

  1. Nomes de tabelas devem ser no plural.
  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 foi mencionado, qualquer convenção é melhor do que nenhuma convenção. Não importa como você decida fazê-lo, documente-o para que as modificações futuras sigam as mesmas convenções.


Nomes de tabelas devem sempre ser singulares, porque eles representam um conjunto de objetos. Como você diz rebanho para designar um grupo de ovelhas, ou rebanho designam um grupo de aves. Não há necessidade de plural. Quando um nome de tabela é uma composição de dois nomes e a convenção de nomenclatura está no plural, torna-se difícil saber se o nome do plural deve ser a primeira palavra ou a segunda palavra, ou ambas. É a lógica - objeto.instância, não objetos.instância. Ou TableName.column, não TableNames.column (s). O Microsoft SQL não diferencia maiúsculas de minúsculas, é mais fácil ler nomes de tabelas, se forem usadas letras maiúsculas, para separar nomes de tabelas ou colunas quando eles forem compostos de dois ou mais nomes.


Resposta tardia aqui, mas em suma:

  1. Minha preferência é plural
  2. sim
  3. Tabelas : * Normalmente * nenhum prefixo é melhor. Colunas : Não.
  4. Ambas as tabelas e colunas: PascalCase.

Elaboração:

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

  • Nomeie suas chaves primárias usando o formato "[singularOfTableName] ID". Ou seja, se o nome da sua tabela é Cliente ou Clientes , 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 faça isso. Eu diria que, embora as restrições de chave estrangeira sejam frequentemente importantes, a nomenclatura de chave estrangeira consistente é sempre importante
  • Seu banco de dados deve ter convenções internas . Embora em seções posteriores você me veja sendo muito flexível, dentro de uma nomeação de banco de dados deve ser muito consistente. Se a sua tabela para clientes é chamada de Clientes ou o Cliente é menos importante do que você faz da mesma maneira em todo o mesmo banco de dados. E você pode apostar uma moeda para determinar como usar os sublinhados, mas deve continuar usando-os da mesma maneira . Se você não fizer isso, você é uma pessoa ruim que deve ter baixa auto-estima.

(2) O que você provavelmente deveria fazer.

  • Os campos que representam o mesmo tipo de dados em diferentes tabelas devem ter o mesmo nome. Não tem Zip em uma tabela e ZipCode em outra.
  • Para separar palavras em seus nomes de tabela ou coluna, use PascalCasing. Usar camelCasing não seria intrinsecamente problemático, mas essa não é a convenção e pareceria engraçado. Vou abordar sublinhados em um momento. (Você não pode usar o ALLCAPS como antigamente. OBNOXIOUSTABLE.ANNOYING_COLUMN estava ok no DB2 há 20 anos, mas não agora.)
  • Não encurte 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 mais selvagens. Cus_AddRef. O que raios é aquilo? Referência do Destinatário Custodial? Reembolso adicional do cliente? Encaminhamento de endereço personalizado?

(3) O que você deve considerar.

  • Eu realmente acho que você deveria ter nomes no plural 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 no plural, as tabelas que representam combinações de outras tabelas podem estar no singular. Por exemplo, se você tem uma tabela de Promoções e Itens , uma tabela que representa um item como parte de uma promoção pode ser Promotions_Items, mas também pode ser legitimamente Promotion_Items (refletindo o relacionamento um-para-muitos).
  • Use sublinhados de forma consistente e para um propósito específico. Apenas os nomes das tabelas gerais devem ser suficientemente claros com o PascalCasing; você não precisa de sublinhados para separar palavras. Salve sublinhados (a) para indicar uma tabela associativa ou (b) para prefixar, que abordarei no próximo marcador.
  • O prefixo não é bom nem ruim. Geralmente não é o melhor. Em seus primeiros db ou dois, eu não sugeriria usar prefixos para agrupamento temático geral de tabelas. As tabelas acabam não se ajustando facilmente às suas categorias, e isso pode dificultar a localização de tabelas. Com experiência, você pode planejar e aplicar um esquema de prefixos que faz mais bem do que mal. Eu trabalhei em um banco de dados uma vez onde as tabelas de dados começaram com tbl , tabelas de configuração com ctbl , visualizações com vew , sp do proc e fdf do udf , e alguns outros; foi meticulosamente, consistentemente aplicado por isso funcionou bem. A única vez que você PRECISA de prefixos é quando você tem soluções realmente separadas que, por algum motivo, residem no mesmo db; prefixá-los pode ser muito útil no agrupamento das tabelas. O prefixo também é válido para situações especiais, como para tabelas temporárias que você deseja destacar.
  • Muito raramente (se alguma vez) você deseja prefixar colunas.

Sou também a favor de uma convenção de nomenclatura do estilo ISO / IEC 11179, observando que elas são diretrizes em vez de prescritivas.

Veja o nome do elemento de dados na Wikipedia :

"Tabelas são coleções de entidades e seguem as diretrizes de nomeação da coleção. Idealmente, um nome coletivo é usado: por exemplo, pessoal. Plural também está correto: funcionários. Nomes incorretos incluem: Employee, tblEmployee e EmployeeTable."

Como sempre, há exceções às regras, por exemplo, uma tabela que sempre tem exatamente uma linha pode ser melhor com um nome singular, por exemplo, uma tabela de configuração. E a consistência é de extrema importância: verifique se você faz compras tem uma convenção e, se for o caso, siga-a; Se você não gosta, então faça um business case para que ele seja mudado, em vez de ser o ranger solitário.


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

nomes de tabelas escolhem nomes curtos e não ambíguos, usando não mais do que uma ou duas palavras distinguem tabelas facilitam facilmente a nomeação de nomes de campos exclusivos, assim como tabelas de consulta e vinculação dão nomes singulares às tabelas, nunca plural (atualização: ainda concordo com as razões dadas para esta convenção, mas a maioria das pessoas realmente gosta de nomes de tabelas no plural, então eu suavizei minha postura) ... siga o link acima, por favor


Nome da Tabela: Deve ser singular, pois é uma entidade singular representando um objeto do mundo real e não objetos, que é singular.

Nome da Coluna: Deve ser singular somente então ele transmite um valor atômico e confirmará a teoria de normalização. Se, no entanto, houver n número do mesmo tipo de propriedades, então elas devem ser sufixadas com 1, 2, ..., n, etc.

Prefixando Tabelas / Colunas: É um tópico enorme, discutirá mais tarde.

Embalagem: Deve ser caso de camelo

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



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

Estas são as convenções que me ensinaram, mas você deve se adaptar ao que quer que você use.

  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 nomenclatura facilmente rastreável de todos os índices e aliases de tabela de restrições.
  4. Caso Pascal para nomes de tabelas e colunas, prefixo + letras maiúsculas para índices e restrições.

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName






naming-conventions