카이제로
58
2018-09-14 12:00:52
4
527

외래키로 자연키와 인조키를 사용하는 것에 대한 궁금증이 있습니다.


1. 첫 질문은 질문이라기 보단 의견을 묻는 것이겠네요.

기본키로 자연키와 인조키의 관한 글을 찾아본 적이 있는데. 이에 대한 명확히 '이것만이 정답이다.'라는 케이스는 없겠으나 그래도 자연키에 지정한 것이 어느 날 개념자체가 바뀌어서 고생하는 케이스가 있으니 그래도 인조키의 사용을 추천하는 글이 있었습니다. (그 때 사용된 예시는 정부의 주민번호 수집금지에 대한 것 이었습니다.)

기본키로서 자연키와 인조키 둘 중 하나를 정해서 사용하는 것과 (물론 자연키를 사용할 때 케이스바이케이스)

아니면 모든 테이블을 인조키로서 활용하는 것. 어느 것을 선호하시나요?


2. 1번에 대한 고민의 연장선상인데 테이블을 구성할 때

위와 같은 테이블과


이와 같은 테이블이 있었을 때에 고민을 해보았는데

구매정보만을 검색할 때 자신이 유저의 이름에 대한 정보만 가지고 있을 때

위의 테이블은 상품 구매 정보 테이블만을 검색하면 가능하기에 편하지만

밑의 테이블은 유저정보를 통해 인덱스를 획득한 후 상품 구매 정보를 얻어와야 해서

쿼리문의 복잡도와 JOIN의 불편함이 있을 수 있을거라는 생각이 들었습니다.


어떤 방법이 좋을까요. 라는 말보다는 어느 것을 피해야 할 까요. 라는 질문을 드리고 싶습니다.

케이스 바이 케이스라는 답변일거라는 생각이 들긴 합니다만 제가 걱정하는 것은

'이것만은 피해야 한다.' 라는 답이거든요. 둘 중에 '이것만은 피해야 한다.' 라는 케이스가 있다면

알려 주시면 감사하겠습니다.

0
0
  • 답변 4

  • ....
    2018-09-14 12:20:06

    유저정보, 상품정보의 인덱스를

    상품구매 정보테이블에서 보여주는 것은 좋다고 생각됩니다.


    하지만 상품정보 테이블의 필드나 레코드의 수가 적은 경우에는

    별도의 테이블로 따로 구분하지않고

    상품구매정보테이블 하나로 합치는 것이 좋다고 생각됩니다.


    1
  • 카이제로
    58
    2018-09-14 13:36:11

    /

    의견 감사드립니다. 일단 DB가 어디까지 확장될지에 대해서는 아직까지 미지수라서..

    나중에 고치기는 무엇하니 일단 인조키로 만드는 방향으로 생각해보겠습니다.

    0
  • ....
    2018-09-14 14:05:15

    사전에 그것까지 아셔야합니다.

    또 확장성을 생각하신다면

    무엇이 확장이 될 예정이고 확실한지 아셔야합니다.


    다시말해서 확장성을 고려한다고

    테이블의 모든 필드를 추가, 제거하면

    시스템이 엉망이 될 가능성이 커집니다.


    일단 정리하고 어떤 시스템으로 갈지 확실히 정할 것은 정하고 가시고

    변하는 것은 미미해야 안정된 시스템이 됩니다.


    시스템 구조의 변화가

    에러날 여지를 주면 안된다는 것이죠

    1
  • 카이제로
    58
    2018-09-14 14:42:33

    /

    조언 감사드립니다. 당연히 확장성을 고려한다는 측면만을 생각했었네요.

    DB 쪽은 그런 것에 더 민감하게 생각하게되나봅니다.

    확실하게 설계 방향을 정해놓고 해야겠네요.

    0
  • 로그인을 하시면 답변을 등록할 수 있습니다.