열을 새 테이블로 분리 할 때

Question

나는 회사, 고객, 공급 업체 등의 테이블에 모두 주소 정보 관련 열이 있습니다.

새 테이블 '주소'를 만들고 모든 주소 열을 분리해야 하는지를 판단하려고합니다.

모든 테이블에 주소 열을 사용하는 것은 사용하기 쉽고 쿼리가 쉽지만 좋은 디자인 관점에서 올바른 방법인지 확실하지 않습니다. 동일한 열을 몇 개 테이블 이상 반복하면 호기심이 생깁니다.

주소 내용은 중요하지 않습니다. 의사 결정 과정에서이 주소를 확인하거나 사용하지 않을 것이며, 정보와 관련이 있습니다. 현재 주소 정보가있는 5 개의 테이블을보고 있습니다.

Answer 1

모든 디자인 질문에 대한 대답은 다음과 같습니다.

에 달려 있습니다.

기본적으로 주소 경우 고객마다 주소가 두 개 이상 있는지 여부에 따라 달라집니다. 두 개 이상인 경우 새 Addresses 테이블에 넣고 각 주소에 CustomerID를 지정하십시오. 일반 주소 테이블을 작성하고이를 회사/고객/공급 업체 테이블에 맵핑하는 것은 과잉입니다 (대부분의 경우, 의존적입니다!).

개체 간의 다 대다 관계로 주소를 매핑하는 것은 종종 과도한 (위험한) 일입니다. 이렇게하면 주소가 마술처럼 바뀔 수 있습니다.

하나의 큰 규칙은 다음과 같습니다. 간단하게하십시오!

Answer 2

해당 주소를 자신의 테이블 범위 내에서만 사용하는 경우, 테이블을 자신의 테이블로 이동하는 데 실제 이점이 없을 수 있습니다.

기본적으로 노력할 가치가있는 것 같지 않습니다.

Answer 3

예. 주소를 고유 한 테이블로 구분해야합니다. 물어 보는 것은 영리한 일입니다. 여기에서 핵심은 주소의 일반적인 형식이 누구인지에 관계없이 동일하다는 것입니다. 고객, 회사, 공급 업체 ... 모두 주소가 같은 필드가 있습니다.

주소를 원자 요소로 처리하는 것이 가치가있는 이유는 무엇입니까? 즉, 주소와 관련된 모든 기능을 일반화하고 여러 테이블을 다루는 것에 대해 걱정할 필요가없고 한 번 발생할 수있는 관련 스키마 드리프트 만 처리 할 수 ​​있습니다.

Answer 4

동일한 테이블이 회사 테이블과 공급 업체 테이블에 모두 입력되어 있고 주소가 항상 두 테이블에서 같아야한다면 해당 테이블로 주소를 이동시켜야합니다. 다른 세 테이블에서 외래 키를 가지고 있습니다. 그렇게하면 변경 될 때 한 지점에서만 업데이트하면됩니다.

세 개의 테이블이 서로 완전히 독립적 인 경우 데이터를 다른 테이블로 옮기는 것이별로 도움이되지 않으므로 그대로 두는 것이 좋습니다.

Answer 5

Database Normalization이라고합니다. 그리고 예, 당신이 그들을 분할하고 싶다면, 다른 이유가 없다면, 앞으로 필요하다면 코드와 쿼리가있을 때 훨씬 어려울 것이기 때문입니다.

원칙적으로 데이터베이스를 3 차 표준 형식으로 설계해야합니다 (간단한 애플리케이션이라 할지라도). 성능이나 논리적 인 이유가없는 경우가있을 수 있지만, 항상 시작하려고합니다. 그것은 제 3 표준 형태이며, 올바른 방법을 알고 난 후에 속임수를 배웁니다.)

EDIT :이 기사를 확장하고 다른 게시물에 작성한 주석을 추가하려면 코드 작성과 리팩터링에서 단순한 디자인으로 시작하는 것이 중요하다고 생각합니다. 복잡하고 더 확실한 객체 지향 원리가 적절할 것입니다. 그러나 프로덕션에있는 데이터베이스를 리팩토링하는 것은 그렇게 간단하지 않습니다. ROI에 관한 것입니다. 정규화 된 데이터베이스를 처음부터 디자인하는 것은 너무 쉽습니다. 잘못 설계된 데이터베이스의 결과는 치명적일 수 있으며 일반적으로 실현되기까지는 너무 늦습니다.

Answer 6

전적으로 데이터베이스의 목적에 달려 있다고 생각합니다. 분명히 모든 주소 정보는 구조적으로 동일하며 이론적 관점에서 모두 부모 테이블에서 키로 연결된 단일 테이블에 있어야합니다.

그러나 성능 및 쿼리 측면에서 보면 해당 테이블에 유지하면보고 측면에서 단순화됩니다. 그들은 상관없이 등 픽업 위치, 배달 위치, 고객

에있어 여부의 모든 위치에있어 -

내 현재의 회사와 상황 주소가 실제로 논리적으로 동일 [물류]이 내 경우, 나는 분명히 모두 한 테이블에 있어야한다고 말하고 싶다. 그러나 공급 업체, 고객, 연락처 정보 관점에서 볼 때 이론적으로 한 테이블에 주소를 갖는 것이 좋지만 실제로는 데이터가 거의 없기 때문에 실제로 많이 구입하지 않을 것이라고 말하고 싶습니다. 되풀이된다.

Answer 7

나는 Dave와는 의견이 다릅니다. 다 대 다 접근 (주소 < -> User)은 안전하고 매우 유용합니다.

고객이 이동하면 주소 테이블의 주소가 변경되지 않습니다. 대신 주소 테이블에 새 주소가 있으며 고객 등은 해당 레코드에 연결됩니다. 새 주소가 아직 표에없는 경우 주소가 추가됩니다.

주소 레코드 자체가 변경됩니까? 예,이 같은 경우 :

• 그것은 주소가
• 미국 우편 서비스는 거리 이름을 변경하는 오타가 밝혀

하나 개의 테이블에있는 모든 주소를 넣는 곳이은 매우 상황입니다 반복하지 않고 지불한다; 어떤 다른 배열은 짜증나고 반복적 인 데이터 입력을 필요로합니다.

물론 데이터베이스가 악용되면 다 - 대 - 다 관계를 피하는 것이 더 안전합니다. 하지만 그 토큰에 의해 데이터베이스가 불량 일 경우 모든 것을 인쇄하고 파일 캐비닛에 저장 한 다음 종이 복사본에 대한 모든 트랜잭션을 확인하는 것이 좋습니다. 따라서 "오용 방지"는 좋은 디자인 원칙이 아닙니다.