Convenção de nomenclatura da tabela relacional

Estou iniciando um novo projeto e gostaria de obter meus nomes de tabelas e colunas desde o início. Por exemplo, eu sempre usei plural em nomes de tabelas, mas recentemente aprendi que o singular está correto.

Então, se eu tenho uma tabela “user” e então eu tenho produtos que só o usuário terá, deve a tabela ser chamada “user_product” ou apenas “product”? Este é um relacionamento para muitos.

E mais adiante, se eu tivesse (por algum motivo) várias descrições de produto para cada produto, seria “user_product_description” ou “product_description” ou apenas “description”? Claro que com o conjunto de foreign keys certo .. Nomeando-o única descrição seria problemática desde que eu também poderia ter descrição do usuário ou descrição da conta ou o que quer

E se eu quiser uma tabela relacional pura (muitos para muitos) com apenas duas colunas, como isso seria? “user_stuff” ou talvez algo como “rel_user_stuff”? E se o primeiro, o que distingue isso, por exemplo, “user_product”?

Qualquer ajuda é muito apreciada e se houver algum tipo de padrão de convenção de nomenclatura que vocês recomendam, sinta-se à vontade para linkar.

obrigado

Nome da mesa

recentemente aprendi singular é correto

Sim. Cuidado com os pagãos. Nomes de tabelas plurais são um sinal claro de alguém que não leu nenhum dos materiais padrão e não tem conhecimento de teoria de database.

Algumas das coisas maravilhosas sobre Padrões são: elas são todas integradas umas às outras; eles trabalham juntos; e eles foram escritos por mentes maiores que as nossas, então não precisamos debatê-los. O nome da tabela padrão refere-se a cada linha na tabela, que é usada em todo o palavreado, não no conteúdo total da tabela (sabemos que a tabela Customer contém todos os Clientes).

Relação, Frase Verbal

Em bancos de dados relacionais genuínos que foram modelados (em oposição a sistemas de arquivamento de registros implementados em um contêiner de database SQL):

  • as tabelas são os Sujeitos do database, assim são substantivos , novamente, singulares
  • os relacionamentos entre as tabelas são as Ações que ocorrem entre os substantivos, portanto são verbos (isto é, não são numerados ou nomeados arbitrariamente)
  • esse é o predicado
  • tudo o que pode ser lido diretamente do modelo de dados (consulte meus exemplos no final)
  • (o Predicado para uma tabela independente (o pai mais alto em uma hierarquia) é que é independente)
  • assim, a Frase Verbal é cuidadosamente escolhida, de modo que é a mais significativa, e os termos genéricos são evitados (isso se torna mais fácil com a experiência). A frase verbo é importante durante a modelagem porque auxilia na resolução do modelo, ou seja. esclarecendo relações, identificando erros e corrigindo os nomes das tabelas.

Diagrama_A

Naturalmente, o relacionamento é implementado em SQL como uma restrição de chave estrangeira na tabela filho (mais, mais tarde). Aqui está a Frase Verbica (no modelo), o Predicado que representa (a ser lido no modelo) e o Nome da Restrição FK:

  Initiates Each Customer Initiates 0-to-n SalesOrders Customer_Initiates_SalesOrder_fk 

Tabela • Idioma

No entanto, ao descrever a tabela, particularmente em linguagem técnica, como os Predicados, ou outra documentação, use o singular e o plural como eles naturalmente no idioma inglês. Tendo em mente que a tabela é nomeada para a única linha (relação) e a linguagem se refere a cada linha derivada (relação derivada):

  Each Customer initiates zero-to-many SalesOrders 

não

  Customers have zero-to-many SalesOrders 

Então, se eu tenho uma tabela “usuário” e depois eu tenho produtos que só o usuário terá, deve a tabela ser chamada “usuário-produto” ou apenas “produto”? Este é um relacionamento para muitos.

(Isso não é uma questão de convenção de nomenclatura; é uma questão de design do aa db.) Não importa se user::product é 1 :: n. O que importa é se o product é uma entidade separada e se é uma tabela independente , ou seja. pode existir por conta própria. Portanto, product , não user_product .

E se o product existe apenas no contexto de um user , ou seja. é uma Tabela Dependente , portanto, user_product .

Diagrama_B

E mais adiante, se eu tivesse (por algum motivo) várias descrições de produto para cada produto, seria “user-product-description” ou “product-description” ou apenas “description”? Claro que com o conjunto de foreign keys certo .. Nomeando-o única descrição seria problemática desde que eu poderia também ter descrição do usuário ou descrição da conta ou o que quer.

Está certo. Tanto user_product_description xor product_description estará correto, com base no acima. Não é para diferenciá-lo de outras xxxx_descriptions , mas é dar ao nome uma noção de onde ele pertence, sendo o prefixo a tabela pai.

E se eu quiser uma tabela relacional pura (muitos para muitos) com apenas duas colunas, como isso seria? “user-stuff” ou talvez algo como “rel-user-stuff”? E se o primeiro, o que distinguiria isso, por exemplo, “usuário-produto”?

  1. Espero que todas as tabelas no database relacional sejam tabelas puramente relacionais e normalizadas. Não há necessidade de identificar isso no nome (caso contrário, todas as tabelas serão rel_something ).

  2. Se ele contiver apenas os PKs dos dois pais (que resolve o relacionamento n n n n que não existe como uma entidade no nível lógico, em uma tabela física ), isso é uma Tabela Associativa . Sim, geralmente o nome é uma combinação dos dois nomes de tabela pai.

    • Observe que nesses casos a Frase Verbal se aplica a, e é lida como, de pai para pai, ignorando a tabela filha, porque seu único propósito na vida é relacionar os dois pais.

      Diagram_C

    • Se não for uma Tabela Associativa (ou seja, além das duas PKs, ela contém dados), nomeie-a adequadamente e as Frases Verbicas se apliquem a ela, não ao pai no final do relacionamento.

      Diagram_D

  3. Se você acabar com duas tabelas user_product , então é um sinal muito alto de que você não normalizou os dados. Então, volte alguns passos e faça isso, e nomeie as tabelas com precisão e consistência. Os nomes então se resolverão.

Convenção de nomes

Qualquer ajuda é muito apreciada e se houver algum tipo de padrão de convenção de nomenclatura que vocês recomendam, sinta-se à vontade para linkar.

O que você está fazendo é muito importante e afetará a facilidade de uso e compreensão em todos os níveis. Por isso, é bom obter o máximo de compreensão possível desde o início. A relevância da maioria disso não ficará clara até você começar a codificar em SQL.

  1. Caso é o primeiro item a ser endereçado. Todas as tampas são inaceitáveis. Caso misto é normal, especialmente se as tabelas estiverem diretamente acessíveis pelos usuários. Consulte meus modelos de dados. Note que quando o buscador está usando algum NonSQL demente, que tem apenas letras minúsculas, eu dou isso, nesse caso eu incluo sublinhados (conforme seus exemplos).

  2. Manter um foco de dados , não um foco de aplicativo ou uso. É, depois de todo o ano de 2011, que temos Arquitetura Aberta desde 1984, e os bancos de dados supostamente são independentes dos aplicativos que os utilizam.

    Dessa forma, à medida que crescem e mais do que um aplicativo usa, a nomenclatura permanecerá significativa e não precisará de correção. (Bancos de dados que são completamente incorporados em um único aplicativo não são bancos de dados.) Nomeie os elementos de dados como apenas dados.

  3. Seja muito atencioso e nomeie as tabelas e colunas com muita precisão . Não use UpdatedDate se for um tipo de dados DATETIME , use UpdatedDtm . Não use _description se contiver uma dosagem.

  4. É importante ser consistente em todo o database. Não use NumProduct em um local para indicar o número de Produtos e ItemNo ou ItemNum em outro local para indicar o número de Itens. Use NumSomething para números de e SomethingNo ou SomethingId para identificadores de forma consistente.

  5. Não prefixar o nome da coluna com um nome de tabela ou código abreviado, como user_first_name . O SQL já fornece o nome da tabela como um qualificador:

      table_name.column_name -- notice the dot 
  6. Exceções:

    • A primeira exceção é para PKs, eles precisam de tratamento especial porque você os codifica em junções, o tempo todo, e você quer que as teclas se destaquem nas colunas de dados. Sempre use user_id , nunca id .

      • Observe que este não é um nome de tabela usado como um prefixo, mas um nome descritivo adequado para o componente da chave: user_id é a coluna que identifica um usuário, não o id da tabela de user .
        • (Exceto, é claro, nos sistemas de arquivamento de registros, onde os arquivos são acessados ​​por substitutos e não há chaves relacionais, eles são uma e a mesma coisa).
      • Sempre use o mesmo nome exato para a coluna de chave onde quer que a PK seja transportada (migrada) como um FK.
      • Portanto, a tabela user_product terá um user_id como um componente de seu PK (user_id, product_no) .
      • a relevância disso ficará clara quando você começar a codificar. Primeiro, com um id em muitas tabelas, é fácil misturar-se na codificação SQL. Segundo, qualquer outra pessoa que o programador inicial não tem ideia do que ele estava tentando fazer. Ambos são fáceis de evitar, se as colunas-chave são tratadas como acima.
    • A segunda exceção é onde há mais de um FK fazendo referência à mesma tabela de tabela pai, transportada no filho. De acordo com o modelo relacional , use nomes de function para diferenciar o significado ou uso, por exemplo. AssemblyCode e ComponentCode para dois PartCodes . E nesse caso, não use o PartCode indiferenciado para um deles. Seja preciso.

      Diagrama_E

  7. Prefixo
    Onde você tem mais do que 100 tabelas, prefixar os nomes das tabelas com uma área de assunto:

    REF_ para tabelas de referência
    OE_ para o cluster de input de pedidos, etc.

    Apenas no nível físico, não o lógico (desordena o modelo).

  8. Sufixo
    Nunca use sufixos nas tabelas e sempre use sufixos em todo o resto. Isso significa que, no uso normal e lógico do database, não há sublinhados; mas no lado administrativo, os sublinhados são usados ​​como separador:

    _V View (com o TableName principal na frente, claro)
    _fk Chave estrangeira (o nome da restrição, não o nome da coluna)
    Cache _cac
    Segmento _seg
    _tr Transaction (stored _tr ou function)
    Função _fn (não transacional), etc.

    O formato é a tabela ou o nome FK, um sublinhado e o nome da ação, um sublinhado e, finalmente, o sufixo.

    Isto é realmente importante porque quando o servidor lhe dá uma mensagem de erro:

    ____ blah blah blah error on object_name

    você sabe exatamente qual object foi violado e o que estava tentando fazer:

    ____ blah blah blah error on Customer_Add_tr

  9. Chaves estrangeiras (a restrição, não a coluna). A melhor nomenclatura para um FK é usar a frase verbal (menos o “cada” e a cardinalidade).

    Customer_Initiates_SalesOrder_fk
    Part_Comprises_Component_fk
    Part_IsConsumedIn_Assembly_fk

    Use a sequência Parent_Child_fk , e não Child_Parent_fk é porque (a) aparece na ordem correta quando você está procurando por eles e (b) sempre sabemos que a criança envolvida, o que estamos adivinhando é qual pai. A mensagem de erro é então agradável:

    ____ Foreign key violation on Vendor_Offers_PartVendor_fk .

    Isso funciona bem para pessoas que se importam em modelar seus dados, onde as frases verbais foram identificadas. Para o resto, os sistemas de arquivamento de registros, etc, usam Parent_Child_fk .

  10. Índices são especiais, então eles têm uma convenção de nomenclatura própria, composta de, na ordem , cada posição de caractere de 1 a 3:

    U Unique, ou _ para não-exclusivo
    C Clustered ou _ para não agrupado
    _ separador

    Para o restante:

    • Se a chave é uma coluna ou muito poucas colunas:
      ____ ColumnNames

    • Se a chave é mais do que algumas colunas:
      ____ PK Primary Key (conforme modelo)
      ____ AK[*n*] Chave Alternativa (termo IDEF1X)

    Observe que o nome da tabela não é obrigatório no nome do índice, porque sempre aparece como table_name.index_name.

    Então, quando Customer.UC_CustomerId ou Product.U__AK aparece em uma mensagem de erro, ele informa algo significativo. Quando você olha para os índices em uma tabela, pode diferenciá-los facilmente.

  11. Encontre alguém qualificado e profissional e siga-os. Observe os designs deles e estude as convenções de nomenclatura que eles usam. Faça perguntas específicas sobre qualquer coisa que você não entenda. Por outro lado, corra como o inferno de qualquer pessoa que demonstre pouca consideração pelas convenções ou padrões de nomenclatura. Aqui estão alguns para você começar:

    • Eles contêm exemplos reais de todos os itens acima. Faça perguntas sobre como nomear perguntas neste tópico.
    • Naturalmente, os modelos implementam vários outros Padrões, além de convenções de nomenclatura; você pode ignorá-las por enquanto ou se sentir à vontade para fazer novas perguntas específicas.
    • São várias páginas cada, o suporte de imagem inline em SO é para os pássaros, e eles não são carregados consistentemente em diferentes navegadores; então você terá que clicar nos links.
    • Observe que os arquivos PDF têm navegação completa, portanto, clique nos botões de vidro azul ou nos objects em que a expansão está identificada:
    • Leitores que não estão familiarizados com o Padrão de Modelagem Relacional podem achar a Notação IDEF1X útil.

Solicitar input e estoque com endereços compatíveis com padrão

Simples sistema de Boletim entre Escritórios para PHP / MyNonSQL

Monitoramento de sensor com capacidade temporal completa

Respostas a perguntas

Isso não pode ser razoavelmente respondido no espaço de comentários.

Larry Lustig:
… até o exemplo mais trivial mostra …
Se um cliente tiver zero-para-muitos produtos e um produto tiver um-para-muitos componentes e um componente tiver um-para-muitos fornecedores e um fornecedor vende zero-para-muitos componentes e um SalesRep tem clientes um-para-muitos Quais são os nomes “naturais” das tabelas que contêm clientes, produtos, componentes e fornecedores?

Existem dois grandes problemas no seu comentário:

  1. Você declara seu exemplo para ser “o mais trivial”, no entanto, é tudo menos isso. Com esse tipo de contradição, não tenho certeza se você é sério, se tecnicamente capaz.

  2. Essa especulação “trivial” tem vários erros de normalização bruta (DB Design).

    • Até que você os corrija, eles são antinaturais e anormais, e eles não fazem o menor sentido. Você também pode nomeá-los como anormais_1, anormal_2 etc.

    • Você tem “fornecedores” que não fornecem nada; referências circulares (ilegais e desnecessárias); clientes comprando produtos sem qualquer instrumento comercial (como Fatura ou SalesOrder) como base para a compra (ou fazem produtos “próprios” de clientes?); relacionamentos muitos-para-muitos não resolvidos; etc.

    • Quando isso é normalizado e as tabelas necessárias são identificadas, seus nomes se tornarão óbvios. Naturalmente.

Em qualquer caso, vou tentar atender sua consulta. O que significa que vou ter que adicionar algum sentido a isso, sem saber o que você quis dizer, então, por favor, tenha paciência comigo. Os erros grosseiros são muitos para listar e, dada a especificação de reposição, não estou confiante de que os corrigi.

  • Eu assumirei que se o produto é composto de componentes, então o produto é um conjunto e os componentes são usados ​​em mais de um conjunto.

  • Além disso, como “o fornecedor vende zero a muitos componentes”, que eles não vendem produtos ou montagens, eles vendem apenas componentes.

Especulação vs Modelo Normalizado

Caso você não saiba, a diferença entre cantos quadrados (Independente) e cantos arredondados (Dependente) é significativa. Por favor, consulte o link IDEF1X Notation. Da mesma forma, as linhas sólidas (Identifying) vs linhas tracejadas (Non-identification).

… quais são os nomes “naturais” das tabelas que contêm clientes, produtos, componentes e fornecedores?

  • Cliente
  • produtos
  • Componente (Ou, AssemblyComponent, para quem percebe que um fato identifica o outro)
  • Fornecedor

Agora que resolvi as tabelas, não entendi seu problema. Talvez você possa postar uma pergunta específica .

VoteCoffee:
Como você está lidando com o cenário que Ronnis postou em seu exemplo, onde existem vários relacionamentos entre duas tabelas (user_likes_product, user_bought_product)? Eu posso entender mal, mas isso parece resultar em nomes de tabela duplicados usando a convenção detalhada.

Assumindo que não há erros de normalização, o User likes Product é um predicado, não uma tabela. Não os confunda. Consulte a minha resposta, onde se relaciona com assuntos, verbos e predicados, e minha resposta a Larry imediatamente acima.

  • Cada tabela contém um conjunto de fatos (cada linha é um fato), não predicados. Predicados (ou proposições), não são Fatos, podem ou não ser verdadeiros.

    • O modelo relacional é baseado no cálculo de predicados de primeira ordem (mais comumente conhecido como lógica de primeira ordem). Um Predicado é uma sentença de cláusula única em inglês simples e preciso, que é avaliada como verdadeira ou falsa.
  • Uma consulta é um teste de um predicado (ou um número de predicados, encadeados) que resulta em verdadeiro (o fato existe) ou falso (o fato não existe).

  • Assim, as tabelas devem ser nomeadas, conforme detalhado em minha Answer (convenções de nomenclatura), pois a linha, o Fato e os Predicados devem ser documentados (por todos os meios, faz parte da documentação do database), mas como uma lista separada de Predicados. .

  • Esta não é uma sugestão de que eles não são importantes. Eles são muito importantes, mas não vou escrever isso aqui.

  • Rapidamente, então. Como o modelo relacional é baseado no FOL, todo o database pode ser considerado um conjunto de declarações, um conjunto de predicados. Mas (a) existem muitos tipos de predicados, e (b) uma tabela não representa um predicado (é a implementação física de muitos predicados e de diferentes tipos de predicados).

  • Portanto, nomear a tabela para “o” predicado que “representa” é um conceito absurdo.

  • Os “teóricos” estão cientes de apenas alguns Predicados, eles não entendem que desde que o RM foi fundado na FOL, o database inteiro é um conjunto de Predicados e de tipos diferentes.

    • E, claro, eles escolhem os absurdos dos poucos que conhecem: EXISTING_PERSON; PERSON_IS_CALLED. Se não fosse tão triste, seria hilário.

    • Observe também que o nome padrão ou atômico da tabela (nomeando a linha) funciona de maneira shiny para todo o palavreado (incluindo todos os Predicados anexados à tabela). Por outro lado, o nome idiota “tabela representa predicado” não pode. O que é bom para os “teóricos”, que entendem muito pouco sobre Predicados, mas retardaram o contrário.

  • Os Predicados que são relevantes para o modelo de dados são expressos no modelo, eles são de dois tipos.

    • O primeiro conjunto está na forma diagramática, não em texto: a notação. Estes incluem vários existenciais; Orientado por restrições; e descritores (atributos) Predicados.

    • Claro, isso significa que apenas aqueles que podem “ler” um modelo de dados Padrão podem ler esses Predicados. É por isso que os “teóricos”, que são severamente afetados por sua mentalidade de texto, não podem ler modelos de dados, por que eles se ater à sua mentalidade pré-1984 apenas em texto.

    • O segundo conjunto é aqueles Predicados que formam relacionamentos entre Fatos. Esta é a linha de relacionamento. A Frase Verbal (detalhada acima) identifica o Predicado, a proposição, que foi implementada (que pode ser testada via consulta). Não se pode ficar mais explícito do que isso.

    • Portanto, para quem é fluente em modelos de dados Padrão, todos os Predicados relevantes são documentados no modelo. Eles não precisam de uma lista separada de predicados (mas os usuários o fazem!).

  • Aqui está um modelo de dados , onde listei os predicados. Eu escolhi esse exemplo porque mostra os Predicados Existenciais, etc, assim como os Relacionados, os únicos Predicados não listados são os Descritores. Aqui, devido ao nível de aprendizado do candidato, eu o trato como um usuário.

Portanto, o evento de mais de uma tabela filho entre duas tabelas pai não é um problema, apenas nomeie-as como o fato existencial de seu conteúdo e normalize os nomes.

As regras que eu dei para Verb Phrases para nomes de relacionamento para Tabelas Associativas entram em jogo aqui. Aqui está uma discussão de Predicado versus Tabela , cobrindo todos os pontos mencionados, em resumo.

Para uma boa descrição resumida do uso apropriado de predicados e como usá-los (que é um contexto bem diferente de responder a comentários aqui), visite esta resposta e role para baixo até a seção Predicado .


Charles Burns:
Por sequência, eu quis dizer o object do estilo Oracle usado puramente para armazenar um número e o seguinte de acordo com alguma regra (por exemplo, “adicionar 1”). Como o Oracle não possui tabelas de ID automático, meu uso típico é gerar IDs exclusivos para PKs de tabela. INSERT INTO foo (id, somedata) VALORES (foo_s.nextval, “dados” …)

Ok, isso é o que chamamos de tabela Key ou NextKey. Nomeie como tal. Se você tiver SubjectAreas, use COM_NextKey para indicar que é comum em todo o database.

Btw, esse é um método muito ruim de gerar chaves. Não escalável, mas com o desempenho do Oracle, é provavelmente “muito bem”. Além disso, indica que seu database está cheio de substitutos, não relacionais nessas áreas. O que significa um desempenho extremamente fraco e falta de integridade.

Singular vs. Plural: Escolha uma e fique com ela.

As colunas não devem ser prefixadas / sufixo / infixadas ou de qualquer forma fixas com referências ao fato de que é uma coluna. O mesmo vale para as tabelas. Não nomeie as tabelas EMPLOYEE_T ou TBL_EMPLOYEES porque, na segunda vez em que é substituído, as coisas ficam realmente confusas.

Não insira informações de tipo em nomes, como “vc_firstname” para varchar ou “flavour_enum”. Também não inclua restrições em nomes de coluna, como “department_fk” ou “employee_pk”.

Na verdade, a única coisa boa sobre * correções que consigo pensar é que você pode usar palavras reservadas como where_t , tbl_order , user_vw . Claro, nesses exemplos, o uso do plural teria resolvido o problema 🙂

Não nomeie todas as chaves “ID”. Chaves referentes à mesma coisa, devem ter o mesmo nome em todas as tabelas. A coluna de ID do usuário pode ser chamada de USER_ID na tabela de usuários e em todas as tabelas que fazem referência ao usuário. A única vez que é renomeado é quando diferentes usuários estão desempenhando funções diferentes, como Message (sender_user_id, receiver_user_id). Isso realmente ajuda ao lidar com consultas maiores.

Em relação ao CaSe:

 thisiswhatithinkofalllowercapscolumnnames. ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME. CamelCaseIsMarginallyBetterButItStillTakesTimeToParse. i_recommend_sticking_with_lower_case_and_underscore 

Em geral, é melhor nomear “tabelas de mapeamento” para corresponder à relação descrita em vez dos nomes das tabelas referenciadas. Um usuário pode ter qualquer número de relações com produtos: user_likes_product , user_bought_product , user_wants_to_buy_product .

Não há “correto” sobre o singular versus o plural – é principalmente uma questão de gosto.

Depende em parte do seu foco. Se você pensa na tabela como uma unidade, ela contém ‘plurals’ (porque contém muitas linhas – então um nome no plural é apropriado). Se você pensar no nome da tabela como identificando uma linha em uma tabela, você preferirá ‘singular’. Isso significa que seu SQL será considerado como trabalhando em uma linha da tabela. Tudo bem, embora geralmente seja uma simplificação excessiva; SQL funciona em conjuntos (mais ou menos). No entanto, podemos ir com singular para as respostas a esta pergunta.

  1. Como você provavelmente precisará de uma tabela ‘user’, outro ‘product’ e o terceiro para conectar os usuários aos produtos, então você precisa de uma tabela ‘user_product’.

  2. Como a descrição se aplica a um produto, você usaria “product_description”. A menos que cada usuário nomeie cada produto para si …

  3. A tabela ‘user_product’ é (ou poderia ser) um exemplo de uma tabela com um ID de produto e um ID de usuário e não muito mais. Você nomeia as tabelas de dois atributos da mesma maneira geral: ‘user_stuff’. Prefixos decorativos como ‘rel_’ realmente não ajudam. Você verá algumas pessoas usando ‘t_’ na frente de cada nome de tabela, por exemplo. Isso não é muita ajuda.

Os plurais não são ruins, desde que sejam usados ​​consistentemente – mas singular é minha preferência.

Eu dispensaria os sublinhados, a menos que você queira delinear um relacionamento muitos-para-muitos; e use um capital inicial porque ajuda a distinguir coisas em ORMs.

Mas há muitas convenções de nomenclatura, portanto, se você quiser usar sublinhados, tudo bem, desde que seja feito de forma consistente.

Assim:

 User UserProduct (it is a users products after all) 

Se apenas um usuário puder ter qualquer produto,

 UserProductDescription 

Mas se o produto for compartilhado pelos usuários:

 ProductDescription 

Se você salvar seus sublinhados para relacionamentos muitos-para-muitos, poderá fazer algo como:

 UserProduct_Stuff 

para formar um M-para-M entre UserProduct e Stuff – não tenho certeza da questão da natureza exata do muitos-para-muitos necessário.

Não há mais correto para usar singular do que plural, onde você ouviu isso? Eu prefiro dizer que a forma plural é mais comum para nomear tabelas de database … e na minha opinião também mais lógica. Na maioria das vezes, a tabela contém mais de uma linha;) Em um modelo conceitual, embora os nomes das entidades estejam frequentemente no singular.

Sobre sua pergunta, se ‘Product’ e ‘ProductDescription’ são conceitos com uma identidade (ou seja, entidades) em seu modelo, eu simplesmente chamaria as tabelas de ‘Produtos’ e ‘ProductDescriptions’. Para tabelas que são usadas para implementar um relacionamento muitos-para-muitos, geralmente uso a convenção de nomenclatura “SideA2SideB”, por exemplo “Student2Course”.