여전히 SQL을 작성해야합니까?

대부분의 현대 언어에 대한 많은 ORM 도구를 사용하여 프로그램에서 언어를 지원하는 언어 / 환경으로 SQL을 작성하고 실행하는 사용 사례가 여전히 있습니까? 그렇다면 왜?

명확성을 위해 : 프로그래머가 SQL을 알아야하는지 또는 데스크탑에 SQL 도구가 있어야하는지 묻지 않습니다. ORM과 달리 코드 (또는 구성 또는 기타)로 왜 가질 수 있는지 구체적으로 묻고 있습니다 .

• 절차 코드를 작성하는 것보다 데이터를 쿼리하기 위해 SQL을 작성하는 것이 더 편합니다.
• ORM은보기에는 아름답지만 일부 중요한 영역에서는 끔찍하게 느린 SQL을 생성합니다.
• ORM을 통해 사용할 수 없거나 사용할 수없는 RDBMS에 의해 노출 된 기능을 활용해야합니다.
• 입력 할 때마다 SELECT * FROM...하나님은 고양이를 죽입니다. 그리고 당신은 새끼 고양이 를 싫어 합니다.
• ORM, OOP 또는 현대 언어를 사용하고 있지 않습니다.

복잡한 SQL 작성

ORM은 기본적인 것들에 좋습니다. 그러나 복잡한 상황에서는 SQL을 작성해야합니다.

간단히 말해서, SQL에 대한 필요성이 가장 분명하며 항상 그렇게 될 것입니다.

• 견해
• 트리거
• 제약
• 패키지 (SSIS, DTS 등)
• 실행 흐름을 정확하게 제어해야 할 때마다

ORM은 데이터베이스를 구축, 조정 또는 자동화하는 데 도움이되지 않습니다. 모든 작업을 완료 한 후에는 데이터베이스와 상호 작용할 수있는 대체 방법을 제공합니다.

확실한:

• 일반적으로 ORM은 많은 것을 캡슐화하지만 결국에는 배후에서 발생하는 일을 알아야합니다. 이는 성능과 확장성에 중요합니다. 응용 프로그램 내부에서 많은 SQL을 작성하지는 않지만 SQL 또는 DDL이 어떻게 보이는지 대략 알고 있습니다.
• 직접 SQL은 종종 읽기 전용 쿼리를 작성하는 것이 좋습니다. ORM 쿼리 언어로 공식화하는 것이 훨씬 쉽고 결과 세트를 제한 할 수도 있습니다 (예 : 'select id from .....').
• ORM은 SQL과 전혀 거리를 두지 않아야합니다. 나는 mysql-client와 같은 DB 클라이언트에서 직접 임시 쿼리에 SQL을 많이 사용합니다. 균일 한 인터페이스와 그룹화 기능을 제공합니다.

ORM은 일반적인 관계형 DB 구현과 OO 언어 기능 간의 임피던스 불일치로 인해 존재합니다. 이들은 다리 일 뿐이지 만 대부분의 사람들은 냉장고에있는 림 버거 치즈처럼 SQL을 취급합니다.

SQL / 저장 프로 시저 / 뷰를 일급 인터페이스로 취급하는 대신 항상 ORM 또는 기타 추상화 된 데이터 액세스 계층을 사용한다고 말할 수 있다면 SQL을 건드리지 않아도 더 나을 것입니다.

실제로, 최종 유효성 검사를 위해 데이터베이스를 쿼리하는 데 적어도 SQL이 필요하지 않은 순수한 ORM 프로젝트는 본 적이 없습니다.

ORM은 프로그래머 도구 상자의 도구입니다. 그들은 자신의 문제가 있습니다. 몇 가지 예는 다음과 같습니다.

• SQL을 제어 할 수 없습니다
• n + 1 문제로 고생

수행중인 작업을 알고 있으면 ORM을 효과적으로 사용하여 많은 CRUD 유형 코드를 대체 할 수 있습니다. 복잡한 작업에는 효과적이지 않지만 성능 조정이 어렵습니다 (성능은 데이터베이스 디자인의 중요한 부분 중 하나이며 객체를 에뮬레이션하지 않음). SQL 자체를 이해하거나 쓰지 않습니다.

또한 복잡한보고는 ORM으로 효과적으로 수행하기 쉽지 않다는 점을 지적하고 싶습니다. 또한 쉬운 방법으로 간단한 SQL을 배우지 못하면보고를 위해 복잡한 SQL을 작성할 수있는 시점에 어떻게 도달 할 수 있습니까? 보고 요구 사항이없고 종종 복잡한 요구 사항이없는 응용 프로그램에서 작업 한 적이 없습니다.

ORM은 대부분 BI 또는 ETL 프로세스에 유용하지 않습니다. 또한 데이터베이스 관리 쿼리 나 감사 테이블에서 정보를 찾고 특정 데이터베이스 변경 세트를 실행 취소하는 데 유용하지 않습니다. 여전히 SQL로 가장 효과적으로 수행되는 많은 것들이 있습니다. 데이터베이스를 쿼리하는 응용 프로그램은 엔터프라이즈 환경에서 데이터베이스를 쿼리해야하는 부분 중 일부입니다.

또한 포스터가 SQL에서 수행하는 방법을 이미 알고있는 ORM을 사용하여 무언가를 수행하는 방법에 대한 많은 질문이 있습니다. 새로운 것을 배우는 것이 좋지만, 그들이 원래의 방법에 비해 실질적인 이득을 얻지 못하고 (그리고 종종 실제 성능 손실) 여분의 시간과 노력을들이는 이유는 무엇입니까?

때때로 클라이언트는 보고서, 내보내기, 데이터 덤프 등에 대한 데이터를 반환하기위한 빠르고 쉬운 쿼리를 원하고 전체 프로그램이 개발되기를 기다립니다.

또한 우수한 SQL 프로그래머는 내가 사용한 ORM보다 항상 더 빠르고 효율적인 SQL을 작성할 수 있습니다. 또한 많은 사람들이 ORM이 저장 프로 시저를 가리킨다는 사실을 발견했습니다. ORM의 이점을 실제로 무시하면 ORM은 복잡한 프로세스에 적합하지 않습니다.

또한 매우 풍부하고 강력한 프로 시저 언어로 Oracle과 같은 데이터베이스를 사용하는 경우 "프로그램"이 없어도 많은 작업을 수행 할 수 있습니다. Oracle의 PL / SQL은 매우 빠르고 효율적입니다.

데이터베이스를 직접 사용하려면 예. 사용하려고 시도한 대부분의 ORM이 충분하지 않거나 데이터베이스를 다루지 않았습니다. 또한 다루지 않은 사용자 지정 쿼리 문제를 해결하거나 작성하는 방법은 무엇입니까?

트리거 및 저장 프로 시저를 작성하는 데 여전히 필요합니다. 저장 프로시 저는 현재 선호도가 떨어졌지만 일부 상황에서는 여전히 유용합니다. 특히 털이 많은 다중 테이블 조인의 경우 SQL이 필요할 수 있습니다.

예, SQL 작성을 피할 수 있습니다. 그러나 대신 HQL (또는 Linq 또는 DQL ...)을 작성하게됩니다!

진심으로, 나는 ORM의 열렬한 팬이며, 대부분 순수 SQL 사용을 피할 수 있다고 생각합니다. 그러나 ORM은 하나의 큰 추상화이며 모든 큰 추상화는 누출됩니다 ...

(그러나 N + 1 문제는 지연 로딩과 관련이 있으며 대부분의 ORM 도구에는 열성 로딩을 요청하는 특정 방법이 있으므로 특정 문제를 피할 수 있습니다.)

ORM은 당신에게 어떤 점을 알려줄 것입니다. 그러나 복잡한 조인, 하위 쿼리, 공용체, 빼기, 분석 함수 등을 사용하여 실제로 복잡한 쿼리를 실행해야하는 경우가 있습니다. SQL이 필요할 때입니다. 그러나 모든 간단한 쿼리를 ORM에 맡길 때 어떻게 복잡한 쿼리를 작성해야합니까?

코드로 작성할 필요가 없더라도 데이터베이스 서버에 대한 터미널 액세스 권한이있을 때 코드를 사용하는 것이 매우 편리합니다.

또한, 프로그래밍에 어려움을 겪는 대부분의 경우 인생이 우리를 제한하는 한계 내에서 일하고 있습니다. 종종 우리 는 오래된 코드 또는 오래된 버전의 데이터베이스로 작업하고 있으며 어떤 언어로든 최신 ORM 라이브러리를 설치할 기회가 없습니다. 협력. 그러한 상황에서는 귀하가 처리 할 도구가 필요합니다.

나머지 시간에는 CRUD에 SQL이 필요하지 않지만 간단한 SELECT, INSERT, UPDATE 및 기본 JOIN 쿼리보다 SQL에 더 많은 것이 있습니다. 당신은 그것으로 매우 영리한 일을 할 수 있으며, 자주 사용하지는 않지만, 그것이 무엇인지 아는 것이 유용합니다.

점점 더 우리는 포스트 SQL 세계에서 자신을 발견 할 것이라고 생각하지만 대부분의 클라우드 서비스는 비 SQL 테이블 스토리지를 사용하며 간단한 CRUD 유형 작업에는 SQL의 모든 기능이 필요하지 않습니다. 그러나 이것이 그것을 이해하는 데 가치가 없다는 것을 의미하지는 않습니다.

또한, 물론, 누군가가 현재 사람들이 많이까지하지 않을 경우 더 나은 ORM 시스템을 쓸 정도로 알고 있습니다. 그들이 SQL을 알고 있다면 도움이 될 것입니다 ...

대규모 웹 응용 프로그램을 구축하는 데는 완전히 불필요하며 필요한 것보다 훨씬 스트레스와 시간을 낭비 할 수 있습니다. 그 이유는 모든 대규모 앱이 자주 사용하는 DB의 메모리 캐싱 부분이어야하는 RAM에서 메모리 지속성 계층을 사용해야하기 때문입니다.

작업 할 메모리가 부족한 모바일 장치 등을 사용하여 프로그래밍해야하는 응용 프로그램이 모바일 장치, 태블릿 등에서 "클라이언트"또는 독립형 응용 프로그램으로 실행되고있는 경우 SQL을 사용하는 것과 같은 것은 여전히 ​​일반적이고 중요합니다. 장치의 메모리가 너무 작아서 메모리에 많은 것을 캐시 할 수 없기 때문에 중요합니다.

작성하는 SQL의 복잡성과 양이 ORM 프레임 워크를 합리적으로 만드는 데 충분하지 않습니다.

(만약 한 달에 한 번 SQL을 작성합니다)

ORM 도구를 사용하여 개발자를 적극적으로 두려워하는 DBA와 함께 많은 대대를 만났습니다.

이들은 튜닝 및 성능과 관련된 DBA입니다.

그리고 예, ORM 도구는 이와 같은 작업을 수행 할 수 있지만 저장 프로 시저 (Sql Server) 만 허용하고 수행중인 작업에 대해 질문 할 곳을 보았습니다.

또한 ORM 도구는 Sql을 직접 작성하는 것만 큼 좋지 않은 Sql을 남용 할 수 있습니다.

한 가지 큰 문제-DDL 및 데이터베이스 마이그레이션. 때로는 기존 데이터를 손상시키지 않고 물건을 업데이트하기 위해 손으로 바느질해야합니다.