현재 버전

나머진 공감합니다만, DB에서 stored procedure를 사용하란 말엔 의문이 생기네요. 

저는 stored procedure로 구성된 레거시 쿼리를 파악하기 너무 힘들었어요. 사이드이펙트를 몰라서 수정하는 것도 너무 힘들었고, 히스토리도 알기 어려웠습니다.

그래서 저는 stored procedure로 풀 수 있다 하더라도 어플리케이션에서 코드레벨로 해결하는 방향으로 진행하고 있습니다.

그러면 장점이, 테스트코드에서 우선 로직의 무결성이 보장되기도 하고, 이후에 참여하는 인원이 로직을 파악하기 더 쉽고, commit 단위로 히스토리 파악이 쉽다고 생각합니다.


수정 이력

2020-03-03 14:37:21 에 아래 내용에서 변경 됨 #3

나머진 공감합니다만, DB에서 stored procedure를 사용하란 말엔 의문이 생기네요. 

저는 stored procedure로 구성된 레거시 쿼리를 파악하기 너무 힘들었어요. 사이드이펙트를 몰라서 수정하는 것도 너무 힘들었고, 히스토리도 알기 어려웠습니다.

그래서 저는 stored procedure로 풀 수 있다 하더라도 어플리케이션에서 코드레벨로 해결하는 방향으로 진행하고 있습니다.

그러면 장점이, 테스트코드에서 우선 로직의 무결성이 보장되기도 하고, 이후에 참여하는 인원이 로직을 파악하기 더 쉽다고 생각하거든요.

2020-03-03 14:11:40 에 아래 내용에서 변경 됨 #2

나머진 공감합니다만, DB에서 stored procedure를 사용하란 말엔 의문이 생기네요. 

저는 stored procedure로 구성된 레거시 쿼리를 파악하기 너무 힘들었어요. 수정하는 것도 너무 힘들었고, 히스토리도 알기 어려웠습니다.

그래서 저는 stored procedure로 풀 수 있다 하더라도 어플리케이션에서 코드레벨로 해결하는 방향으로 진행하고 있습니다.

그러면 장점이, 테스트코드에서 우선 로직의 무결성이 보장되기도 하고, 이후에 참여하는 인원이 로직을 파악하기 더 쉽다고 생각하거든요.

2020-03-03 14:09:46 에 아래 내용에서 변경 됨 #1

나머진 공감합니다만, DB에서 stored procedure를 사용하란 말엔 의문이 생기네요. 

저는 stored procedure로 구성된 레거시 쿼리를 파악하기 너무 힘들었어요. 수정하는 것도 너무 힘들었고, 히스토리도 알기 어려웠습니다.

그래서 저는 stored procedure로 풀 수 있다 하더라도 어플리케이션에서 코드레벨로 해결하는 방향으로 진행하고 있습니다.

그러면 장점이, 테스트코드에서 우선 로직의 무결성이 보장되고, 이후에 참여하는 인원이 로직을 파악하기 더 쉽다고 생각하거든요.