라고 생각하는 사람 혹시 있어?
자바\'만\' 개발해본 사람들중에 은근히 좀 있을거 같은데..
내가 느낀건..MVC 분리만 잘하면..굳이 sql 과 코드까지는 따로 분리 안해도 될거 같다는 거..
분리도 해보고 분리도 안해보고 php로도 분리해보고 java로도 분리해보고 안해보고 다 해봤는데..
확실히 느낀건..MVC만 잘 분리되고 M의 메서드만 잘 분리되있다면..
걍 sql 을 각 메서드 상단에 때려박아두는게 오히려 유지/보수 하기 좋다라는 생각이..
MVC 아니라도 어지간하면 Model 클래스 정도는 따로 만들어줘라 ㅡㅡ); 레알 나중에 DB 이전이라던지 하면 레알 포풍 코피다....
sql을 재사용 할 일은 거의 없다만, 떙칠횽이 말한 경우같은 거 때문에 분리하는게 좋음
현실적으로 DB 이전을 하게 된다고 해서 sql 만 바꾸지는 않고 그 sql을 사용하는 모든 메서드들을 다 추적해서 바꿔야 하는데...어차기 고게 고거인듯?
추가적으로 DB이전을 하게 되면..대부분 새로 짜지들 않나~? SQL을 분리하게 되면 DB 이전에 유용하다..이게 이론적이고 이상향이긴 한데..과연 실무에서도 그럴까?
사실 DB 이전을 염두해두고 SQL을 나눠놓으면..그에 따르는 설계같은것도 그렇게 따라가야 하기 마련인데..과연 실무에서 \"DB 이전의 가능성\"을 두고 개발하는 곳이 얼마나 될까? 아니 그 가능성을 열어두고 개발하는 개발자는 얼마나 될까?
사이트가 커지면 쿼리 튜닝할일이 존나게 마는데 쿼리랑 코드랑 분리 안되면 짜증남....
mssql 쪽은 마소에서도 권장하는게 글코 대부분 모든 쿼리를 프로시져로 만든 다음에 코드에서는 그 프로시져만 호출하거등. 오라클이나 mysql은 내가 안해서 모르고.. 여튼 일케 sql은 코드랑 분리되서 dbms 안에 있기 때문에 dba들은 코드 안보고 그냥 모니터링 상황 보고 악성쿼리 찾아서 수정하면 되거든.
근데 예전 회사에서는 쿼리를 그대로 코드에 박았어. 그럼 악성쿼리를 찾은다음에 개발자 불러다가 이거 어디서 쓰는건지 물어봐서 코드에서 쿼리 보고 거기서 수정해서 소스 다시 적용시켜 올려야 했지.....
그니까 코더가 코딩 쿼리 다 만지면야 상관없겠지만 코더 dba 나뉠 정도 사이트에서는 서로의 협업을 위해서도 나뉘는게 좋다능. 코더들도 dba들이 너네 코드 수정하고 다시 배포시켜서 혹시나 에러가 날 상황을 원하진 않을꺼자녀