O que devo nomear uma tabela que mapeie duas tabelas? [fechado
-
06-07-2019 - |
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
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.
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.