안시 쿼리'만' 사용하는 것은 옳은 선택인지 궁금합니다.

Question

안녕하세용.한창 개처럼 구를 때인 뉴비입니다.제목 그대로 안시쿼리'만' 사용하고자 하는 마음이 옳은 것인지 궁금합니다.여러 이유는 많겠지만 제가 생각하기에,안시쿼리의 장점은 모든 DB에서 작동가능하다는 점인거 같고,각 DB에 최적화된 쿼리는 짧아서 가독성이 좋거나, 성능이 좋거나 하는 장점이 있는 것 같습니다.근데 제가 직장에서 보니까, DB를 종종 건드려야 할 일이 생기는 것 같습니다.아예 다른 DB로 가버리는 경우는 잘 없긴 하지만, 버전업 정도는 하는 것 같더라고용?그럴 때, 안시쿼리가 아닌 경우 문제가 되는 부분들이 생기더라고요.근데 그렇다고 안시쿼리만 사용하기에는 불편하고 번거로운 점이 있다는 것도 사실이니,초보자 입장에서는 어떤 방향성을 생각하고 쿼리를 짜야 하는가 의문이 생기더라고요.그래서 제목 그대로, 안시쿼리만 사용하는 것이 좋은지 어떤지 질문 드립니다.제가 아는게 별로 없어서 질문의 범위가 좀 넓은거 같긴한데, 그래도 잘알려주시면 한번 잘 배워보겠습니다.

allinux · Answer

아뇨 dbms마다 제공되는 문법을 사용하는 편이 더 효율적인 경우가 많습니다. (오라클이면 connect by 같은것)여러종류의 dbms를 관리하고 쿼리문이 문제가 되는 경우라면 orm 을 도입해보는 것도 좋겠습니다.

도니코니 · Answer

저도 신입때 들었던 말인데 안시쿼리로는 한계가 있습니다. 그리고 제가 했던 프로젝트는 프로시저를 다 빼고 배치, 서비스로 변경했어요. 프로시저로 뺀다는게 무조건 정답이 아니리는거죠. 방향성이라는게 사실 그 프로젝트 또는 솔루션의 코드컨벤션을 따라가는게 가장 좋다고 생각합니다.

dw kim · Answer

목적에 따라 다르죠현업에서 디비 종속된 개발을 많이 하기 때문에 비현실적인 것 같습니다

Ganymede Ganymedian · Answer

SQL 자체는 사실 아무것도 아닙니다. outer join 과 subQuery, temp table 등이 퍼즐같은 재미는 있지만, 개발자의 전체 여정에서 보면, 초기에 잠깐 경험해야 하는 가벼운 던전 중 하나일 뿐입니다. 중요한 건 ‘해결해야 할 태스크’ 이고, 이제 SQL 은, -schema 가 제공됐을 때- AI 가 인간보다 훨씬 더 잘 만듭니다. 그리고, 논쟁을 일으킬 수도 있겠으나, 극단적으로 말하자면, Join 쿼리보다는 단순쿼리 10 개가 더 경제적일 수 있습니다. 어느쪽이 더 효과적일 것이지를 외면하거나 망각해선 안돼요. 중요한 건 비용과 결과이지, 개발자의 자뻑이 아닙니다.ANSI SQL 은, 배움을 위해 다져두어야 할, 일종의 구구단 같은 과정이고요.. AI 가 던져준 SQL 을 보고 이해하고 검증할 능력이 없다면, AI 를 활용할 자격이 없다고, 저는 생각합니다.그리고, ANSI 이후의 빌드를 생각하고 활용할 수 있어야 합니다. 각 DBMS 마다 ANSI SQL 외의 유틸리티 기능들을 제공하고 있는데, DBMS 특성 SQL 보다는, 이들 유틸리티 펑셔널리티들을 활용하는 능력을 키우는 게 더 중요하다고, 저는 생각하고 있습니다.아래는, ChatGPT 에게 만들어달라고 부탁해서 만든, 각 DBMS 별 주요 펑셔널리티/유틸리티 의 특성입니다.기능PostgreSQLMySQLSQLiteSQL ServerOracleTrigger✔️ 매우 강력(BEFORE/AFTER/INSTEAD OF)✔️ 지원✔️ 가벼운 구현✔️ 강력✔️ 강력Cascading FK✔️ 지원✔️ 지원✔️ 제한적으로 지원✔️ 지원✔️ 지원RLS (Row-Level Security)⭐ 강력한 RLS 지원❌ 없음❌ 없음✔️ 있음 (but 복잡)✔️ 있음 (VPD)Policy 기반 보안✔️ PostgreSQL 독자 기능❌❌❌✔️ VPD (Enterprise)Materialized Views✔️ 지원❌ 거의 없음❌✔️ 지원✔️ 매우 강력Partial Index✔️ 지원❌✔️ 일부 지원❌❌Event Trigger✔️ 지원❌❌❌❌Generated Column✔️ 지원✔️ 지원✔️ 지원✔️ 지원✔️ 지원예를 들어, 각 사용자에게, DBMS 와 Storage 의 Usage Quota 를 할당해주고, 이를 관리해줘야 하는 서비스가 있다고 가정해보죠.John 에게는, 총 200MB 의 스토리지 데이터와, 50MB 의 DB 데이터 쿼타가 할당되어 있습니다. 할당량을 초과하는 요청에는, 507 에러를 리턴해야 합니다.이 경우, John 이 파일을 업로드할 때, 또, 아티클을 작성할 때, John 의 quota 관리를 어떻게 해줘야 할까요? 또, 파일을 삭제할 때, John 의 quota 관리가 어떻게 자동화 될 수 있을까요?가볍게 생각해볼 때는, 파일 업로드 클라이언트 모듈과 API, 파일 삭제 클라이언트 모듈과 API 에, Auth 와 quota 체크 쿼리가 필요할 것 같습니다. 쿼리도 매 작업마다 수차례 오갈 수 밖에 없습니다. 생산성과 효율 면에서 정답일 수 없겠다는 직감이 들죠.Cascade 와 Trigger function 으로 이 작업을 자동화 할 수 있습니다. Trigger function 은, -모든 DBMS 가 지원하고 있지만- 엄밀히 말하자면 ANSI 영역은 아니죠. Trigger function 이 아닌, 백엔드의 코드로 이 작업을 처리해주다가는, 어디에선가 드리프트가 발생할 수 있습니다. 만약, 백엔드로만 이 태스크를 처리해줬다면, 백엔드 업데이트 작업은 무척 두렵고 어려워지겠죠. 후임자 또는, 미래의 자신이 고통받게 될 수 있습니다.최근 PostgreSQL 이 각광받고 있는 데에는 이유가 있습니다. RLS Policy 는 진입장벽이 있기는 한데, 한번 발 들이면, 그 정합성의 매력이, 개발자의 패턴과 가치관을 바꿀 정도로 임팩트가 있습니다.

안시 쿼리'만' 사용하는 것은 옳은 선택인지 궁금합니다.

4개의 답변

Q&A 목록