이유를 알아야 최대한 그게 맞게 처리할텐데 말입니다.

어찌됐든 동일한 구조를 갖도록 나눠야 하는 이유가 성능상의 이유로

• 하나의 테이블의 데이터를 최근 데이터와 예전 데이터로 나눠서 수정이 빈번한 최근 데이터는 자주 index 재생성(rebuild)을 할 예정이라든지,
• 자주 조회되는 최근 데이터는 SSD에, 그렇지 않은 예전 데이터는 HDD에 저장하겠다든지...

같은  경우라면 MS-SQL을 포함하여 대부분의 DBMS는 이를 지원하는 기능(horizontal partitioning)을 가지고 있습니다.

파티셔닝에 대한 내용을 참조하셔서 해당 테이블을 파티셔닝 처리하시면 데이터는 논리적으로 혹은 물리적으로 나뉘어 저장되지만 테이블은 1개로 바깥에서 볼때는 동일하기 때문에 외부 프로그램은 1도 고치지 않을 수 있습니다.

빠르게 개념을 이해하시기에는 이 내용을 참조해보셔도 좋겠습니다.

문제는 과연 테이블을 나누라는 요청이 테이블 자체가 무조건 3개로 나뉘어 져야 하거든... 과 같은 경우라면 X까라고 외치시면서 거부를 해보시는 방법이... (이때, 이정도 수정이라면 우리가 인력을 ~~나 들여서 ~~기간동안 작업을 해야 하니까 니네가 돈을 ~~~만큼 지불하는 계약이 별도로 필요합니다요 고객님 같은 말을 하면 조금 더 효과가 있을 수도...)

그래도 거부가 거부당하거나 돈을 진짜 주면...

• TableOrg를 TableA, TableB, ... 와 같이 생성 및 데이터 이전을 수행하고
• TableOrg를 삭제
• Create View TableOrg AS TableA Union TableB 

와 같이 해두시면 조회와 관련된 외부 프로그램이나 많은 수의 프로시저 등은 수정을 하지 않아도 되겠지만 data의 변경에 관련된 부분은 적당한(이라고 쓰고 어마무시한 이라고 읽는) 수정이 필요합니다. 예를 들어 TableOrg에 PK 컬럼이 있었고 해당 컬럼이 IDENTITY이라는 것을 염두에 두고 설계된 프로그램을 이에 맞도록 수정한다든지, 누군가 성전환 수술을 하고 와서 '난 이제 성별이 바뀌었으니 이쪽 테이블에서 저쪽 테이블로 옮겨줘요.'를 처리하는 프로그램(예전에는 UPDATE로 끝났던 일)을 작성한다든지 등의 어마무시한 일이 있게 됩니다.(생각만 해도 어질어질한.. )

후자의 경우라면 삼가 무운을 빌겠습니다. 혹시고객사에서 진짜 돈주면 그 돈으로 외주를 주는 방법이 최선일지도......

안타깝게도 저는 후자에 해당되는것 같습니다. 고객사의 방침이겠지요

처음에는 거절하였으나 돈이야기가 나오면서 승인 진행중입니다.

성전환케이스도 고려사항이라 굉장히 고민이 많습니다.

파티셔닝에 대한 정보 감사합니다. 제가 알지 못한 부분이였습니다. 그래도 도움되었습니다. 감사합니다.

UNION 뷰로 대체하는 부분에서
UNION 이 아닌 UNION ALL 을 쓰셔야 합니다.
프로그램 수정 없이도
SELECT 부분은 구문오류 문제는 없겠으나
성능 문제가 일부 있을 수 있습니다.
DML 부분에서는 프로그램 수정이 필요합니다.
프로그램 수정 없이 하려면
뷰에 트리거를 걸어서 처리해야 합니다. (INSTEAD OF)
트리거 작성 로직이 복잡하고 까다로울 것입니다.
트리거 로직 잘 구성하셔야 하고 테스트도 철저하게 하셔야 합니다.