코드에 저장된 SQL 쿼리를 구성하는 가장 좋은 방법은 무엇입니까? (또는 당신은해야합니까?) [닫힌]

폐쇄되었습니다 . 이 질문은 더 집중되어야 합니다. 현재 답변을받지 않습니다.

이 질문을 개선하고 싶습니까? 이 게시물 을 편집 하여 한 가지 문제에만 집중할 수 있도록 질문을 업데이트하십시오 .

휴일 오년 전에 .

나는 그들이 SQL 쿼리로 흩어진 코드 페이지를 볼 때 좌절하는 유일한 사람이 아니라고 확신합니다. ActiveRecord 및 기타 ORM 패턴은 프로젝트에서 사용되는 많은 양의 SQL을 완화하는 데 도움이되지만 복잡한 쿼리의 경우 많은 경우 SQL 사용을 피할 수없는 것처럼 보입니다.

SQL 코드를 나머지 코드 (또는 외부 코드)와 함께 구성하여 어디서나 흩어지지 않도록하는 방법에 대한 의견을 찾고 있습니까? 명백한 아이디어 중 하나는 뷰를 사용하는 것이지만 종종 여러 개의 큰 인덱스 테이블 등을 처리 할 때 뷰가 성능 문제의 원인이 될 수 있습니다.

편집 1-모델 레이어로 이미 분리했다고 가정합니다.

sql code-formatting

— 해파리
소스

이 질문은 여기에서 확실히 적절하다-코드 구성 : ''왜 '와'어떻게 '를 설명하는 영감을 얻는다.' 주제는 '디자인 패턴'과 '아키텍처'( FAQ에서 )

— Michael K

나는 단지 같은 질문을하려고했다. 여기에 더 많은 답변이 있었기를 바랍니다.

— Michael Kristofik

답변:

나에게 SQL은 비즈니스 로직 코드의 기본 부분 (대부분의 경우 대부분)이다. 반환 된 데이터에서 작동하는 코드와 코드를 분리하려고하면 코드의 이해도와 유지 관리 성이 불균형이 발생하기 쉽습니다.

데이터를 읽고, 데이터를 처리하고, 데이터를 쓰고, 데이터를 검색하는 등의 작업은 모두 유사한 작업이며 동일한 위치에 보관하는 것이 가장 좋습니다.

쿼리 작업이 중복되는 것을 감지하기 시작하면 데이터베이스 액세스 또는 해당 측면의 데이터베이스 액세스를 캡슐화 할 수있는 데이터베이스 뷰 또는 객체가 필요할 수 있습니다.

또 다른 팁은 실제로 좋은 데이터베이스 쿼리 방법을 사용하는 것입니다. 필자가 작성한 소프트웨어 (PostgreSQL, MySQL, SQL Server)에서 대부분의 쿼리 작업이 단일 코드 명령문으로 발생할 수 있음을 확인했습니다.

GetValue(SQL, [transaction], [array_of_params])
GetRow(SQL, [transaction], [array_of_params])
GetRowList(SQL, [transaction], [array_of_params])
GetValueList(SQL, [transaction], [array_of_params])
Execute(SQL, [transaction], [array_of_params])

그것들은 내가 보증하는 주요 함수 호출이 "연결 객체"의 일부입니다. 언어, 실제로 구현하는 것에 달려 있지만, 요점은 실제로 간단하고 고통없이 유지하는 것입니다.

요약하면, SQL을 프로그래밍의 기본 부분으로 취급하고 추상화를 위해 추상화하지 마십시오.

— 가후 아
소스

좋은 답변입니다. 어쩌면 뒤로 물러서서 SQL에 흩어져있는 것이 아니라 코드의 일부로 SQL을보고 시작해야합니다.

— jellyfishtree

"추상화를 위해 추상화하지 마십시오"-좋은 지적. 더 이해하기 쉬운 코드를 위해 요약하십시오.

— Jason Baker

'또 다른 팁은 실제로 좋은 데이터베이스 쿼리 방법을 갖는 것입니다.': 나는 확실히 동의합니다. 비즈니스 로직이 변경 될 때 코드를 수정할 장소가 단 한 곳일 때 많은 도움이됩니다.

— Michael K

SQL을 어디에 두나요? 응용 프로그램으로 컴파일되어 위의 방법으로 전송됩니까?

— johnny

Jason Baker의 답변에 대한 OP의 의견을 바탕으로 "거대한 SQL 쿼리의 배럴을 쳐다 보는 중 ..."은 어떻게 SQL 텍스트의 큰 블록을 읽는 문제를 해결합니까?

— JeffO

일반적으로 별도의 모델 레이어를 사용하는 것이 가장 좋습니다. 이를 설계 하는 방법을 제공 하는 여러 엔터프라이즈 디자인 패턴 이 있습니다.

— 제이슨 베이커
소스

죄송합니다. 좀 더 구체적으로 말해야합니다. 이미 모델 레이어로 분리했다고 가정합니다. 그러나 모델 코드는 여전히 SQL 코드로 상당히 흩어질 수 있습니다. 어쩌면 이것은 피할 수 없을 것입니다. 모델 코드에서 나를 놀라게하는 또 다른 것은 어떤 논리를 기반으로 "SQL 쿼리를 작성하는"코드이다. 아마도 이것은 자체 팩토리 또는 무언가로 분리되어야한다.

— jellyfishtree

@ jellyfishtree-문제가 무엇인지 이해하지 못합니다. 모델 레이어가 너무 많은 모델 코드로 끝날 까봐 두렵습니까?

— Jason Baker

유효한 반박. 가독성이 걱정됩니다. 좋은 모델 코드는 일반적으로 이해하기 쉽지만 거대한 SQL 쿼리의 배럴을 쳐다 보는 것만으로는 의미가 없습니다. 분명히 가장 먼저해야 할 일은 이러한 쿼리에 올바르게 주석을 달지만 좋은 자체 문서화 코드와 동일하지는 않으며 이러한 유형의 섹션은 모델에 흩어져 있습니다. 나는 그것을 받아들이지 만 모델에서 미친 SQL 문을 분리하거나 구성하는 더 좋은 방법이 있는지 궁금합니다.

— jellyfishtree

모델 계층을 "엔터티", "리포지토리"및 "서비스"의 3 가지 하위 계층으로 분리하는 것이 좋습니다. 이를 통해 비즈니스 로직에서 관심사를 분리하고 한 곳에서 SQL을 수집 할 수 있습니다.

이 시나리오에서는 복잡한 SQL을 포함한 모든 데이터 검색 코드가 리포지토리에 있습니다. 따라서 리포지토리 의 목표 는와 같은 자명 한 방법 뒤에 복잡한 SQL 문을 숨기는 것 getUsersWithActiveSubscription()입니다.

엔티티는 getter 및 setter를 사용하여 실제 DB 테이블 필드 이름을 추상화하며 DB 필드 유형과 애플리케이션 / 프로그래밍 언어에서 사용 가능한 유형 간의 일부 데이터 변환을 제공 할 수 있습니다. 귀하의 ORM이이를 지원하는 경우, 엔터티는 연결을 처리 할 수 있습니다.

서비스 계층은 비즈니스 로직의 장소입니다. 서비스는 리포지토리를 사용하여 엔터티를 검색하고 그에 따라 작동하여 다시 저장합니다.

— 게 키릴
소스