현재 버전

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

추가로 SQL 학습은 다음과 같은 이유로 ORM을 사용을 권장합니다. 

1) Model 객체의 설계 스킬
2) ORM이 만들어주는 모델에 최적화된 query와 그 실행 계획 분석을 통한 스킬
     (DB 종류에 따라 자동으로 SQL을 바꿔서 볼 수 있음 ex) mysql, mssql, postgre, oracle)

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 좋을 것 같습니다.

말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

제가 모든 상황을 다 알지 못해서 이야기하기에는 조심스럽지만, 개인적인 생각으로는 REST API 서비스 하나가 DB를 바라보고 다른 서비스들이 REST API 서비스를 요청하도록 설계했다면 어땠을까 합니다.






수정 이력

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

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

추가로 SQL 학습은 다음과 같은 이유로 ORM을 사용을 권장합니다. 

1) Model 객체의 설계 스킬
2) ORM이 만들어주는 모델에 최적화된 query와 그 실행 계획 분석을 통한 스킬

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 좋을 것 같습니다.

말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

제가 모든 상황을 다 알지 못해서 이야기하기에는 조심스럽지만, 개인적인 생각으로는 REST API 서비스 하나가 DB를 바라보고 다른 서비스들이 REST API 서비스를 요청하도록 설계했다면 어땠을까 합니다.





2020-03-03 23:07:20 에 아래 내용에서 변경 됨 #13

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

추가로 SQL 학습은 다음과 같은 이유로 ORM을 사용을 권장합니다. 

1) Model 객체의 설계 스킬
2) ORM이 만들어주는 모델에 최적화된 query와 그 실행 계획 분석을 통한 스킬

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 좋을 것 같습니다.

말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 했다고 생각합니다.






2020-03-03 23:06:08 에 아래 내용에서 변경 됨 #12

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

추가로 SQL 학습은 다음과 같은 이유로 ORM을 사용을 권장합니다. 

1) Model 객체의 설계 스킬
2) ORM이 만들어주는 모델에 최적화된 query와 그 실행 계획 분석을 통한 스킬

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 좋을 것 같습니다.

말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 23:05:25 에 아래 내용에서 변경 됨 #11

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

개인적으로는 SQL을 Model 객체의 설계 스킬과 ORM이 만들어주는 query의 실행 계획을 보면서 익히는 것을 추천합니다. 

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 맞지 않을까요?

말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 23:03:42 에 아래 내용에서 변경 됨 #10

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.
개인적으로는 SQL을 Model 객체의 설계 스킬과 ORM이 만들어주는 query의 실행 계획을 보면서 익히는 것을 추천합니다. 

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 맞지 않을까요?

말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 23:03:33 에 아래 내용에서 변경 됨 #9

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 맞지 않을까요?

말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 23:00:08 에 아래 내용에서 변경 됨 #8

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날렸던 경험은 시스템 설계의 문제로 보입니다.
REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 22:59:32 에 아래 내용에서 변경 됨 #7

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

SQL 인젝션은 prepared statement와 validation check를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날렸던 경험은 시스템 설계의 문제로 보입니다.
REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 22:59:18 에 아래 내용에서 변경 됨 #6

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

SQL 인젝션은 prepared statement를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날렸던 경험은 시스템 설계의 문제로 보입니다.
REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 22:58:52 에 아래 내용에서 변경 됨 #5

좋은 글 잘 읽었습니다! 

하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 이슈가 더 크다고 생각됩니다.

SQL 인젝션은 prepared statement를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날렸던 경험은 시스템 설계의 문제로 보입니다.
REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 22:58:10 에 아래 내용에서 변경 됨 #4

나머지는 공감합니다만, stored procedure 사용은 반대합니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 이슈가 더 크다고 생각됩니다.

SQL 인젝션은 prepared statement를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날렸던 경험은 시스템 설계의 문제로 보입니다.
REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 22:57:17 에 아래 내용에서 변경 됨 #3

나머지는 공감합니다만, stored procedure는 반대하고 싶습니다. 

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 이슈가 더 크다고 생각됩니다.

SQL 인젝션은 prepared statement를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날렸던 경험은 시스템 설계의 문제로 보입니다.
REST API 서비스 하나가 DB를 바라보고
다른 서비스들이 REST API 서비스를 요청하도록 설계했어야 하지 않을까요?






2020-03-03 22:56:21 에 아래 내용에서 변경 됨 #2

나머지는 공감합니다만, stored procedure는 반대하고 싶습니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더 최악)으로 발생하는 부채 이슈가 더 크고 SQL 인젝션은 prepared statement를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날리는 시스템 아키텍처를 경험담으로 말씀하셨는데, REST API 서비스 하나가 DB를 바라보고 다른 서비스들은 REST API 서비스를 바라보게 설계했어야 했을것 같습니다.






2020-03-03 22:54:28 에 아래 내용에서 변경 됨 #1

나머지는 공감합니다만, stored procedure는 완전 반대입니다.

1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더 최악)으로 발생하는 부채 이슈가 더 크고 SQL 인젝션은 prepared statement를 사용하는게 맞지 않을까요?

여러 서비스가 하나의 DB를 바라보고 query를 날리는 시스템 아키텍처를 경험담으로 말씀하셨는데, REST API 서비스 하나가 DB를 바라보고 다른 서비스들은 REST API 서비스를 바라보게 설계했어야 했을것 같습니다.