어떤 경우에 이런 기능이 유용하고 바르게 쓰는 방법인 지를 알고 싶습니다.
만약 하나의 행을 위해 테이블에 칼럼 하나를 추가하고 다른 행에서는 그 칼럼을 사용하지 않는다면
그 칼럼을 사용하지 않는 다른 행들의 데이터를 읽을 때 데이터 읽기 처리 크기에 영향을 주지 않는지 알고 싶습니다.
안녕하세요 개발자님
우선 테이블 행들이 모두 다른 컬럼을 가지고 있어도 사용(CRUD)상에는 큰 문제가 없습니다.
다만 클라이언트 상에서 데이터를 조회할 때 해당 행에 해당 컬럼이 존재하는지 확인하고 이를 처리하는 로직이 필요합니다.
(행마다 다른 컬럼을 가지고 있을 수 있기 때문)
칼럼 수가 계속 늘어나도 데이터베이스 읽기 처리에는 영향이 없다는 말씀이신가요?
그리고 스키마 정의 테이블에서 행을 읽을 때 null값을 허용하면 null값을 포함한 칼럼은 제외하고 읽어오게 되나요?
하나의 행은 최대 400kb에 데이터를 저장할 수 있습니다.
그렇기에 컬럼 갯수에 제한은 없지만 행의 데이터 크기 제한에 걸려 무한히 컬럼의 갯수는 늘어날 수 없습니다.
또한 컬럼의 갯수는 읽기처리에 영향을 끼치지 않습니다.
컬럼에 null값이 있을 경우 null값을 포함한 컬럼 또한 함께 조회됩니다.
가령 key1 컬럼에 null 값이 들어있으면 아래와 같이 리턴됩니다.
"key1":{"NULL":true}
답변해 주셔서 감사합니다.
제가 튜토리얼만 보고 좀 헷갈려서, 죄송하지만 좀 더 질문하고 싶습니다.
같은 질문인 것 같기는 한데 스키마 미정의 테이블은 뒤끝 콘솔에서 쓰지 않는 칼럼 수를 계속 늘려도 행의 데이터 크기나 읽기 처리에 영향이 없나요?
미정의 테이블은 행에서 지정한 칼럼의 데이터만 가져오고 직접 정의 해주지 않은 칼럼은 가져오지 않는 것 같던데 스키마 정의 테이블에선 그렇게 할 수 없나요?
플레이어 인벤토리 테이터베이스를 짜는데 다음 두 개의 방법 중 뭐가 더 효율적인가요?
테이블: Player
칼럼: PlayerId, name, password, money
테이블: Item
칼럼: ItemId, ItemLevel, ItemDurability
테이블: Inventory
칼럼: PlayerId, ItemId, Quantity
아이템마다 칼럼 생성, 한 플레이어가 새로운 아이템을 얻었는데 해당 칼럼이 없을 때 마다 클라이언트에서 칼럼 새로 생성
정리해서 말씀드리면
테이블에 저장된 행에는 최대 400kb 까지만 저장할 수 있기 때문에 행에 저장된 컬럼을 계속 추가할 수는 있지만,
무한히 컬럼을 추가할 수는 없습니다.
컬럼을 계속 추가하면 해당 행의 크기 또한 증가하게 됩니다.
또한 각 행에 저장된 컬럼의 수는 다른 행에 영향을 끼치지 않습니다.
스키마 미정의 테이블의 경우 스키마가 정의되어 있지 않기 때문에 각각의 행이 다른 구조의 컬럼을 가질 수 있습니다.
그렇기에 각 행을 조회하면 해당 행에 저장된 데이터만 조회되게 됩니다.
스키마 정의 테이블의 경우 스키마, 즉 해당 테이블의 형태 자체를 미리 정의하고 사용하는 것 이기 때문에
클라이언트 사이드에서 별도로 해당 컬럼을 추가하지 않아도 모든 행에 해당 컬럼이 모두 존재하게 되고,
그렇기에 테이블의 행을 조회 시 모든 컬럼이 함께 조회되게 됩니다.
DB 구조의 경우 개발자님의 취향, 게임의 기획 등에 따라 변할 수 있어 어떤 것이 맞다 혹은 효율적이라고 말씀드리기 어려운 부분이 있습니다.
다만 Player 테이블은 1번과 같은 형태로 사용하시고,
Item 혹은 Inventory는 2번과 같이 컬럼을 추가하는 형태로 사용하시면 좋을 것 같습니다.
이 때 각 컬럼의 명을 아이템 명으로 하지 말고,
socket1, socket2 이런 식으로 컬럼명을 생성하고
(인벤토리 안에 100개의 칸이 존재한다는 가정 하에 ~socket100)
각 컬럼의 dictionary 형태의 데이터를 저장하면
Item 테이블과 Inventory 테이블을 합칠 수 있을 것 같습니다.
자세한 답변 대단히 감사합니다.
스키마 미정의 테이블이 제게 좀 생소해서 질문을 하게 된 것 같습니다.
스키마 미정의 테이블을 Dictionary<InDate 값, 행 데이터>같은 걸로 이해해도 될까요?
안녕하세요 개발자님
개념이 다르긴 하지만
그렇게 이해하시고 사용하셔도 무방할 것 같습니다.
덕분에 조금이나마 개념이 잡히는 것 같아 대단히 감사합니다.
혹시 데이터 베이스에 인벤토리 dictionary를 저장해서 읽고 쓰면 위에 2번 예시와 큰 차이가 있나요?
dictionary 타입을 수정할 때 쓰기 작업의 크기가 더 커지게 되나요?
작업의 크기는 차이가 없습니다.
다만 사용상의 편의 측면에서 dictionary를 사용하는 것을 예로 들었습니다.