2つのテーブルを一緒にマップするテーブルにはどのような名前を付ける必要がありますか？[閉まっている]

2つのテーブルがあるとします。

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

色を形にマップするテーブルを何と呼ぶべきですか？

Table: ???
Columns: ColorId, ShapeId

コンピュータサイエンスの2つだけのハードなものがあります：キャッシュの無効化と命名のものは
- フィルKarlton

many-to-many関係を表すテーブルに適切な名前を付けると、関係が読みやすくなり、理解しやすくなります。素晴らしい名前を見つけるのは簡単なことではありませんが、通常は考えるのに時間をかける価値があります。

例：ReaderとNewspaper。

A Newspaperは多くReaders、a Readerは多くNewspapers

リレーションシップと呼ぶこともできますNewspaperReaderが、のような名前を付けるとSubscription、テーブルの内容がわかりやすくなります。

この名前Subscriptionは、後でテーブルをオブジェクトにマップする場合に備えて、より慣用的になっています。

many-to-manyテーブルの命名規則は、リレーションに関係する両方のテーブルの名前を連結したものです。ColourShapeあなたの場合、賢明なデフォルトになります。それは私がニックDが思う、と述べ思い付いた：2つの偉大な提案StyleとTexture。

ColorShapeMapまたはStyleまたはTextureはどうでしょうか。

興味深い回答の約半分は、多対多の関係を実装するテーブルの一般的な用語を提供し、回答の残りの半分は、この特定のテーブルの名前を示唆しています。

これらのテーブルを交差点テーブルと総称しました。

命名規則に関しては、ほとんどの人は、多対多の関係にある2つのテーブルの融合である名前を付けます。したがって、この場合は「ColorShape」または「」ShapeColorです。しかし、これは人工的で扱いにくいように見えます。

Joe Celkoは、著書「SQLプログラミングスタイル」で、これらのテーブルに何らかの自然言語の名前を付けることを推奨しています。たとえば、ShapeがColorで色付けされている場合、テーブルに名前を付けますColoredBy。次に、この図のように自然に読み取れるダイアグラムを作成できます。

Shape <-- ColoredBy --> Color

逆に、色は形状を着色すると言うことができます：

Color <-- Colors --> Shape

しかし、これは真ん中のテーブルがColor複数の命名規則の場合と同じように見えます。混乱しすぎます。

おそらくColoredBy命名規則を使用することが最も明確です。パッシブボイスを使用すると、命名規則がより明確になるので興味深いです。

わかりやすい限り、テーブルに好きな名前を付けます。

COLOR_SHAPE_XREF

モデルの観点からすると、このテーブルは結合/結果/相互参照テーブルと呼ばれます。私は_XREF、関係を明確にするために、最後に使用するという習慣を続けてきました。

これは関連エンティティであり、それ自体かなり重要な場合があります。

たとえば、TRAINSとTIMESの多対多の関係は、TIMETABLEを引き起こします。

明らかな新しいエンティティ（タイムテーブルなど）がない場合は、2つの単語を一緒に実行して、COLOUR_SHAPEまたは類似のものを指定するのが慣例です。

マッピングテーブルは、これが通常呼ばれるものです。

ColorToShape
ColorToShapeMap

私はこれを結合テーブルと呼ぶDBAと協力してきました。

Colour_Shapeはかなり典型的です-関係に明示的なドメイン固有の名前がない限り。

ジャンクションテーブルと呼ばれるものをよく耳にします。テーブルの名前には結合する名前を付けているので、あなたの場合はColorShapeまたはShapeColorのいずれかです。私はそれが私が行くだろうので色は、形状を持つことよりも色を持っている形状のために、より理にかなっていると思いますShapeColor。

Junction table

または Bridge Table

または Join Table

または Map Table

または Link Table

または Cross-Reference Table

これは、両方のテーブルのキーがJunctionテーブルの複合主キーを形成する多対多の関係に行くときに使用されます。

エンティティの名前を組み合わせて使用​​し、複数に入れることをお勧めします。したがって、テーブルの名前は「多対多」の接続を表します。

あなたの場合：

色+形状= ColorsShapes

中間テーブルまたは結合テーブル

好みに応じて「ColorShapes」または「ColorShape」と名付けます

連想という言葉も聞いたことがありますテーブル使用されます。

テーブルの名前は、ColorShapeAssociations各行がその色とその形状の間の関連を表すことを意味している場合があります。行が存在するということは、色がその形になることと、形がその色になることを意味します。特定の色のすべての行は、その色が関連付けられているすべての形状のセットであり、特定の形状の行は、その形状が入ったすべての色のセットです...

一般に、ほとんどのデータベースには、インデックスや主キーなどに何らかの命名規則があります。PostgreSQLでは、次の命名が提案されています。

• 主キー：tablename_columnname_ pkey
• 一意制約：tablename_columnname_ キー
• 排他的制約：tablename_columnname_ excl
• 他の目的のためのインデックス：tablename_columnname_ idx
• 外部キー：tablename_columnname_ fkey
• シーケンス：tablename_columnname_ seq
• トリガー：tablename_actionname_after | before_ trig

あなたのテーブルは私にリンクされたテーブルです。上記の命名に合わせるために、以下を選択します。

• リンクテーブル：tablename1_tablename2_ lnk

テーブルオブジェクトのリストでは、リンクテーブルはtablename1の後になります。これは視覚的に魅力的かもしれません。しかし、他の人が提案したように、リンクの目的を説明する名前を選択することもできます。これは、id列の名前を短く保つのに役立つ場合があります（リンクに独自の名前付きIDが必要で、他のテーブルで参照されている場合）。

• または好きなテーブル：purposename_ lnk

私はいつも「ハンバーガーテーブル」という言葉に不慣れでした。理由がわからない-それはちょうどいい音。

ああ、そして私はテーブルをShapeColorまたはColorShapeと呼びますが、どちらがより一般的に使用されるテーブルであるかによって異なります。

「多対多」テーブル。私はそれを「ColourShape」またはその逆と呼びます。

これほど恣意的なものに答えるのは難しいですが、私は、基礎となる関係の一般的な説明ではなく、実際のドメインで何かにちなんで名前を付けることを好む傾向があります。

多くの場合、この種のテーブルは、ドメインモデルにとってよりリッチなものに進化し、リンクされた外部キーを超えた追加の属性を引き受けます。

たとえば、色に加えてテクスチャを保存する必要がある場合はどうでしょうか？SHAPE_COLORテーブルを拡張してそのテクスチャを保持することは、少しファンキーに思えるかもしれません。

一方、今日の要件に基づいて十分な情報に基づいて決定し、後で追加の要件が導入されたときにリファクタリングする準備をしていることについても、言うべきことがあります。

そうは言っても、後で導入される追加の表面のような特性があるだろうという洞察があれば、それをSURFACEと呼びます。そうでなければ、私はそれをSHAPE_COLORまたはある種の何かと呼んで、より差し迫った設計問題に進むことに問題はないでしょう。

たぶんだけColoredShape？

質問を受けるかどうかわかりません。これはこの特定のケースについてですか、それとも一般的なガイドラインを探していますか？

結合するテーブルの正確な名前で名前を付けます= ColorShape。

Developer Artの関連性に忠実に、

ColorShape

通常の命名規則になります。ER図では、それは関係になります。

これを相互参照表と呼びます。

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

私はその意味に応じて使用しr_shape_colorsたりr_shape_colorします。この場合の
r_代わりにxref_なります。

私の投票は、テーブルを最もよく表す名前です。この場合はそうかもしれませんShapeColorが、多くの場合、連結とは異なる名前の方が適しています。私は読みやすさが好きです。つまり、接尾辞、アンダースコア、接頭辞はありません。

私は個人的には、下線を付けてColour_Shapeに行きます。この規則がかなり上向きになるのを見たからです。[しかし、おそらくこれを行うにはもっと「詩的な」方法があるという他の投稿にも同意する]。

外部キーもこの結合テーブルに構築する必要があることを覚えておいてください。これは、関係の識別にも役立つ、カラーテーブルとシェイプテーブルの両方を参照します。

私が個人的に好きなテーブルを結合するために私がよく見ている慣習は「Colour_v_Shape」で、これは俗に「対テーブル」と呼ばれていると聞いたことがあります。

テーブルが多対多の関係を表していることが一目で非常に明確になり、複合語を形成する可能性のある2つの単語、たとえば「バター」を連結しようとすると、（まれではありますが）混乱する状況を回避できます。また、「Milk」は「ButterMilk」になる可能性がありますが、「Buttermilk」というエンティティも表す必要がある場合はどうでしょうか。

このようにすると、「Butter_v_Milk」と「Buttermilk」ができます-混乱はありません。

また、元の質問にFoo Fightersの参照があると思います。