USER라는 클래스가 있고, ID / PS 라는 멤버를 갖고있고
1~10으로 ID가 주어지고, 각각 다른 PS를 갖고있을때,
ID를 가지고, ID에 해당하는 PS를 알고싶을때
USER의 ID가 인덱스 되어있으면 USER[ID].PS 라고하면 바로 찾을 수 있잔아요.
근데 배열상에 USER ID가 소팅되어있지 않을땐
for문을 돌아서 같은 ID를 찾고, 그 ID번째의 USER[i].PS를 얻어야될텐데..
그게 10개면 몰라도 100개, 1000개 되면 ,매번 찾는다면 비효율적일것같은데..
for문 안돌고 더 빠르게 찾는 방법은 없을까요?
1~10으로 ID가 주어지고, 각각 다른 PS를 갖고있을때,
ID를 가지고, ID에 해당하는 PS를 알고싶을때
USER의 ID가 인덱스 되어있으면 USER[ID].PS 라고하면 바로 찾을 수 있잔아요.
근데 배열상에 USER ID가 소팅되어있지 않을땐
for문을 돌아서 같은 ID를 찾고, 그 ID번째의 USER[i].PS를 얻어야될텐데..
그게 10개면 몰라도 100개, 1000개 되면 ,매번 찾는다면 비효율적일것같은데..
for문 안돌고 더 빠르게 찾는 방법은 없을까요?
매핑의 내부 알고리즘이 검색이 편하게 최적화되어 있을 뿐이지 어차피 키값은 내부에서도 순환문 돌려서 뽑기 때문에 저걸 P문제로 바꿀 수 있는 방법은 없을것 같아 보입니다.
맵이나 해쉬맵 사용ㄱㄱ
키 검색 부분을 B트리 형태로 인덱싱하면 빠를거 같네요.
근데 트리맵에서 깊이검색으로 빨리 찾아진다고 해도 결국 깊이 검색을 하는데 루프가 돌아가니까요. 방법이 없을 거 같습니다.
정렬이나 인덱싱이 되어있는 자료라면.. 풀스캔 외에는 답이없을듯요. 가상으로라도 정렬되어있는것처럼 꾸며져있어야죠 ㅜㅜ
되어있는 -> 되어있지 않은
ㅁㄴㅇ 님 말씀처럼 풀 스캔밖에 답이 없음. 차후에 배열에 USER 객체의 삽입 삭제시 작업이 더 추가될 경우가 생기기는 하겠지만.. 그나마 방법을 내보자면 현재 user 객체를 담고 있는 배열과 동일한 배열을 하나 더 선언하고, 이미 있던 배열의 객체들을 소팅하여 새로 만든 배열에 담는 방법이 떠오르네요. 삽입 삭제보다 검색이 빈번하게 일어나는 경우라면 위와같은 방법을 사용하여 이진 탐색 알고리즘이라도 펼치는 것이 매회 검색마다 풀 스캔을 하는것보다는 빠를 것이라고 예상됩니다. (그렇지 않으면 객체가 n 개일 때 재수 없으면 n번의 탐색을 할 수도 있으니 그야말로 최악이죠)
설계 단계에서 어느 부분에선 어느 자료 형식을 사용 할 지 선택을 하게 되는데, 코딩까지 완성 된 상태에서 d 님이 질문한 것과 같은 비효율적인 문제가 발생했다라는 것을 찾았다면, 설계 미스입니다. 까딱 잘못하면 완전 갈아 엎어야 하는 경우가 생기게 됩니다.