동일한 테이블에 유사한 엔티티를 저장하고 데이터베이스의 여러 테이블에 저장하는 경우

Question

데이터베이스에 표시 할 엔티티가 두 개 있습니다.
- 속성 (x, y, z, r)이있는 엔티티 A입니다.
- 속성 (x, y, z, s)을 갖는 엔티티 B.

2 개의 엔티티에는 3 개의 동일한 속성이 있고 1 개의 다른 속성 만 있습니다. 매우 유사하지만 비즈니스 로직과 함께 사용되지는 않습니다.

1. 두 개의 별도의 테이블, 각 엔티티를 생성합니다

   다음을 대표하는 (어쩌면 그 이상)이 방법을있다.
   이것은 직접적인 방법입니다. 상대적으로 작은 두 개의 테이블과보다 명확한 쿼리 및 비즈니스 로직을 제공합니다. 그러나 테이블은 거의 동일하므로 분명히 중복됩니다 (동일한 속성이 3 이상이라는 것을 상상해보십시오).

2. 5 개의 속성 (x, y, z, r, s, 유형)으로 하나의 공유 테이블을 생성하십시오.
   (type)은이 행에 표시되는 엔터티의 유형 (A 또는 B)을 나타냅니다. 이것은 속성 (r)과 (s)가 필수가 아니므로 엔티티의 유형을 결정하기 위해 의존 할 수 없다고 가정합니다.
   예를 들어, 이것은 Wordpress에서 게시물 및 페이지 (및 다른 몇 가지 엔터티)를 나타내는 데 사용되는 접근 방법입니다. null 필드를 많이 포함하는 상대적으로 큰 테이블 하나와 비교적 지저분한 쿼리 및 비즈니스 로직을 사용하여 행을 필터링하고 논리적으로 엔티티를 분리합니다. 하지만 두 개의 중복 테이블 대신 하나의 고유 한 테이블로 끝납니다.

내 질문은 : 다른 장점과 각 방법의 단점은 무엇

1?

2 두 가지 접근 방식의 사용 사례는 무엇입니까?

3 엔티티의 수가 증가했거나 관계가 복잡 해지면 다른 엔티티가 분명히 나을 것인가? 2 개의 엔티티 대신 20 개의 엔티티가있는 것처럼, 엔티티는 데이터베이스의 다른 엔티티와 다 대다 관계를 유지합니다.

감사합니다.

Answer 1

2 개의 엔티티는 3 개의 동일한 속성과 1 개의 다른 속성 만가집니다. 매우 비슷하지만 은 관련이 없으므로과 함께 사용되며 비즈니스 논리에서 함께 사용되지 않습니다.

스키마/모델에 대한 지식이 없으면 두 엔터티가 유사한 특성을 갖고 있지만 비즈니스 논리에서 "관련 없음"이라고 말하면 나는 접근 방식 1을 강력히 권합니다. 관련이없는 경우 각 개체가 공통으로 갖고있는 속성의 수에 영향을 미칩니다. 비슷한 속성으로 인해 관련없는 데이터를 같은 테이블에 저장하는 것은 좋은 데이터베이스 디자인이 아닙니다. 스키마에 대한 자세한 내용은 의사 결정에 도움이 될 것입니다.