ORM 프레임 워크를 잘 알고 있으면 SQL이 중요합니까? [닫은]

나는 SQL에 대한 심각한 경험이 없으며 LINQ 대신 SQL을 쓰는 것을 싫어합니다. ORM에 만족합니다.

고용주와 부문 관점에서 SQL을 아는 것이 중요합니까? 마스터해야합니까? ORM 프레임 워크보다 순수한 SQL을 선호하는 회사는 프로그래밍 분야에서 "공룡"입니까?

기본 SQL 만 알고 있으면 ORM의 버팀목에 비해 많은 이점을 얻지 못 하기 때문에 많은 프로그래머에게 설명하기가 어렵습니다 . 그러나 고급 SQL 개념은 작동하는 응용 프로그램과 고품질 (특히 빠르고 안정적인) 응용 프로그램 간의 차이점의 중요한 부분입니다 .

나는 다른 사람을 믿고있어 설계 하고 있기 때문에, 당신을 위해 데이터베이스를 하는 것이 어떤 SQL을 모르고 단지 창백한를 벗어납니다. 그러나 당신이 그들에 대해서만 개발하고 있더라도, ORM이 여전히 잘하지 않거나 전혀하지 않는 모든 것들의 일부 목록은 다음과 같습니다.

• 재귀 및 / 또는 계층 쿼리
• 선택적 매개 변수 (특히 범위 술어로 변환)
• 사용자 정의 데이터 유형
• 플랫폼 별 유형 (SQL 계층 ID 및 TVP, Oracle 배열 및 중첩 테이블 등)
• 배치 삽입 / 업데이트 / 업 서트 / 삭제
• 색인 힌트
• 잠금 힌트 (특히 업데이트 잠금 및 더티 읽기)
• 오류 처리
• 외부 조인-결과 집합이 OOP 모델에 잘못 매핑되며 많은 ORM에 고유 한 쿼리 언어가 있지만 SQL 자체를 아는 것과 유사합니다.
• 저장 프로 시저 및 UDF, 특히 인라인 UDF 및 CROSS APPLY 쿼리를 통한 모듈화
• 여러 테이블에 데이터를 스테이징하기 위해 OUTPUT / RETURNING 사용
• 효율적인 페이징 쿼리
• 윈도우 기능 (rownum, rank, partition)을 기반으로하는 쿼리

이 목록은 계속 진행되고 있습니다. 많은 것들이 초보자 DBA가 해본 적이없고 초보자 개발자도 들어 본 적이없는 것입니다. 그러나 대규모 앱에서는 매우 중요합니다.

ORM은 정말 지루한 SQL 코드, 즉 모든 반복적 인 CRUD 및 매핑 및 기타 배관 코드의 속도를 높이는 데 정말 뛰어납니다. 따라서 사용하는 것은 부끄러운 일이 아니며 악의를 가진 사람의 말을 듣지 마십시오. 그러나 여전히 마스터 SQL 조차도 배우고 그래야하며 ORM이 무게를 풀지 않을 때 원시 DB 명령 / 쿼리에 빠질 준비가되어 있어야합니다.

물론! SQL은 여전히 ​​데이터베이스의 언어입니다. ORM을 많이 사용하더라도 ORM의 결정과 SQL이 생성하는 SQL을 이해하려면 SQL을 이해해야합니다. 또한 사용자 지정 SQL 및 저장 프로 시저와 관련하여 여전히 많은 일이 있습니다. 죄송합니다, 무료 점심은 없습니다.

예, 여전히 SQL을 알아야합니다. ORM은 매우 누출 된 추상화 이며 SQL의 모든 기능에 액세스 할 수 없습니다. 장난감 응용 프로그램의 경우 SQL 지식이 부족할 수도 있습니다. 엔터프라이즈 응용 프로그램의 경우 ORM에서 적절한 성능을 얻으려면 데이터베이스를 이해해야합니다. 또한 응용 프로그램 언어보다 SQL로 훨씬 쉽게 수행 할 수있는 많은 작업이 있습니다. Java 프로그래머가 한 시간 만에 SQL로 코딩 할 수있는 코드를 작성하는 데 며칠을 소비하는 것을 보았습니다. SQL 지식은 관계형 데이터베이스를 사용하는 응용 프로그램을 작성하는 모든 사람에게 매우 중요합니다.

SQL 기술은 오늘날 IT에 반드시 필요한 기술입니다. LINQ는 Microsoft Only 기술입니다. SQL 사용은 웹 및 클라이언트 / 서버 응용 프로그램 개발 그 이상입니다. SQL에 익숙하지 않은 경우 데이터베이스를 모델링하고 ETL을 수행 할 수 없습니다. ORACLE 및 SQL Server에서 데이터웨어 하우징 제품에 사용되는 SQL 언어를 마스터하지 않아도되지만 표준 SQL을 알아야합니다. SQL 기본 사항은 간단합니다. 시작하기에 많은 자료가 있습니다.

SQL 데이터베이스와 상호 작용하는 경우 ORM이 생성하는 SQL을 이해해야합니다. SQL 데이터베이스 고유의 개념을 이해하고 ORM이 할 수없는 것을 이해해야합니다. ORM은 삶을 더 쉽게 만들어줍니다. (그렇습니다. 많은 사람들이 없으면 공룡으로 자격을 얻는다고 생각합니다.)하지만 목발이 아니라 (학습을 방해하는) 도구가 아닙니다.

SQL 학습을 거부하면 ORM의 유무에 관계없이 SQL 데이터베이스를 다루는 비즈니스가 없으며 다른 유형의 작업을 찾아야합니다.

나는 내가 어려운 ORM 팬이며 ORM의 이점을 수년 동안 전파 해 왔으며 ORM이 왜 SQL보다 우선하는지에 대해 많은 이야기를했다는 것을 인정할 것입니다.

그러나...

나는 실제 세계에서 SQL이 완전히 필요하다는 것을 인정해야하며 모든 개발자는 SQL에 대해 잘 알고 있어야합니다.

거의 모든 경우에 SQL 프로세스가 ORM보다 빠릅니다. 대부분의 경우 ORM 출력을 낙관 할 수는 있지만 SQL 프로세스와 거의 비슷합니다.

경우에 따라 필요한 결과를 얻기 위해 무거운 SQL이 필요할 수 있으며 이러한 괴물 쿼리는 SQL 프로세스에서보다 쉽고 빠르게 만들 수 있습니다.

그냥 내 두 비트.

ORM이 생성하는 복잡한 것을 최적화해야 할 때가 올 것입니다. 이 시점에서 일반적으로 분석하기에는 매우 복잡한 쿼리가 있습니다. 기초를 배운 적이 없다면 어떻게 고급 학습을 통해 SQL 학습을 시작할 수 있습니까? 당신은 시작조차 충분히 이해하지 못할 것입니다. SQL을 이해하는 사람의 손에 든 ORM-좋은 도구입니다. SQL을 전혀 모르는 사람의 손에 든 ORM-재난이 기다리고 있습니다.

SQL이 데이터베이스를 이해하는 데 중요한 이유 중 하나는 응용 프로그램 프로그래머가 자연스럽게 데이터 세트에 대해 생각하지 않기 때문입니다. 그러나 데이터베이스가 효율적으로 작동하는 유일한 방법은 집합입니다. ORM을 사용하기 전에 세트로 생각하는 방법을 배워야합니다.

ORM 프레임 워크에서 쿼리를 수동으로 강제하지 않는 경우가 더 많습니다. 또한 대부분 자체 쿼리 언어가 있지만 SQL에서 영감을 얻은 코드는 SQL로 바뀌므로 문제가 발생하거나 잘못 수행 될 때 해당 SQL을 읽으면 무엇이 잘못되었는지 이해해야합니다.
따라서 SQL을 직접 작성하지 않더라도 기본 수준 이상으로 이해하십시오 (저장 프로 시저, 트리거 등을 작성하는 것에 대해 배울 필요는 없지만 데이터베이스에 액세스하는 것입니다). 생성 된 코드를 이해하고 필요에 따라 조정하기에 충분한 언어를 알아야합니다.

질문에 대해 이야기하기 전에 먼저 약간의 소개를하겠습니다. 나는 ORM을 좋아합니다. 그리고 나는 SQL이 싫어. ORM은 SQL과 같은 사용자에게 친숙하지 않은 혼란을 숨기고 데이터베이스를 처리하는 언어 통합 방식을 제공하기 때문에 ORM을 좋아합니다.

그러나 SQL에는 많은 이점이 있으며 더 큰 것이 정확하다는 점을 인정해야합니다. 쿼리를 거치는 것만으로도 기본 데이터베이스 스키마에 대한 자세한 지식없이 SQL 쿼리의 복잡성에 대해 거의 논쟁 할 수 있습니다. 따라서 SQL을 사용할 때는 항상주의를 기울여야하며 구성 요소의 복잡성이 어디로 향하고 있는지에 대한 직관이 항상 있습니다.

반면에 ORM을 사용할 때 데이터베이스 통합의 용이성에 압도되어 데이터베이스조차 없다는 것을 문자 그대로 잊어 버렸습니다. 이것은 여러 번 망쳤습니다. 과거에는 여러 차례 무고한 ORM 메소드를 호출했는데,이 비하인드 스토리는 방대하고 무서운 데이터베이스 조인을 호출하여 성능을 저하시킵니다.

그렇기 때문에 진실은 어딘가에 있습니다. 나는 ORM을 사용하는 것을 좋아하지만 계속 그렇게 할 것이지만, 좀 더 조심해야하고 ORM 메소드 호출의 의미 (SQL 레벨)를 항상 연구해야합니다. 추상화 계층의 의미를 아는 것은이 사업에서 순수한 금이며 추상화의 사용을 정당화합니다. 다른 것은 발로 자신을 쏘는 것과 같습니다.

빌드하려는 애플리케이션을 통해서만 데이터베이스와 상호 작용하는 것이 필요한 경우에는 필요하지 않을 수 있습니다. 일부 소규모 회사 나 개발자 팀에서는 약간의 지원이 필요할 수 있습니다. 클라이언트의 데이터베이스에 연결하고 몇 가지 SQL 문을 실행하여 데이터가 어떻게 진행되고 있는지 확인하는 것이 훨씬 쉽습니다.

훌륭하고 성숙한 ORM을 사용하더라도 비효율적 인 SQL을 내보내고 생성 된 SQL에서 진행중인 작업을 파악할 수 있으면 인생을 훨씬 쉽게 만들 수있는 상황에 빠지게됩니다. 즉, ORM에 능숙하고 선택한 DB에 프로파일 러를 사용하는 방법을 알고 있다면 "만들기 전까지는 쉽게 가짜"가 될 수 있습니다.

이러한 모든 유형의 질문에 대한 대답 ( "X를 알아야합니까?")은 "필요한 경우 필요할 때 처음 배울 수 있습니다"입니다.

효율적으로 수행하는 방법을 알지 못하거나 배우려고하지 않기 때문에 비효율적 인 일을 함정에 빠뜨리지 않는 것이 중요합니다.

예를 들어,이 특정한 경우에 PostCount사용자 테이블 의 필드가 때때로 부정확하게 하는 버그가 프로그램에 있다는 것을 알고 있다면 어떻게해야합니까?

버그를 수정하면 모든 사용자에 대해 PostCount를 업데이트해야합니다. 어떻게합니까?

ORM을 사용하여 약간의 스크립트를 작성하면 매우 비효율적입니다. 매우 간단한 SQL 쿼리가 수행됩니다.

이러한 상황은 매우 흔하기 때문에 위에서 설명한 함정에 빠질까 걱정됩니다!

예, 여전히 SQL이 필요합니다.

"오래된"무엇인가를 고려할 가치가 없다고 가정하지 마십시오. 소위 "레거시"기술은 시간의 시험을 거친 후에도 여전히 남아있는 기술입니다. 우리는 Wang 컴퓨터를 "레거시"라고 부르지 않고 실패했으며 사라졌습니다.

저에게 물어 보면 은행에서 메인 프레임 또는 IBM i에서 COBOL을 사용하고 있다고 귀찮게합니까? 절대 아닙니다. 이들은 견고하고 검증 된 진정한 기술입니다. 그들은 주로 DB2 SQL을 사용하는 것을 추측합니다. 이 달의 유행 언어로 개발 된 소프트웨어보다 돈을 신뢰하는 것이 훨씬 행복합니다.

공룡은이 지구에서 우리 인간보다 훨씬 오래 지속되었습니다. Jurasic Park를 읽는다면 (예, 책이 영화보다 낫습니다), 저는 여러분에게 묻습니다. "공룡"을 과소 평가하여 물리지 마십시오. ;-)

내가 경험하지 않은 게임 및 (주로 통계적인) 연구 외에도 데이터베이스 액세스 및 운영은 잘못된 결정으로 인해 성능이 크게 저하되는 몇 안되는 영역 중 하나 인 것 같습니다. 나는 코드에서보다 강력한 데이터베이스 추상화를 강력하게 믿는 사람이며 linq는 데이터베이스 작업을 프로그래밍 언어에 연결하여 언어의 모든 도구 (유형 검사, 구문 검사, 원하는 모든 것)를 제공합니다 원하는 프로그래밍을 수행 할 수있는 충분한 힘을 주면서도 정말 훌륭합니다. 불행히도 여전히 항상 작동하지는 않습니다. 즉, 추상화 계층에서 최적화가 잘못되어 결과를 얻기 위해 마이크로 초 대신 초 또는 몇 초가 아닌 몇 분 동안 대기 중일 수 있습니다. 시간이 매우 눈에 띄기 때문에 최적화하지 않으면 응용 프로그램이 작동하지 않습니다. 성능이 응용 프로그램의 가장 큰 문제가됩니다. 즉, 금속에 가까워지고 손을 최적화해야합니다.

우리가 큰 데이터 셋을 조작하는 것은 예를 들어 수동으로 할 때 3ms, 추상화 계층이 당신을 위해 그것을 할 때 100ms가 걸리는 지점에 도달하면, 추상화 계층이 당신을 위해 그것을 처리하게하십시오. 30 배 더 느리지 만 여전히 (대부분의 응용 프로그램에서) 충분히 빠릅니다. 그러나 실제 상황은 200ms의 응답 시간을 갖는 수작업으로 최적화 된 솔루션을보고 추상화 계층이이를 처리 할 때 알고리즘이 10 배의 성능 히트를 '단지'걸리는 것입니다. 2 초 지연된 다음, 그다지 빠르지 않은 것부터 고통스럽게 느리게 진행될 때까지 많은 것을 관리합니다. 관계형 데이터베이스 솔루션이 제대로 확장되지 않는 것을 확인, 나는 이것이 2-3 년 안에 해결 될 것이라고 생각하지 않습니다. 즉, 더 큰 데이터베이스와 관련하여 상당한 시간 동안 베어 메탈에 접근해야하거나 응용 프로그램이 너무 느려 경쟁 업체에 견딜 수 없다는 것을 의미합니다.