문자열 리스트를 DB에 저장할때 설계 어떻게함??

[익명(211.243)]

순서도 지켜야한다면

1. ID, ORDER, VALUE 컬럼을 만들어서 하나하나씩 넣는다

2. ID, VALUES 컬럼을 만들어서 리스트 전체 값을 json 으로 만들던 해서 VALUES에 다 때려박는다

두가지 말곤 방법이 없어보이는데 

뭐가 낳냐

[익명(nscks)]

나중에 조회를 어떻게 할지에 따라서? 리스트를 통으로만 조회할거면 후자로 해도 되는데 각각 조회할 일이 일이 있다면 전자지 - dc App

[익명(nscks)]

다만 너무 긴 문자열을 통으로 저장하면 db 성능에 악영향이 될수도 있고 그러니 dba와 상의해보자 - dc App

[익명(211.243)]

각각 조회할일은 없어서 후자를 고민중이긴함

[익명(nscks)]

db는 기본적으로 하나의 컬럼안에 모든 걸 때려박는 것보다 나눠서 insert하는 것에 최적화된 도구임. 리스트가 짧다면 다 때려넣어도 되겠지만 그게 아니라면 나눠 넣는게 나을 가능성이 높음 - dc App

[익명(211.243)]

dba도 뭐 뻔한말이긴 함 너무 크면 쪼개시구요 아니면 뭐 알아서 하시구요

[익명(211.243)]

우리회사만 그런진 모르겠지만 dba가 조금 수동적임 실제로 서비스에서 돌아갈때 지표상 느리거나 문제가 있는 부분에 대해서 피드백이 오는거지 처음 설계부분에서 크게 고민해주진 않음

[프갤러 1(218.150)]

이런애들은 왜 필요할때 nosql을 안쓰는걸까??

[익명(211.243)]

전체중에 아주작은 저 일부분때문에 nosql로 다 바꿔? 저부분만 nosql로 써?

[프갤러 1(218.150)]

내말의 의미를 이해를 못하네 갈길감 ㅅㄱ

[익명(211.243)]

니가 내 질문을 이해 못했던가, nosql 무새던가 둘중하나겠지

[프갤러 2(220.74)]

문자열 길이가 얼마나 됨?