ORM 또는 플레인 SQL 사용
제가 개발한 (그 후 잊고 있는) 일부 앱은 주로 MySQL용 플레인 SQL을 작성했습니다.SQL Chemy처럼 Python에서 ORM을 사용한 적은 있지만 오래 지속되지는 않았습니다.보통 서류나 복잡성(내 관점)이 발목을 잡았습니다.
예를 들어 이동성을 위해 ORM을 사용하고, 데이터베이스 유형을 하나만 사용할 경우 일반 SQL을 사용합니다.데이터베이스 지원이 필요한 앱을 개발할 때 ORM이나 SQL을 언제 사용해야 하는지 조언을 구하고 있습니다.
ORM을 사용하는 경우와 비교하여 데이터베이스의 불일치를 처리하기 위해서는 경량 래퍼를 사용하는 것이 훨씬 좋습니다.
Hibernate, Eclipse Link, Toplink, OpenJ를 포함한 JPA(Java Persistence API, 기본적으로 Java/J2EE/EJB용 표준화된 ORM API)를 사용하여 오랜 시간을 작업한 사람입니다.PA와 다른 분들께 제 관찰 내용을 말씀드리겠습니다.
- ORM은 고속이 아닙니다.이러한 시스템은 충분할 수 있고 대부분의 경우 문제가 없지만, 대용량의 저지연 환경에서는 문제가 없습니다.
- Java 및 C#과 같은 범용 프로그래밍 언어에서는 이들을 작동시키기 위해 엄청난 마력이 필요합니다(자바의 로드 타임 위빙, 인스트루먼트 등).
- ORM을 사용하면 (의도적인 것처럼 보이는) SQL에서 더 멀리 가는 것이 아니라 ORM이 퍼포먼스 SQL을 생성하기 위해 XML 및 주석/속성을 조정하는 데 얼마나 많은 시간을 소비하는지 놀랄 것입니다.
- 복잡한 질의에 대해서는 다른 대안이 없습니다.JPA와 마찬가지로 원시 SQL에는 불가능한 쿼리가 있으며 JPA에서 원시 SQL을 사용해야 하는 경우에는 적합하지 않습니다(C#/).Net에는 적어도 오브젝트 어레이보다 훨씬 뛰어난 동적 유형(var)이 있습니다.
- ORM을 사용할 때는 의도하지 않은 동작이나 예기치 않은 동작이 많이 발생합니다.데이터베이스에 SQL 업데이트를 실행하는 기능을 내장해야 한다는 사실(JPA 또는 이와 유사한 메서드에서 refresh()를 사용하여 기본적으로는 모든 것을 캐시하므로 직접 SQL 업데이트를 실행하는 것은 일반적인 프로덕션 지원 활동입니다).
- 오브젝트-관계 미스매치는 항상 문제를 일으킵니다.이러한 문제에는 추상화의 복잡성과 완전성 사이에 트레이드오프가 있습니다.때때로 나는 JPA가 너무 지나쳐 복잡성에 부딪힌 수익 감소의 진짜 법칙에 부딪혔다고 느꼈다.
조금 더 설명이 필요한 또 다른 문제가 있습니다.
웹 애플리케이션의 전통적인 모델은 지속성 계층과 프레젠테이션 계층을 갖는 것입니다(아마도 서비스 또는 다른 계층을 사이에 두고 있지만 이 두 계층은 이 논의에서 중요한 두 가지입니다.ORM은 지속성 레이어에서 프레젠테이션레이어(즉 엔티티)까지 경직된 뷰를 강제합니다.
raw SQL 메서드의 비판 중 하나는 이러한 모든 VO(값 개체) 또는 DTO(데이터 전송 개체)가 하나의 쿼리에 의해 사용된다는 것입니다.이것은 ORM의 장점으로 선전되고 있습니다.이것은, ORM이 불필요하기 때문입니다.
이러한 문제는 ORM과 함께 사라지지 않고 프레젠테이션 계층으로 넘어갑니다.쿼리의 VO/DTO를 작성하는 대신 커스텀프레젠테이션 오브젝트(통상은 뷰마다 1개씩)를 만듭니다.이게 더 나아요?IMHO 아니야.
나는 이것에 대해 ORM이나 SQL에 썼다: 우리는 아직 도착하지 않았는가?
제가 요즘 선택한 지속성 기술은 (자바에서) ibatis입니다.SQL은 JPA의 90% 이상의 기능을 수행하지만(정확하게 문서화되어 있지는 않지만) 훨씬 적은 오버헤드(복잡성과 실제 코드 측면에서) 훨씬 적은 양의 작업만 수행할 수 있습니다.
이것은 작년에 제가 쓰고 있던 GWT 어플리케이션에서 나왔습니다.서비스 구현 시 Eclipse Link에서 프레젠테이션 개체로의 많은 변환.ibatis를 사용했다면 ibatis로 적절한 오브젝트를 만들고 스택을 위아래로 넘기는 것이 훨씬 간단했을 것입니다.일부 순수주의자들은 이것이 Bad™라고 주장할 수 있습니다.(이론적으로는) 그럴지도 모르지만, 이렇게 하면 코드도 심플해지고 스택도 심플해지고 생산성도 향상됩니다.
ORM에는 몇 가지 좋은 기능이 있습니다.데이터베이스 열을 객체 필드에 복사하는 대부분의 작업을 처리할 수 있습니다.일반적으로 언어의 날짜 및 시간 유형을 적절한 데이터베이스 유형으로 변환하는 작업을 처리합니다.이들은 일반적으로 중첩된 객체를 인스턴스화함으로써 일대다 관계를 상당히 우아하게 처리합니다.ORM의 장점과 단점을 염두에 두고 데이터베이스를 설계하면 데이터베이스 안팎에서 데이터를 가져오는 데 많은 노력이 절약된다는 것을 알게 되었습니다.(다형성 및 다대다 관계를 매핑해야 하는 경우 이를 어떻게 처리하는지 알고 싶을 것입니다.ORM을 '컴퓨터 과학의 베트남'이라고 부르는 '임피던스 미스매치'의 대부분을 제공하는 것은 이 두 영역입니다.)
트랜잭션형 애플리케이션(예: 요청을 작성하거나 개체를 가져오거나 데이터를 이동하거나 웹 페이지에 렌더링하는 경우)의 경우 성능 세금은 적고, ORM은 이전에 본 개체를 캐시하기 때문에 더 빠를 수 있으며, 그렇지 않으면 데이터베이스를 여러 번 쿼리할 수 있습니다.
보고량이 많거나 요청당 데이터베이스 행 수가 많은 애플리케이션의 경우 ORM 세금은 훨씬 더 많이 부과되고 캐싱은 메모리 보유에 큰 부담이 됩니다.이 경우 간단한 SQL 매핑(LinQ 또는 iBatis) 또는 씬 DAL의 수작업으로 코딩된 SQL 쿼리를 사용하는 것이 좋습니다.
모든 대규모 애플리케이션에 대해 두 가지 접근 방식을 모두 사용할 수 있습니다(ORM은 CRUD의 경우이고 SQL/씬 DAL은 보고의 경우).
읽기에는 플레인 SQL, CUD에는 ORM이라고 합니다.
특히 웹 어플리케이션에서는 퍼포먼스가 항상 신경이 쓰입니다만, 코드의 유지 보수성과 가독성도 중시됩니다.이러한 문제를 해결하기 위해 SqlBuilder를 작성했습니다.
ORM은 단순한 휴대성이 아닙니다(ORM을 사용해도 달성하기 어렵습니다).ORM 툴을 사용하면 보일러 플레이트 SQL 쿼리(PK 또는 술어, 삽입, 업데이트 및 삭제에 의한 선택)를 쓸 수 없게 되어 문제 영역에 집중할 수 있게 됩니다.
중요한 설계에서는 임피던스 불일치를 처리하기 위해서만 데이터베이스에 대한 추상화가 필요합니다.그러나 가장 간단한 첫 번째 단계(대부분의 경우 적합)는 중량 ORM이 아닌 DAL입니다.당신의 유일한 선택지는 그 범위의 끝에 있는 것이 아닙니다.
DAL과 ORM을 구별하는 방법을 설명하는 코멘트에 응답하여 편집:
DAL은 사용자가 직접 작성하는 것입니다.테이블을 캡슐화하고 해당 필드를 속성에 매핑하는 클래스에서 시작할 수 있습니다.ORM은 dbms 스키마의 다른 속성(대부분 PK 및 FK)에서 추론된 추상화 메커니즘에 대해 작성하지 않는 코드입니다(여기서 자동 추상화가 누출되기 시작하는지 여부를 확인할 수 있습니다).일부러 알려드리고 싶지만 제 개인적인 취향일 수도 있습니다).
제 ORM 사용을 가능하게 한 열쇠는 코드 생성이었습니다.코드 성능 측면에서 ORM 경로가 가장 빠르지 않다는 데 동의합니다.그러나 중간 규모에서 대규모 팀이 있는 경우 DB가 빠르게 변화하고 있습니다. 빌드 프로세스의 일부로 DB에서 클래스와 매핑을 재생성하는 기능은 특히 CI를 사용할 때 매우 유용합니다.따라서 코드 속도가 가장 빠르지 않을 수도 있지만 코딩 속도가 가장 빠를 수도 있습니다. 대부분의 프로젝트에서 어떤 코드를 사용할지 알고 있습니다.
스키마가 유동적인 상태에서 ORM을 사용하여 개발하고 프로파일링을 사용하여 병목 현상을 찾아내고 필요한 영역을 raw SQL을 사용하여 조정하는 것이 좋습니다.
Hibernate에 내장된 캐싱은 올바른 방법으로 사용한다면 많은 경우 성능을 크게 향상시킬 수 있습니다.더 이상 DB로 돌아가서 참조 데이터를 읽을 필요가 없습니다.
프레임워크 사용 여부에 대한 딜레마는 현대의 소프트웨어 개발 시나리오에서 매우 흔합니다.
이해해야 할 중요한 것은 모든 프레임워크 또는 접근 방식에는 장단점이 있다는 것입니다.예를 들어, 우리의 경험상 ORM은 거래를 처리할 때 유용하다는 것을 알 수 있습니다.삽입/갱신/삭제 작업 - 그러나 복잡한 결과를 가진 데이터를 가져올 때는 ORM 도구의 성능과 효과를 평가하는 것이 중요합니다.
또, 프레임워크나 어프로치를 선택해, 그 안에서 모든 것을 실행할 필요는 없다는 것을 이해하는 것도 중요합니다.즉, ORM과 네이티브 쿼리 언어를 혼재시킬 수 있습니다.많은 ORM 프레임워크는 네이티브 SQL의 플러그인에 확장 포인트를 제공합니다.우리는 틀이나 접근 방식을 너무 많이 사용하지 않도록 노력해야 한다.특정 프레임워크 또는 접근방식을 조합하여 적절한 솔루션을 제공할 수 있습니다.
삽입, 갱신, 삭제, 버전 관리 시 ORM을 사용할 수 있습니다.또한 Native SQL을 사용하여 보고서 생성 및 장기 목록을 작성할 수 있습니다.
'일률적인' 솔루션은 없습니다.또한 이것은 '내가 or/m을 사용해야 하는가, 말아야 하는가'라는 질문에도 해당됩니다.
다른 논리를 사용하지 않고 매우 '데이터'에 초점을 맞춘 애플리케이션/툴을 작성해야 하는 경우에는 일반 SQL을 사용합니다.SQL은 이런 종류의 애플리케이션에서는 도메인 고유의 언어이기 때문입니다.
한편, 만약 내가 많은 '도메인' 로직을 포함하는 비즈니스/엔터프라이즈 애플리케이션을 쓴다면, 나는 이 도메인을 코드로 표현할 수 있는 리치 클래스 모델을 쓸 것이다.이 경우 OR/M 매퍼는 많은 배관 코드가 필요하기 때문에 매우 도움이 될 수 있습니다.
제가 개발한 앱 중 하나는 파이썬으로 작성된 IRC 봇입니다.사용하는 모듈은 별도의 스레드로 동작하지만 sqlite를 사용할 때 스레드를 처리하는 방법을 찾지 못했습니다.하지만, 그건 다른 질문으로 가는 게 나을 수도 있어요.
제목과 실제 질문을 모두 다시 썼어야 했어요.실제로 DAL을 사용해 본 적이 없습니다.어떤 언어에서도요.
SQL과 동일하게 작동하지만 컴파일 시간 검사 및 유형 안전성을 제공하는 ORM을 사용합니다.내가 좋아하는 것 처럼:데이터 놀리지 오브젝트(공개:내가 썼어)
예를 들어 다음과 같습니다.
for (Bug bug : Bug.ALL.limit(100)) {
int id = bug.getId();
String title = bug.getTitle();
System.out.println(id +" "+ title);
}
풀 스트리밍간단하게 설정할 수 있습니다(정의할 매핑 없음 - 기존 스키마를 읽습니다).조인, 트랜잭션, 내부 쿼리, 집약 등을 지원합니다.SQL에서 할 수 있는 거의 모든 것.대규모 데이터 세트(재무 시계열)에서 사소한 데이터 세트(Android)까지 모두 검증되었습니다.
이 질문이 아주 오래됐다는 건 알지만, 혹시나 저처럼 누가 이 질문을 발견하면 답을 올리려고 했어요.ORM은 많은 발전을 이루었습니다.그 중 일부는 개발의 생산성과 성능 유지라는 두 가지 장점을 모두 제공합니다.
SQL Data(http://sqldata.codeplex.com를 참조하십시오.모든 베이스를 커버하는 c#의 매우 가벼운 ORM입니다.
참고로 저는 SQL Data의 저자입니다.
'중간지대가 있다!'라는 후렴구에 제 목소리를 더하고 싶습니다.
애플리케이션 프로그래머에게 SQL은 제어하고 싶은 것과 제어하고 싶지 않은 것이 혼재되어 있습니다.
제가 항상 원했던 것은 완전히 예측 가능한 결정(SQL 키워드의 철자법, 괄호의 위치, 컬럼 에일리어스의 작성 시기, 2개의 플로트와 int를 저장하는 클래스에 대해 작성해야 하는 컬럼)을 담당하는 레이어(DAL, ORM, 마이크로 ORM 중 어느 것이든 상관없습니다)입니다.SQL의 상위 수준(JOIN, 서버 측 계산, DISTINT, GROUP BY, 스칼라 서브쿼리 등)을 담당하게 되었습니다.
그래서 이렇게 써놨어요.http://quince-lib.com/
C++용: 그것이 당신이 사용하는 언어인지 아닌지는 모르겠지만, 마찬가지로 '중도'가 어떻게 보일지 보는 것도 재미있을지도 모릅니다.
언급URL : https://stackoverflow.com/questions/494816/using-an-orm-or-plain-sql
'programing' 카테고리의 다른 글
| 스크립트에서 사용할 커스텀 타입을 PowerShell에서 작성하려면 어떻게 해야 합니까? (0) | 2023.04.22 |
|---|---|
| 숨겨진 UIView가 있는 자동 레이아웃? (0) | 2023.04.22 |
| 목록 안으로 항목을 이동하시겠습니까? (0) | 2023.04.22 |
| 필터링된 데이터의 행 수 (0) | 2023.04.22 |
| 함수 내에서 발신자의 명령줄 인수에 액세스하려면 어떻게 해야 합니까? (0) | 2023.04.22 |