제 생각만 적어볼게요.. 정답이 아닐수 있습니다.

1. 1:1 관계라면 굳이 테이블을 나눌필요가 없겠지만

정보테이블에 있는 자료만 사용되는 빈도가 높고 메타정보테이블에 있는 자료의 사용빈도가 낮다면 테이블 분리로 성능향상의 효과가 있어 보입니다.

(단 두 테이블을 항상 조인해야 하는 상황이라면 분리하는게 좋아보이진 않네요)

2. 인덱스가 여러개일경우 발생할수 있는 문제는 

     1) 테이블스페이스 공간을 많이 사용하게된다.

     2) INSERT 나 UPDATE DELETE 의 속도저하

     3) Analyze 나 리빌딩시 오래걸림

     4) 백업시간이 오래걸림   등이 생각나네요

3. 대용량데이터(억단위이상) 에서는 인덱스 이상을 고려해야겠지만 1만 5000건 정도의 데이터에서는 인덱스 이상을 고려해야 할 필요는 없어보입니다만, 0.001 초를 고려해야 하는 상황이라면 또 달라지겠죠..

4. 테이블을 분리하는경우나 써머리테이블(통계나 누적)을 사용하는 경우는 실무에서도 자주 사용됩니다.

5. 1만 5천건 정도의 데이터에 동시접속 10명(동시에 쿼리를 날리는 숫자니 작은 숫자가 아닙니다. 쿼리실행 시간이 0.01초 안에 끝날것이니..) 정도의 시스템이라고 한다면 인덱스만 제대로 탄다면 특별히 DB 설계에서 고려해야 할 필요는 없어보이며 테이블을 굳이 나누지 않아도 성능에는 별 영향이 없어보이네요

1님@답변 감사드립니다. 추가 질문도 올렸으니 한번 봐주시면 정말 감사드리겠습니다.

 추가답변입니다.

6. 위에서 말씀드렸다시피 15천건은 데이터양이 무시해도 좋을만큼 작은양입니다.

   (뭐 서버가 8bit pc 는 아니겠죠...)

   뷰카운트는 일반적으로 본테이블에 컬럼만 추가합니다만. 다만 조회시점을 로그로 남기려면 별도의 테이블이 있어야 겠지요. 

7. 구분자를 두어 단일컬럼에 여러정보를 담는 부분은 전 별로 좋지않게 생각합니다.

    뭐 정규화 문제를 떠나서  App 단에서 해줘야 할 작업이 많이 생기지요..

또다시  1님 답변 감사드립니다.

조회 시점을 로그로 남기는 것은 생각해 보질 못한 부분이네요. 반영해야겠습니다.

구분자를 코드를 분해해서 검색도 가능하게 하려 합니다만, 물론 App단에서 해야할 일이 많겠지만, 구분자를 쓰도록 해야겠습니다. 리더가 정규하하는 것을 왠지 귀찮아 하네요.

답변 정말 감사드립니다.