O que devo nomear uma tabela que mapeie duas tabelas? [fechado

StackOverflow https://stackoverflow.com/questions/1813321

Pergunta

Digamos que eu tenho duas mesas:

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

Como devo chamar a tabela que mapeia a cor para moldar?

Table: ???
Columns: ColorId, ShapeId
Foi útil?

Solução

Existem apenas duas coisas difíceis na ciência da computação: invalidação do cache e nomear coisas
-- Phil Karlton

Criando um bom nome para uma tabela que representa um many-to-many O relacionamento facilita a leitura e a compreensão do relacionamento. Às vezes, encontrar um ótimo nome não é trivial, mas geralmente vale a pena passar algum tempo pensando.

Um exemplo: Reader e Newspaper.

UMA Newspaper tem muitos Readers e a Reader tem muitos Newspapers

Você poderia chamar o relacionamento NewspaperReader Mas um nome como Subscription Pode transmitir melhor sobre o que é a tabela.

O nome Subscription Também é mais idiomático, caso você queira mapear a tabela para objetos posteriormente.

A convenção para nomear many-to-many As tabelas são uma concatenação dos nomes de ambas as tabelas envolvidas na relação. ColourShape seria um padrão sensato no seu caso. Dito isto, acho que Nick D surgiu Duas ótimas sugestões: Style e Texture.

Outras dicas

Que tal ColorhapeMap ou Estilo ou Textura.

Interessante sobre metade das respostas fornece um termo geral para qualquer tabela que implementa um relacionamento de muitos para muitos, e a outra metade das respostas sugere um nome para esta tabela específica.

Eu chamei estas mesas tabelas de interseções geralmente.

Em termos de nomeação de convenções, a maioria das pessoas dá um nome que é um amálgama das duas tabelas no relacionamento muitos para muitos. Então, neste caso, "ColorShape" ou "ShapeColor. "Mas acho que isso parece artificial e estranho.

Joe Celko recomenda em seu livro "SQL Programming Style" para nomear essas tabelas de alguma maneira de linguagem natural. Por exemplo, se uma forma for colorida por uma cor, nomeie a tabela ColoredBy. Então você pode ter um diagrama que mais ou menos leituras naturalmente assim:

Shape <-- ColoredBy --> Color

Por outro lado, você poderia dizer uma cor de cor a uma forma:

Color <-- Colors --> Shape

Mas isso parece que a mesa do meio é a mesma coisa que Color com uma convenção de nomeação plural. Muito confuso.

Provavelmente mais claro para usar o ColoredBy convenção de nomes. Interessante que o uso da voz passiva torna a convenção de nomenclatura mais clara.

Nomeie a tabela o que quiser, desde que seja informativo:

COLOR_SHAPE_XREF

Do ponto de vista do modelo, a tabela é chamada de tabela de referência de junção/corrollary/cruzamento. Eu mantive o hábito de usar _XREF No final, para tornar o relacionamento óbvio.

Uma tabela de mapeamento é como isso geralmente é chamado.

ColorToShape
ColorToShapeMap

Isto é um Entidade associativa e muitas vezes é significativo por si só.

Por exemplo, muitos a muitos relacionamentos entre trens e horários dão origem a um cronograma.

Se não houver uma nova entidade óbvia (como o horário), a convenção é executar as duas palavras juntas, dando colour_shape ou similar.

Eu costumo ouvir isso chamado tabela de junção. Nomei a tabela da tabela pelo que ela se junta, então, no seu caso, a cor de cores ou o shapecolor. Eu acho que faz mais sentido para uma forma ter uma cor do que para uma cor ter uma forma, então eu iria com ShapeColor.

Eu trabalhei com dbas que chamam de Junte -se à mesa.

Colour_Shape é bastante típico - a menos que o relacionamento tenha um nome específico de domínio explícito.

Junction table

OU Bridge Table

OU Join Table

OU Map Table

OU Link Table

OU Cross-Reference Table

Isso entra em uso quando optamos por muitos relacionamentos, onde as chaves de ambas as tabelas formam a chave primária composta da tabela de junção.

Tabela intermediária ou a Junte -se à mesa

Eu nomearia "colorishapes" ou "colorhape", dependendo da sua preferência

Eu recomendo usar uma combinação dos nomes das entidades e colocá -los no plural. Assim, o nome da tabela expressará a conexão "muitos para muitos".

No seu caso:

Cor + forma = fodas de cores

Eu também ouvi o termo Associativo tabela usada.

Um nome para sua tabela pode ser ColorShapeAssociations o que significa que cada linha representa uma associação entre essa cor e essa forma. A existência de uma fila implica que a cor vem nessa forma e que a forma vem nessa cor. Todas as linhas com uma cor específica seriam o conjunto de todas as formas às quais a cor está associada, e as linhas para uma forma específica seria o conjunto de todas as cores em que a forma veio ...

Em geral, a maioria dos bancos de dados possui algum tipo de convenção de nomenclatura para índices, chave primária e assim por diante. No PostgreSQL, a seguinte nomeação foi sugerida:

  • Chave primária: tablename_columnname_pkey
  • Restrição exclusiva: tablename_columnname_chave
  • restrição exclusiva: tablename_columnname_excl
  • Índice para outros propósitos: tablename_columnname_idx
  • Chave estrangeira: tablename_columnname_fkey
  • Sequência: tablename_columnname_Seq
  • gatilhos: tablename_actionName_after | antes_trig

Sua mesa é uma tabela vinculada para mim. Para ficar de acordo com a nomeação acima, eu escolheria o seguinte:

  • Tabela vinculada: tablename1_tablename2_lnk

Em uma lista de objetos da tabela, a tabela vinculada será após o tableName1. Isso pode ser visualmente mais atraente. Mas você também pode escolher um nome que descreva o objetivo do link como os outros sugeriram. Isso pode ajudar a manter o nome da coluna de identificação curta (se o seu link deve ter seu próprio ID nomeado e for referenciado em outras tabelas).

  • ou tabela curtida: Purposename_lnk

Eu sempre fui parcial com o termo "tabela de hambúrguer". Não sei por que - parece bom.

Ah, e eu chamaria a tabela ShapeColor ou ColorShape, dependendo da tabela mais comumente usada.

Tabela de "muitos muitos". Eu chamaria isso de "coroushape" ou vice -versa.

É difícil responder a algo tão arbitrário quanto esse, mas eu prefiro a idéia de Tosh de nomeá -lo depois de algo no domínio real, em vez de uma descrição genérica dos relacionamentos subjacentes.

Muitas vezes, esse tipo de tabela evolui para algo mais rico para o modelo de domínio e assume atributos adicionais acima e além das chaves estrangeiras vinculadas.

Por exemplo, e se você precisar armazenar uma textura além da cor? Pode parecer um pouco divertido expandir a tabela Shape_color para manter sua textura.

Por outro lado, também há algo a ser dito para tomar uma decisão bem informada com base nos requisitos que você tem hoje e estar preparado para refatorar quando requisitos adicionais forem introduzidos posteriormente.

Tudo isso dito, eu chamaria de superfície se tivesse insight de que haveria propriedades adicionais semelhantes à superfície introduzidas posteriormente. Caso contrário, eu não teria problemas para chamá -lo de shape_color ou algo do tipo e passar para problemas de design mais prementes.

Talvez apenas ColoredShape?

Não tenho certeza se recebo a pergunta. É sobre esse caso específico ou você está procurando diretrizes gerais?

Eu o nomearia com os nomes exatos das tabelas que estão sendo unidas = colorida.

Em adição ao que a arte do desenvolvedor relatou, 

ColorShape

seria uma convenção de nomenclatura usual. No diagrama de ER, seria uma relação.

Chame de tabela de referência cruzada.

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

Eu usaria r_shape_colors ou r_shape_color dependendo do seu significado.
r_ seria um substituto para xref_ nesse caso.

Meu voto é para um nome que descreva melhor a tabela. Nesse caso, pode ser ShapeColor Mas, em muitos casos, um nome diferente de uma concatenação é melhor. Eu gosto de legibilidade e para Eu, isso significa que não há sufixos, sublinhados e prefixos.

Eu pessoalmente iria para o Colour_Shape, com o sublinhado: só porque eu vi essa convenção aparecer bastante. [Mas concorde com os outros posts aqui que provavelmente existem mais maneiras "poéticas" de fazer isso].

Lembre -se de que as chaves estrangeiras também devem ser construídas nesta tabela de junção, o que referenciaria as tabelas de cores e formas que também ajudariam a identificar o relacionamento.

Uma convenção que vejo muito para ingressar nas mesas que eu pessoalmente gosto é 'colour_v_shape', que ouvi pessoas se referirem coloquialmente como 'versus tabelas'.

Fica muito claro que a mesa representa um relacionamento de muitos para muitos e ajuda a evitar isso (embora raro) uma situação confusa quando você tenta concatenar duas palavras que, de outra forma, poderiam formar uma palavra composta, por exemplo, 'manteiga' e 'leite' pode se tornar 'leitelho', mas e se você também precisasse representar uma entidade chamada 'leitelho'?

Fazendo dessa maneira, você teria 'Butter_v_milk' e 'Buttermilk' - sem confusão.

Além disso, eu gosto de pensar que há uma referência a Foo Fighters na pergunta original.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top