Convenções de nomenclatura de banco de dados, tabelas e colunas?[fechado]

https://stackoverflow.com/questions/7662

08-06-2019
|

Pergunta

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

Os nomes das tabelas devem estar no plural?
Os nomes das colunas devem ser singulares?
Devo prefixar tabelas ou colunas?
Devo usar qualquer caso para nomear itens?

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

Solução

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.

Nomes singulares para tabelas
Nomes singulares para colunas
Nome do esquema para prefixo de tabelas (por exemplo:Nomedoesquema.Nomedatabela)
Invólucro Pascal (também conhecido comocaso de camelo superior)

Outras dicas

Resposta tardia aqui, mas resumida:

Meu preferência é plural
Sim
Tabelas:*Normalmente* nenhum prefixo é melhor. Colunas:Não.
Tabelas e colunas:PascalCase.

Elaboração:

(1) O que você deve fazer. Há muito poucas coisas que você deve faça de uma certa maneira, sempre, mas existem alguns.

Nomeie seu 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 Identificação do Cliente.
Avançar, chaves estrangeiras deve ser nomeado consistentemente em tabelas diferentes.Deveria ser legal bater em alguém que não faz isso.Eu diria que, embora as restrições de chave estrangeira definidas sejam muitas vezes uma nomenclatura de chave estrangeira importante e consistente é sempre importante
Seu banco de dados deve ter convenções internas.Embora nas seções posteriores você me veja sendo muito flexível, dentro de uma nomenclatura de banco de dados deve ser muito consistente.Se a sua mesa para clientes se chama Clientes ou Cliente é menos importante do que fazer isso da mesma maneira no mesmo banco de dados.E você pode jogar uma moeda para determinar como usar sublinhados, mas então você deve continuar a usá-los da mesma maneira.Se você não fizer isso, você é uma pessoa má que deveria ter baixa autoestima.

(2) O que você provavelmente deveria fazer.

Campos que representam o mesmo tipo de dados em tabelas diferentes deve ter o mesmo nome.Não tenha Zip em uma tabela e ZipCode em outra.
Para separar palavras nos nomes de tabelas ou colunas, use PascalCasing.Usar camelCasing não seria intrinsecamente problemático, mas essa não é a convenção e pareceria engraçado.Abordarei os 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 encurte ou abrevie palavras artificialmente.É melhor um nome ser longo e claro do que curto e confuso.Nomes ultracurtos 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.No entanto, os nomes das colunas devem ser singulares.Mesmo se você usar nomes de tabelas no plural, as tabelas que representam combinações de outras tabelas poderão estar no singular.Por exemplo, se você tiver um Promoções e um Unid table, uma tabela que representa um item que faz parte de uma promoção poderia ser Promotions_Items, mas também poderia ser legitimamente Promotion_Items, eu acho (refletindo o relacionamento um-para-muitos).
Use sublinhados de forma consistente e para uma finalidade específica.Apenas os nomes gerais das tabelas devem ser suficientemente claros com PascalCasing;você não precisa de sublinhados para separar palavras.Salve os sublinhados (a) para indicar uma tabela associativa ou (b) para prefixar, que abordarei no próximo item.
A prefixação não é boa nem ruim.Isto geralmente não é o melhor.Em seus primeiros bancos de dados, eu não sugeriria o uso de prefixos para agrupamento temático geral de tabelas.As tabelas acabam não se ajustando facilmente às suas categorias e podem realmente torná-lo mais difícil para encontrar tabelas.Com experiência, você pode planejar e aplicar um esquema de prefixação que faz mais bem do que mal.Eu trabalhei em um banco de dados uma vez onde as tabelas de dados começavam com tbl, configure tabelas com ctbl, visualizações com uau, proc's sp, e udf fn, e alguns outros;foi meticulosamente aplicado de forma consistente, então funcionou bem.A única vez que você PRECISA de prefixos é quando você tem soluções realmente separadas que, por algum motivo, residem no mesmo banco de dados;prefixá-los pode ser muito útil para agrupar as tabelas.O prefixo também é adequado para situações especiais, como tabelas temporárias que você deseja destacar.
Muito raramente (se alguma vez) você gostaria de prefixar colunas.

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

Acredito que os nomes das tabelas devem estar no plural.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 Person de Pessoas (ou Pessoas, o que você preferir).

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

SELECT person.Name
FROM People person

Um pouco como o "from person in people select person.Name" do LINQ.

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

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

Qualquer padrão de nomenclatura é melhor do que nenhum padrão.
Não existe um padrão “único e verdadeiro”, todos nós temos nossas preferências
Se já existir um padrão em vigor, use-o.Não crie outro padrão nem turve os padrões existentes.

Usamos nomes singulares para tabelas.As tabelas tendem a ser prefixadas com o nome do sistema (ou sua sigla).Isto é ú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/acryonm da tabela (ou seja,cust_address1) e também preferimos o uso de um conjunto padrão de sufixos ( _id para PK, _cd para "código", _nm para "nome", _nb para "número", _dt para "Data").

O nome do campo-chave estrangeiro deve ser igual ao campo-chave primário.

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 siglas preferenciais e entregue este documento aos seus desenvolvedores.Então, quando decidirem criar uma nova tabela, eles poderão consultar o documento em vez de "adivinhar" como a tabela e os campos devem ser chamados.

Não.Uma tabela deve receber o nome da entidade que representa.Pessoa, não pessoas, é como você se referiria a quem quer que um dos registros represente.
Novamente, a mesma coisa.A coluna FirstName realmente não deveria ser chamada de FirstNames.Tudo depende do que você deseja representar com a coluna.
NÃO.
Sim.Case-o para maior clareza.Se você precisar de colunas como "Nome", as maiúsculas e minúsculas facilitarão a leitura.

OK.Esses são meus $ 0,02

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

Ver Nome do elemento de dados na Wikipedia:

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

Como sempre, há exceções às regras, por ex.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 sua loja possui convenção e, se sim, siga-a;se você não gostar, faça um caso de negócios para alterá-lo, em vez de ser o guarda solitário.

nossa preferência:

Os nomes das tabelas devem estar no plural?
Nunca.Os argumentos para ser uma coleção fazem sentido, mas você nunca sabe o que a tabela irá conter (0,1 ou muitos itens).As regras plurais tornam a nomenclatura desnecessariamente complicada.1 casa, 2 casas, rato contra ratos, pessoa contra pessoas, e nem sequer olhamos para 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.
Os nomes das colunas devem ser singulares?
Normalmente sim, exceto quando você viola as regras de normalização.
Devo prefixar tabelas ou colunas?
Principalmente uma preferência de plataforma.Preferimos prefixar as colunas com o nome da tabela.Não prefixamos tabelas, mas prefixamos visualizações (v_) e procedimentos armazenados (sp_ ou f_ (função)).Isso ajuda as pessoas que desejam tentar atualizar v_person.age, que na verdade é um campo calculado em uma visualização (que não pode ser ATUALIZADO de qualquer maneira).

Também é uma ótima maneira de evitar colisão de palavras-chave (delivery.from é interrompido, 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 ela vem (tabela customer).

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

customer_category_customer_type_id

...é um pouco (!) no lado comprido.
Devo usar qualquer caso para nomear itens?Sim - letras minúsculas :), com sublinhados.Eles são muito legíveis e multiplataforma.Juntamente com o 3 acima, também faz sentido.

A maioria delas são preferências.- Contanto que você seja consistente, deve ser previsível para qualquer pessoa que precise lê-lo.

Ouço o tempo todo o argumento de que a pluralização ou não de uma mesa é uma questão de gosto pessoal e não existe prática recomendada.Não acredito que isso seja verdade, especialmente como programador e não como DBA.Até onde sei, não há razões legítimas para pluralizar o nome de uma tabela além de "Faz sentido para mim porque é uma coleção de objetos", embora haja ganhos legítimos no código por ter nomes de tabelas singulares.Por exemplo:

Evita bugs e erros causados por ambigüidades plurais.Os programadores não são exatamente conhecidos por sua experiência em 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 que ele cria.No momento em que interajo com esta tabela, ela é usada em todo o código ao qual não tenho acesso ou que levaria muito tempo para ser corrigido.O resultado é que tenho que me lembrar de soletrar a tabela errada toda vez que a uso.Algo muito parecido com isso aconteceu comigo.Quanto mais fácil for para que cada membro da equipe use de forma consistente e fácil os nomes de tabelas exatos e corretos, sem erros ou sem ter que procurar nomes de tabelas o tempo todo, melhor.A versão singular é muito mais fácil de manusear em um ambiente de equipe.
Se você usar a versão singular de um nome de tabela E prefixar a chave primária com o nome da tabela, agora terá a vantagem de determinar facilmente um nome de tabela a partir de uma chave primária ou vice-versa apenas por meio de 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 o "Id" do final de uma chave primária para determinar o nome de uma tabela por meio de código.Se você usar "id" sem um nome de tabela para a chave primária, não poderá determinar por meio do código 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.
Se você tornar os nomes das tabelas singulares, poderá fazer com que correspondam aos nomes das classes que 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...
Se você tornar o nome da tabela singular, seu esquema de nomenclatura será 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, como um nome de classe ou como nome de tabela, é exatamente o mesmo nome.Isso permite que você faça pesquisas globais para ver onde quer que os dados sejam usados.Ao pluralizar o nome de uma tabela, haverá casos em que você usará a versão singular desse nome de tabela (a classe em que ela se transforma, na chave primária).Faz sentido não ter alguns casos em que seus dados sejam referidos como plural e alguns casos como singulares.

Resumindo, se você pluralizar os nomes das tabelas, estará perdendo todos os tipos de vantagens em 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 nomes de objetos ou códigos locais que você poderia ter evitado.Nomes de tabelas singulares, embora talvez pareçam um pouco estranhos no início, oferecem vantagens significativas sobre nomes pluralizados e acredito que sejam uma prática recomendada.

Dê uma olhada na ISO 11179-5:Princípios de nomeação e identificação Você pode obtê -lo aqui: http://metadata-standards.org/11179/#11179-5

Eu escrevi sobre isso há um tempo aqui: Convenções de nomenclatura ISO-11179

Sei que já é tarde para o jogo e a pergunta já foi respondida muito bem, mas quero dar minha opinião sobre o item 3 em relação ao 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 com os prefixos “cust” e “addr”, respectivamente."cliente" teria "cust_id", "cust_name", etc.iniciar."endereço" teria "addr_id", "addr_cust_id" (FK de volta ao cliente), "addr_street", etc.iniciar.

Quando me foi apresentado esse padrão pela primeira vez, fui totalmente contra ele;Eu odiei a ideia.Eu não suportava a ideia de toda aquela digitação e redundância extras.Agora tenho experiência suficiente com isso e nunca mais voltarei.

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

Você pode pesquisar toda a sua base de código e encontrar com segurança cada linha de código que toca 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 saber se os dados de uma coluna estão sendo usados em uma parte específica do sistema.Não consigo contar quantas vezes isso transformou um projeto potencialmente enorme em um projeto simples, nem quantas horas economizamos no trabalho de desenvolvimento.

Outro benefício relativamente menor é que você só precisa usar aliases de tabela ao fazer uma auto-junção:

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%';

Minhas opiniões sobre isso 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 se sempre usar um alias (como sugere Matt) 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 alias) poderá distingui-los bem o suficiente.Você deseja que as consultas sejam rápidas e simples de digitar - os prefixos adicionam complexidade desnecessária.

4) O que você quiser, sugiro CapitalCase

Não creio que exista um conjunto de diretrizes absolutas sobre qualquer um deles.

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:

Os nomes das tabelas devem estar no plural.
Os nomes das colunas devem ser singulares.
Não.
CamelCase (meu preferido) ou underscore_separated para nomes de tabelas e colunas.

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

Definitivamente, mantenha os nomes das tabelas no singular, pessoa e não pessoas
1. Mesmo aqui
2. Não.Já vi alguns prefixos terríveis, chegando ao ponto de afirmar que o que estamos tratando é 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.Eu costumo PascalCase todos os nomes das minhas tabelas

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 como é a convenção de nomenclatura.

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

É claro que é bom buscar algumas 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ê poderá obter:escolha aquele que parece melhor para você.

Por precaução, aqui estão minhas respostas:

Sim.Uma mesa é um grupo de registros, professores ou atores, então...plural.
Sim.
Eu não os uso.
O banco de dados que uso com mais frequência - Firebird - mantém tudo em letras maiúsculas, então não importa.Enfim, quando estou programando escrevo os nomes de uma forma que seja mais fácil de ler, como ano de lançamento.

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 uma linguagem comum.Uma boa convenção de nomenclatura cresce organicamente com o projeto.Uma boa convenção de nomenclatura lida facilmente com mudanças durante a fase mais longa e importante do ciclo de vida do software – gerenciamento de serviços em produção.

Aqui estão minhas respostas:

Sim, os nomes das tabelas devem estar no plural quando se referem a um conjunto de negociações, títulos, ou contrapartes por exemplo.
Sim.
Sim.As tabelas SQL são prefixadas com tb_, as visualizações são prefixadas com vw_, os procedimentos armazenados são prefixados com usp_ e os gatilhos são prefixados com tg_ seguido pelo nome do banco de dados.
O nome da coluna deve estar em letras minúsculas separadas por sublinhado.

Nomear é difícil, mas em cada organização há alguém que pode nomear coisas e em cada equipe de software deve haver alguém que assuma a responsabilidade pelos padrões de nomenclatura e garanta que questões de nomenclatura como sec_id, valor_sec e segurança_id sejam resolvidos antes de serem incorporados ao 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 seu domínio da solução
Seja descritivo
Ser consistente
Desambiguar, refletir e refatorar
Não use abreviações, a menos que estejam claros para todos
Não use palavras -chave reservadas SQL como nomes de colunas

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

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

Os nomes das tabelas devem ser sempre singulares, pois representam um conjunto de objetos.Como você diz rebanho para designar um grupo de ovelhas, ou rebanho designa um grupo de pássaros.Não há necessidade de plural.Quando o nome de uma tabela é uma composição de dois nomes e a convenção de nomenclatura está no plural, fica difícil saber se o nome no plural deve ser a primeira palavra, 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 nomes de tabelas, se forem usadas letras maiúsculas, para separar nomes de tabelas ou colunas quando elas são compostas por dois ou mais nomes.

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

Nome da tabela: Deveria 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 só então transmite que terá um valor atômico e confirmará a teoria de normalização.Se, no entanto, houver n número de propriedades do mesmo tipo, elas deverão ter o sufixo 1, 2, ..., n, etc.

Prefixando tabelas/colunas:É um tópico enorme, discutiremos mais tarde.

Invólucro:Deveria 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.Deveria ser legal bater em alguém que não faz isso.".Nunca cometi esse erro, meu amigo Patrick, mas estou escrevendo em geral.E se eles juntos planejarem vencer você por isso?:)

Muito tarde para a festa, mas ainda queria acrescentar meus dois centavos sobre os prefixos das colunas

Parece haver dois argumentos principais para usar o padrão de nomenclatura table_column (ou tableColumn) para colunas, ambos baseados no fato de que o próprio nome da coluna será exclusivo em todo o banco de dados:

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

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

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

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

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

Mas posso ouvir você gritar, como isso resolve 1)?Tratava-se exatamente de evitar isso.Sim, era, mas a solução era terrivelmente falha.Por que?Bem, a solução do prefixo se resume a:
Para evitar ter que especificar table.column quando houver ambigüidade, você nomeia todas as suas colunas como 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ê tiver que fazer isso de qualquer maneira, qual é a vantagem de sempre escrever explicitamente table.column?Exatamente, não há benefício, é exatamente o mesmo número de caracteres para digitar.

editar:sim, estou ciente de que nomear as colunas com o prefixo impõe o uso correto, enquanto minha abordagem depende dos programadores

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

Nomes de tabela Escolha nomes curtos e inequívocos, usando não mais de uma ou duas palavras distinguindo tabelas facilita facilmente a nomeação de nomes de campo exclusivos, bem como as tabelas de pesquisa e vinculação dão a tabelas nomes singulares, nunca plural (atualização:ainda concordo com as razões apresentadas para esta convenção, mas a maioria das pessoas realmente gosta de nomes de tabelas no plural, então suavizei minha posição)...segue o link acima por favor

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


--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 aprendi, mas você deve se adaptar a tudo o que sua mangueira de desenvolvimento usa.

Plural.É uma coleção de entidades.
Sim.O atributo é uma representação da propriedade singular de uma entidade.
Sim, o nome da tabela de prefixo permite uma nomenclatura facilmente rastreável de todos os índices de restrições e aliases de tabela.
Pascal Case para nomes de tabelas e colunas, prefixo + ALL caps para índices e restrições.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow