프로시저에 담긴 비즈니스 로직, 업계에서 걷어낼 수 있을까요?

요즘에는 비스니스 로직은 WAS에서 해결하고, DB의 의존성을 낮추기 위해 프로시저를 지양하는 추세인데요, BigQuery, Snowflake, Vertica 같은 회사/제품에서 오히려 프로시져에 대한 지원을 시작, 확장하고 있습니다. 왜 일까요? > Stored Procedure는 전통적인 DBMS 회사들이 SQL만으로 하기 어려운 프로그래밍적 기능을 사용하기 위해 만들어졌으며, ... 특히 Oracle의 Stored Procedure는 PL/SQL이라고 따로 불리고 하나의 전문 기술영역으로 분류될 만큼 널리 활용되어 왔다. 가장 큰 특징은 상태 저장이 어려운 SQL을 변수 처리를 할 수 있도록 보완하는 것이며, 여기에 루프문, 조건문 등의 기초적인 프로그래밍 기법을 활용할 수 있도록 하는 것이 주요 골자이다. ... 일부 데이터와 관계된 비즈니스 로직을 WAS단이 아닌 DB 구간에서 처리하여 효율성을 높일 수 있다는 점 때문에 널리 사용 되었다. > 하지만, 이들이 Stored Procedure에 대한 지원을 하게 되는 이유는 결국 매우 단순하다. 기존에 만들어진 시스템의 경우라면 결국 마이그레이션을 해야하는데, Stored Procedure를 온전히 모두 다 걷어낸다는 건 사실상 불가능에 가깝다고 생각하기 때문일 것이다. ... 그래서 Oracle이나 Teradata가 제공하는 수준의 기능은 아니더라도, Stored Procedure를 지원하는 방향으로 나갈 수 밖에 없는 것이다. > 또 다른 관점에서 생각해볼 수도 있다. Databricks나 Dataiku 같은 데이터 플랫폼 서비스가 시장에 성공적으로 진입하면서, DBMS 벤더가 신규 데이터 관련 시장에서 가져갈 수 있는 파이가 기대보다 많이 줄었을 가능성이 높다. 그렇기 때문에 더욱 기존 시스템의 윈백 기회나 기존 데이터베이스 사용자를 강하게 견인하기 위해서 더욱 DBMS 전통적인 기능을 넣을 수 밖에 없었다고 볼 수도 있다. 본문에서 언급했듯이 COBOL로 쓰여진 코드를 유지보수하기 위해 애타게 사람을 구하고 있는 것 처럼, 나중에는 N만줄짜리 프로시저 유지보수를 위해 애타게 사람을 구할 수도 있겠네요. http://cloudinsight.net/data/stored-procedure%ec%97%90-%eb%8c%80%ed%95%9c-%eb%8b%a8%ec%83%81/