현재 버전

// 자라선

질문 감사드립니다. 

SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 실수를 적게 유발 시키지 않을 수 있다는 의미입니다. 

JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적는 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

해결방안은 갑 업체에서 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 성능 측정 logging 및 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

특히나 데드락은 Stored procedure를 잘 못 만든 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라고 생각합니다.




수정 이력

2019-12-27 11:16:05 에 아래 내용에서 변경 됨 #6

// 자라선

질문 감사드립니다. 

SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 실수를 적게 유발 시키지 않을 수 있다는 의미입니다. 

JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적기 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

해결방안은 갑 업체에서 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 쌓인 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 성능 측정 logging 및 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

특히나 데드락은 Stored procedure를 잘 못 만든 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라고 생각합니다.



2019-12-27 11:03:08 에 아래 내용에서 변경 됨 #5

// 자라선

질문 감사드립니다. 

SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 실수를 적게 유발 시키지 않을 수 있다는 의미입니다. 

JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적기 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

해결방안은 갑 업체에서 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 쌓인 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 성능 측정 logging 및 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

특히나 데드락은 Stored procedure를 사용하는 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라고 생각합니다.



2019-12-27 10:43:27 에 아래 내용에서 변경 됨 #4

// 자라선

질문 감사드립니다. 

SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 실수를 적게 유발 시키지 않을 수 있다는 의미입니다. 

JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적기 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

해결방안은 갑 업체에서 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 쌓인 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 성능 측정 logging 및 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

특히나 데드락은 Stored procedure를 사용하는 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라도 생각합니다.



2019-12-27 10:43:08 에 아래 내용에서 변경 됨 #3

// 자라선

질문 감사드립니다. 

SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 실수를 적게 유발 시키지 않을 수 있다는 의미입니다. 

JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적기 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

해결방안은 갑 업체에서 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 쌓인 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

특히나 데드락은 Stored procedure를 사용하는 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라도 생각합니다.



2019-12-27 10:42:14 에 아래 내용에서 변경 됨 #2

// 자라선

질문 감사드립니다. 

SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 실수를 적게 유발 시키지 않을 수 있다는 의미입니다. 

JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적기 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

해결방안은 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 쌓인 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

특히나 데드락은 Stored procedure를 사용하는 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라도 생각합니다.



2019-12-27 10:41:02 에 아래 내용에서 변경 됨 #1

// 자라선

질문 감사드립니다. 

SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 주요 이유는 아니지만 좀 더 낫게 실수를 유발 시키지 않을 수 있다는 의미입니다. 

JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적기 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

해결방안은 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 쌓인 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

특히나 데드락은 Stored procedure를 사용하는 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라도 생각합니다.