0
A를 정의하는 많은 필드가있는 테이블 A가 있지만 A가 될 수있는 것을 정의하는 많은 필드도 있지만 항상 그런 것은 아닙니다. 이 엔티티를 두 개로 나누는 것에 대해 생각하고 있습니다. 축소 된 A 엔티티는 A와 관련된 필드 만 포함하고 B 엔티티는 A와 관련된 필드를 cointaining하면 "B의 양식을 가정합니다".일대일 관계를 만드는 것이 가치가 있습니까?
("A"는 Mission이라는 테이블이고 "B"는 Monster라는 테이블입니다.) 내 도메인에서 임무는 여러 가지 일 수 있으며, 때로는 괴물입니다. 괴물을 정의하는 많은 필드가 있으므로 원본 미션 테이블은 거대합니다.)
그렇다면 몬스터 테이블을 만들지 말지를 결정 해야겠다. 나는 단지 커다란 미션 테이블을 받아 들일 것인가? 아니면 내가 1 : 1의 관계를 만들어야 하는가? 조인은 꽤 자주 실행되며, 나는 이것에 대해 조금 걱정합니다.
미리 감사드립니다.
"Mission"을로드 할 때마다 "Monster"가 필요할 경우 대개 별도의 테이블과 필요한 조인이 적합하지 않습니다. 그러나 성과와 관련하여 유일한 진실은 측정에서 비롯됩니다. 따라서 각 시나리오에 대한 스키마를 만들고 예상되는 데이터 양을 입력 한 다음 가장 일반적인 사용 사례를 테스트하십시오. –
이후에 테이블 A와 B가 같은 수의 열을 가지면 메모리 공간을 절약하지 않고 조인의 복잡성을 추가하기 만하면됩니다. 성능이 중요한 경우에는 조인을 피하는 것이 좋습니다. 또한 하나의 테이블의 실제 단점이 무엇인지 스스로에게 물어보십시오. coulmns의 수는 거의 추측하지 않습니다. – molig
답변 해 주셔서 감사합니다. 몬스터가 필요할 때마다 내가 몬스터를 격리 할 수 있는지를 연구하면 나는 그대로 테이블을 떠날 것이다. –