작성한 질문수 14

1

안녕하세요, Dom poo님!! 정말 좋은 질문 감사합니다! 😊

제가 궁금한건 여기서 User와 Book 테이블을 수정하여, 예를들면 User테이블에는 OneToMany로 Book의 id를 가리킬 수 있는 필드를, Book테이블에는 ManyToOne으로 User의 id를 가리킬 수 있는 필드를 추가하여 개발할 수도 있지 않나 싶어서요!

라고 말씀해주셨는데요!!!

두 가지를 나눠서 생각해볼게요!

• User 테이블 : OneToMany로 Book의 id를 가리킬 수 있는 필드

• Book 테이블 : User의 id를 가리킬 수 있는 필드

[Uesr 테이블]

결론부터 말씀드리면, User 테이블에 OneToMany로 Book의 id를 가리킬 수 있는 필드를 넣기는 애매합니다!

그 이유는, OneToMany (즉 1 : N 관계) 때문인데요!! 표 데이터를 생각해보시면 하나의 유저 데이터가 여러개의 책 데이터를 가리키는 것은 다소 어려움이 있어요! 만약 하나의 유저 데이터가 여러 책 데이터를 가리키게 하고 싶다면, 1) 책 데이터가 추가될 때마다 필드가 추가로 생기거나 2) 책 데이터가 추가될 때마다 특정 필드가 업데이트 되어야 합니다.

전자의 경우 테이블의 필드를 동적으로 추가하는 것은 애매하고요!! (계속해서 alter table add column 이 수행되어야 하기 때문이죠!) 후자의 경우 특정 필드를 계속 업데이트 할 수는 있지만, 코드가 깔끔하지 않고 유지보수가 어렵게 됩니다.

[Book 테이블]

Book 테이블 역시 user_id만 가지고 있기에는 애매한 부분이 있습니다.

책 A를 1번 유저가 빌렸다가 반납했다가~ 2번 유저가 다시 빌렸다가 반납하는 경우 책 A를 1번 유저도 빌리고 2번 유저도 빌렸다는 기록이 필요합니다. 또한 대출과 반납 여부를 기록하고 있어야 하고요!

결론적으로 말씀해주신 방법이 불가능한 것은 아니나, 확장성이나 유지보수성을 고려하면 개발하기 어려운 형태가 됩니다!! 😭😭 관련해서 정규화, 역정규화 라는 키워드로 자료를 조금 더 찾아보시면 좋을 것 같아요!

[추가적인 의견]

객체지향적으로 생각했을 때 User와 Book은 객체지만, '대출기록'은 객체가 아니라 객체간의 관계 같아서 테이블로 만드는 것에 거부감이 생기는 것 같습니다.

아~ 어떤 말씀인지 공감됩니다! 관련해서, 이 말씀을 꼭 드리고 싶어요!

객체지향적인 프로그래밍을 할 때에, 객체는 현실세계의 객체와 꼭 대응될 필요가 없습니다.

예를 들어 현재 우리의 대출기록은 대출기록만의 고유한 정보를 가지고 있습니다. 반납되었는지 / 대출되었는지 말이죠. 또한 요구사항에 따라 대출기록의 고유한 정보는 얼마든지 추가될 수 있습니다. 도메인 관점에서 대출기록 역시 하나의 객체로 생각할 수 있는거죠!!!

오히려 대출기록을 하나의 객체로 인정하지 않으면 문제가 생기게 됩니다! 본래 대출기록 객체가 가져야할 (관리해야할) 정보는 유저가 관리해야 할지~ 책이 관리해야 할지... 대출기록이 가지고 있어야 할 기능은 유저 쪽에 넣어야 할지~ 책 쪽에 넣어야 할지 등 현실세계에서는 '대출기록'이라는 유형의 물체가 존재하지 않지만 SW 세계에서는 '대출기록'이라는 무형의 객체가 있어야 객체간의 관계가 쉽게 표현되는 느낌이죠!!

객체지향에 대한 시각을 더 넓히고 싶으시다면, 다소 어려울 수는 있지만 <오브젝트>라는 책을 추천드립니다!!!! 👍

다소 추상적인 레벨에서 답변을 드려보았는데요!! 혹시나 더 궁금하신 부분이 있으시다면 편하게 질문 남겨주세요 ㅎㅎㅎ 좋은 질문 남겨 주셔서 다시 한 번 감사드립니다.

행복한 하루 되세요!!! 🙏 🙇