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

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?

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)

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.

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.

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.

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

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.

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.

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.

Veja a ISO 11179-5: Princípios de nomenclatura e identificação Você pode obtê-lo aqui: http://metadata-standards.org/11179/#11179-5

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

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

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.

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.

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 .

1. Definitivamente mantenha os nomes das tabelas singulares, pessoa e não pessoas
   2. O mesmo aqui
   3. 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!
   4. Sim. Tendo a PascalCase todos os meus nomes de tabela

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

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

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

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.

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? :)

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

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

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.

--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.