저라면 한 테이블로 만듭니다..

데이터를 넣는데는 아무런 문제가 없습니다.. 하지만 언제나 문제가 되는건 그 데이터를 조회하는 곳에서 문제가 발생하는데 그 부분은 효율적인 설계와 인덱스로 충분히 풀어낼 수 있다고 봅니다.

조건번호라는 분리할 수 있는 키가 있다면 그걸 기준으로 부분 인덱스를 생성해도 되겠네요. 물론 검색할 때 그 조건번호가 항상 검색되어야 겠구요.

이렇게 할 수 있다면 테이블을 몇만개가 아니라 몇십개로 분리한다고 해도 그 상황보다는 나을듯 싶습니다.

우선은 관리하는 자료량이 많아지면 그것에 맞춰서 메모리나 I/O도 보강을 해주셔야겠습니다.

그리고 한 테이블에 넣는 것이 원칙(?)이겠지만 판단을 잘해서 말씀하신 것 처럼 하는 것이 현실적으로 필요할 수도 있습니다. 일단 한 테이블에 모든 자료를 넣어 두고 몇몇 자료만 별도에 테이블에 또 복사해서 저장해두는거죠.

이때 무결성 보장을 위해서 신경을 쓰셔야 할거구요.

어떤 방법을 쓸지는 전적으로 DBA의 판단에 따라야 할 것 같습니다. 한번 test 해보세요.

아무래도 한 테이블에 저장된 양이 작으면 속도면에서 이득이 있을겁니다. 처리할 자료가 적어서도 이득이겠지만 큰 테이블을 처리할 때의 최적화 방법과 작은 테이블을 처리할 때의 최적화 방법이 달라서 작은 테이블을 처리할 때에 더 효율적인 경우가 많습니다.