자바보다 PL/SQL이 편해서 PLSQL로 비지니스로직을 짜고 있는데
다른 개발자분이 PLSQL은 유지보수가 힘들어서
PLSQL로 비지니스로직을 짜는 건 잘못된 일 처럼 얘기하는데
제가 개발하고 있는 방식이 구식방식인건가요?
각자의 입장이 있으시니 어느 것이 낫다고 하기는 어렵습니다. 그렇지만 plsql로 작성했을 때 성능상의 이점도 있는데 잘못된 것이라고 할 수는 없다고 생각합니다. java든 plsql이든 서비스 성격에 맞게 사용하면 좋을 것 같습니다.
비지니스로직을 무엇으로 짤 것인지는
운영시 인력구조를 감안하셔야 합니다.
(내가 계속 그곳에서 운영할 것이 아니라면...)
우리나라에서 PLSQL에 익숙한 개발자 보다
JAVA개발자를 구하기가 쉽죠
오라클의 pl/sql 은 문법도 쉬우며 상당히 좋은 기능입니다.
하지만 개발시에 비즈니스 로직을 이걸로 모두 구현하는 것은 많은 프로젝트에서는 피하고 있습니다. - 보통 정말 프로그램에서 하려면 쉽지않고, pl/sql 에서는 간단하게 구현하는 부분, - pl/sql로 구현시 확실한 튜닝 포인트가 존재하는 부분(bulk, refcursor 등) - 프로그램 호출에서 pl/sql 에서 짠걸 호출하면 도움이 될 경우 들은 pl/sql 로 짜긴 합니다. ### pl/sql 비즈니스 로직을 대부분 구현하는 경우 고려할 사항이라고 생각하는 것을 적어봅니다. 1) 개발팀 / DBA 조직에서 pl/sql 로 이걸 짤 경우 담당 문제 : pl/sql 튜닝 포인트를 생각하면서 짤 수 있는 조직이 어디인가의 이슈가 있을 것입니다. 개발쪽은 로직을 잘 알고, DB쪽은 튜닝 포인트를 잘 알고 ... 여기에서 밀리면 독박입니다... 특히 DBA 조직에서 짤 경우 그 소수 인원은 개발도 하고 관리도 하고 ... 2) 더 중요한건 차후 유지보수 문제입니다. pl/sql 문서화가 안될 경우 상당히 치명적입니다. 실제로 한 사이트에서 핵심 비즈니스 로직을 수백개의 pl/sql 로 작성한 적이 있습니다. 그걸 문서화하는건 소수 몇 명 뿐입니다. 당연히 유지보수 문제가 발생했습니다. 3) 비즈니스 로직의 수정 / 추가와 컬럼 추가 등의 ddl 반영시에도 상호 함수를 참조할 경우 반영시 오라클 객체 invalid 등의 문제를 어떻게 피할 것인가 하는 등의 문제가 있습니다. (이건 DBA 들에게는 상당한 스트레스입니다.) 4) 일반적으로 개발자의 비율이 10배 이상으로 많으며, java 등의 프로그램 로직으로 개발할 경우 문서화를 더 잘할 시간적 여유가 있습니다. 이는 차후 유지보수를 상당히 수월하게 해줍니다.