두 테이블을 함께 매핑하는 테이블의 이름은 무엇입니까?

두 테이블을 함께 매핑하는 테이블의 이름은 무엇입니까? [닫은]

---

두 개의 테이블이 있다고 가정 해 봅시다.

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

색상을 모양에 매핑하는 테이블을 무엇이라고해야합니까?

Table: ???
Columns: ColorId, ShapeId

---

컴퓨터 과학에는 캐시 무효화와 이름 지정 문제
, 필 칼튼의 두 가지 어려운 점이 있습니다.

many-to-many관계 를 나타내는 테이블의 이름이 좋으면 관계를 읽고 이해하기가 더 쉽습니다. 때로는 위대한 이름을 찾는 것이 사소한 것이 아니지만 일반적으로 생각하는 데 시간을 할애 할 가치가 있습니다.

예 : Reader및 Newspaper.

A는 Newspaper많은이 Readers과는 Reader많이있다Newspapers

관계를 호출 할 수는 NewspaperReader있지만 Subscription테이블 이름 에 대해 더 잘 전달할 수 있습니다.

Subscription나중에 테이블을 객체에 매핑하려는 경우 이름 이 더 관용적입니다.

many-to-many테이블 이름 지정 규칙 은 관계에 관련된 두 테이블의 이름을 연결 한 것입니다. ColourShape귀하의 경우 합리적인 기본값이 될 것입니다. 그게 내가 닉 D 생각했다 내놓았다 : 두 위대한 제안 Style하고 Texture.

---

ColorShapeMap 또는 Style 또는 Texture 는 어떻습니까 ?

---

답의 절반 정도가 흥미 롭다면 다 대다 관계를 구현하는 테이블에 대한 일반적인 용어를 제공하고 나머지 절반은이 특정 테이블의 이름을 제안합니다.

이 테이블 교차점 테이블을 일반적으로 불렀습니다 .

명명 규칙과 관련하여 대부분의 사람들은 다 대다 관계에서 두 테이블의 합병 인 이름을 지정합니다. 따라서이 경우 " ColorShape"또는 " ShapeColor." 그러나 나는 이것이 인위적이고 어색한 것처럼 보입니다.

Joe Celko는 자신의 저서 "SQL Programming Style"에서 이러한 테이블의 이름을 자연 언어로 추천합니다. 예를 들어, 셰이프에 색상이 지정된 경우 테이블 이름을 지정하십시오 ColoredBy. 그러면 다음과 같이 자연스럽게 읽거나 읽는 다이어그램을 가질 수 있습니다.

Shape <-- ColoredBy --> Color

반대로, 당신은 색깔을 모양이라고 말할 수 있습니다 :

Color <-- Colors --> Shape

그러나 이것은 중간 테이블이 Color복수 명명 규칙과 같은 것으로 보입니다 . 너무 혼란 스럽다.

아마도 ColoredBy명명 규칙 을 사용하는 것이 가장 분명합니다 . 패시브 음성을 사용하면 이름 지정 규칙이 더 명확 해집니다.

---

정보를 제공하는 한 원하는대로 테이블 이름을 지정하십시오.

COLOR_SHAPE_XREF

모델 관점에서 테이블을 조인 / 롤러 리 / 상호 참조 테이블이라고합니다. 나는 _XREF관계를 분명하게하기 위해 마지막 에 사용하는 습관을 유지했습니다 .

---

이것은 연관 엔티티 이며 종종 자체적으로 중요합니다.

예를 들어, TRAINS와 TIMES 사이의 다 대다 관계는 TIMETABLE을 발생시킵니다.

시간표와 같은 명백한 새로운 실체가 없다면, 두 단어를 함께 실행하여 COLOUR_SHAPE 또는 이와 유사한 것을 부여하는 것이 관례입니다.

---

매핑 테이블이 일반적으로 호출됩니다.

ColorToShape
ColorToShapeMap

---

DBA와 함께 조인 테이블 이라고 불렀습니다 .

관계에 명시적인 도메인 특정 이름이없는 한 Colour_Shape는 상당히 일반적입니다.

---

나는 보통 정션 테이블이라고 들었습니다. 테이블의 이름을 조인하여 ColorShape 또는 ShapeColor로 지정합니다. Shape가 Shape를 갖는 것보다 Color를 갖는 것이 더 의미가 있다고 생각합니다 ShapeColor.

---

Junction table

또는 Bridge Table

또는 Join Table

또는 Map Table

또는 Link Table

또는 Cross-Reference Table

이것은 두 테이블의 키가 접합 테이블의 복합 기본 키를 형성하는 다 대다 관계를 수행 할 때 사용됩니다.

---

중간 테이블 또는 조인 테이블

원하는대로 "ColorShapes"또는 "ColorShape"로 이름을 지정합니다.

---

I recommend using a combination of the names of entities and put them in the plural. Thus the name of the table will express connection "many-to-many".

In your case:

Color + Shape = ColorsShapes

---

I've also heard the term Associative table used.

a name for your table might be ColorShapeAssociations meaning that each row represents an association between that color and that shape. The existence of a row implies that the color comes in that shape, and that the shape comes in that color. All rows with a specific color would be the set of all shapes the color is associated with, and the rows for a specific shape would be the set of all colors that shape came in...

---

In general most databases have some sort of naming convention for indexes, primary key and so forth. In PostgreSQL the following naming has been suggested:

• primary key: tablename_columnname_pkey
• unique constraint: tablename_columnname_key
• exclusive constraint: tablename_columnname_excl
• index for other purposes: tablename_columnname_idx
• foreign key: tablename_columnname_fkey
• sequence: tablename_columnname_seq
• triggers: tablename_actionname_after|before_trig

Your table is a linked table to me. To stay in line with the naming above I would choose the following:

• linked table: tablename1_tablename2_lnk

In a list of table objects the linked table will be after tablename1. This might be visually more appealing. But you could also choose a name that describes the purpose of the link like others have suggested. This might help to keep the name of the id column short (if your link must have its own named id and is referenced in other tables).

• or liked table: purposename_lnk

---

I've always been partial to the term "Hamburger Table". Don't know why - it just sounds good.

Oh, and I would call the table ShapeColor or ColorShape depending on which is the more commonly used table.

---

"Many-Many" table. I'd call it "ColourShape" or vice versa.

---

It's hard to answer something as arbitrary as this, but I tend to prefer tosh's idea of naming it after something in the actual domain instead of some generic description of the underlying relationships.

Quite often this sort of table will evolve into something richer for the domain model and will take on additional attributes above and beyond the linked foreign keys.

For example, what if you need to store a texture in addition to color? It might seem a bit funky to expand the SHAPE_COLOR table to hold its texture.

On the other hand, there's also something to be said for making a well-informed decision based on what requirements you have today and being prepared to refactor when additional requirements are introduced later.

All that said, I would call it SURFACE if I had insight that there would be additional surface-like properties introduced later. If not, I'd have no problems calling it SHAPE_COLOR or something of the sort and moving on to more pressing design problems.

---

Maybe just ColoredShape?

I'm not sure I get the question. Is this about this specific case or are you looking for general guidelines?

---

I would name it with the exact names of the tables being joined = ColorShape.

---

In adiction to what Developer Art has related,

ColorShape

would be a usual naming convention. In ER diagram, it would be a relation.

---

Call it a cross reference table.

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

---

I'd use r_shape_colors or r_shape_color depending on its meaning.
r_ would a replacement for xref_ in this case.

---

My vote is for a name that describes the table best. In this case it might be ShapeColor but in many cases a name different from a concatenation is better. I like readability and for me, that means no suffixes, no underscores and no prefixes.

---

I would personally go for Colour_Shape, with the underscore: just because I have seen this convention turn up quite a bit. [but agree with the other posts here that there are probably more 'poetic' ways of doing this].

Bear in mind that the foreign keys should also be built on this join table which would reference both the Colour & Shape tables which would also help with identifying the relationship.

---

A convention I see a lot for joining tables that I personally like is 'Colour_v_Shape', which I've heard folk refer to colloquially as 'versus tables'.

It makes it very clear at a glance that the table represents a many-to-many relationship, and helps avoid that (albeit rare) confusing situation when you try to concatenate two words that might otherwise form a compound word, for example 'Butter' and 'Milk' may become 'ButterMilk', but what if you also needed to represent an entity called 'Buttermilk'?

Doing it this way, you'd have 'Butter_v_Milk' and 'Buttermilk' - no confusion.

Also, I like to think there's a Foo Fighters reference in the original question.

참고URL : https://stackoverflow.com/questions/1813321/what-should-i-name-a-table-that-maps-two-tables-together