Java 프로그래밍 - SQL 문을 어디에 저장해야 합니까?
JDBC 호환 응용 프로그램이 SQL 문을 저장하는 위치와 이유는 무엇입니까?
지금까지, 다음의 옵션을 특정할 수 있었습니다.
- 비즈니스 오브젝트로 하드 코드화
- SQLJ 절에 포함됨
- 다른 클래스로 캡슐화한다.데이터 액세스 오브젝트
- 메타데이터 기반(데이터 스키마에서 개체 스키마를 분리 - 메타데이터에서 개체 스키마 간의 매핑 설명)
- 외부 파일(프로퍼티 또는 리소스 파일 등)
- 스토어드 프로시저
각각에 대한 "장점"과 "단점"은 무엇입니까?
SQL 코드를 "코드" 또는 "메타데이터" 중 어느 것으로 간주해야 합니까?
저장 프로시저는 성능 최적화에만 사용해야 하는가, 아니면 데이터베이스 구조의 적법한 추상화인가?
퍼포먼스가 결정의 핵심 요소입니까?벤더에 의한 제약은 어떻습니까?
느슨한 커플링과 촘촘한 커플링 중 어떤 것이 더 좋으며 그 이유는 무엇입니까?
편집: 답변 감사합니다.요약:
메타데이터에 의존합니다.오브젝트 릴레이셔널 맵핑(ORM)
장점:
- 매우 추상적 - 모델을 변경할 필요 없이 DB 서버를 전환할 수 있습니다.
- 광범위 - 사실상 표준
- SQL 소요량 절감
- SQL을 리소스 파일에 저장할 수 있습니다.
- 퍼포먼스(통상)는 양호
- 메타데이터 기반 접근법
- (데이터베이스) 벤더의 독립성
단점:
- SQL 및 진정한 개발자의 의도를 숨김
- DBA가 SQL을 검토/변경하기 어렵다
- 이상한 경우 SQL이 필요할 수 있음
- 고유 쿼리 언어를 강제로 사용할 수 있습니다.HQL
- 최적화(추상)에 적합하지 않음
- 참조 무결성이 부족할 수 있습니다.
- SQL에 대한 지식이 없거나 DB에서 코드화할 준비가 되어 있지 않은 대신
- 네이티브 데이터베이스의 퍼포먼스에 필적하지 않는다(비록 근접해도)
- 모델 코드는 데이터베이스 모델과 매우 긴밀합니다.
DAO 계층에 하드 코드화/캡슐화
장점:
- SQL은 데이터에 액세스하는 개체로 유지됩니다(캡슐화).
- SQL은 쓰기 쉬움(개발 속도)
- 변경이 필요한 경우 SQL을 쉽게 추적할 수 있습니다.
- 심플한 솔루션(아키텍처가 복잡하지 않음)
단점:
- DBA가 SQL을 검토/변경할 수 없음
- SQL은 DB 고유의 것이 될 가능성이 높다
- SQL의 유지보수가 어려워질 수 있다
스토어드 프로시저
장점:
- SQL이 데이터베이스에 유지됨(데이터에 근접함)
- SQL은 DBMS에 의해 해석, 컴파일 및 최적화됩니다.
- SQL은 DBA가 쉽게 확인/변경 가능
- 네트워크 트래픽 감소
- 보안 강화
단점:
- SQL이 데이터베이스에 연결되어 있다(벤더 록인)
- SQL 코드는 유지보수가 어렵다
외부 파일(프로퍼티 또는 리소스 파일 등)
장점
- 애플리케이션을 재구축할 필요 없이 SQL을 변경할 수 있습니다.
- SQL 로직과 애플리케이션 비즈니스 로직 분리
- 모든 SQL 문의 중앙 저장소– 유지보수가 용이함
- 알기 쉽다
단점:
- SQL 코드가 유지보수가 불가능해질 수 있습니다.
- SQL 코드에서 (구문) 오류를 확인하기 어렵다
SQLJ 절에 포함됨
장점:
- 구문 검사 향상
단점:
- Java와 너무 밀접하게 연결됨
- JDBC보다 낮은 퍼포먼스
- 동적 쿼리 부족
- 그다지 인기가 없다
일반적으로 응용 프로그램의 크기 및 재사용성이 커질수록 SQL 문을 외부화/축소해야 합니다.
하드코딩(정적 최종 상수로)이 첫 번째 단계입니다.파일(properties/xml 파일)에 보존하는 순서는, 다음과 같습니다.메타데이터 구동(Hibernate/J 등의 ORM에 의해 실행됨)PA)가 마지막 단계입니다.
하드코드는 코드가 DB에 고유해질 가능성이 높고 변경 시마다 다시 작성/재구축/재등록해야 한다는 단점이 있습니다.장점은 한 곳에 있다는 것입니다.
파일에 저장하면 응용 프로그램이 커지면 유지보수가 불가능해질 수 있다는 단점이 있습니다.DAO 방식을 추가할 필요가 없는 한 앱을 다시 작성/재구축할 필요가 없다는 것이 장점입니다.
메타데이터 기반은 모델 코드가 데이터베이스 모델과 매우 긴밀하다는 단점이 있습니다.데이터베이스 모델을 변경할 때마다 코드를 다시 작성/재구축/재등록해야 합니다.매우 추상적이고 모델을 변경할 필요 없이 DB 서버에서 쉽게 전환할 수 있다는 장점이 있습니다(하지만 지금 자문해 보십시오: 기업이 DB 서버에서 얼마나 자주 전환합니까?).적어도 3년에 한 번 정도일 겁니다.그렇죠?
스토어드 프로시저는 이 문제를 "좋은" 솔루션이라고 할 수 없습니다.그들은 전혀 다른 목적을 가지고 있다.단, 사용하는 DB / 구성에 따라 코드가 달라집니다.
이것이 최적인지는 모르겠지만, 제 경험상 DAO 계층에 하드 코드(즉, 문자열 리터럴)가 되어 버립니다.
상당히 큰 질문이기 때문에, 어느 누구도 당신이 원하는 프로/콘을 설명할 것이라고는 생각하지 않습니다.그 대신에, 지금까지 사용해 온 것과 향후의 사용법을 나타냅니다.
DAL에서 SQL 하드코드를 사용하곤 했어요DBA가 SQL을 사용하고 싶어할 때까지는 이 정도면 충분하다고 생각했습니다.그런 다음 파일을 찾아 포맷한 후 DBA에게 전송해야 합니다.누가 그걸 비웃고 다 대신할 것인가.하지만 좋은 물음표나 잘못된 순서로 물음표가 없으면 자바 코드에 다시 붙일 수 있습니다.
또한 ORM을 사용해 왔습니다.개발자에게는 매우 좋은 일이지만, DBA는 ORM을 비웃을 만한 SQL이 없기 때문에 ORM을 싫어했습니다.데이터베이스를 삭제하는 습관이 있는 이상한 ORM(서드파티 서플라이어의 커스텀 ORM)도 사용했습니다.그 후 JPA를 사용해 왔습니다만, DBA를 경유해 복잡한 JPA를 사용하는 것은 매우 어려운 일입니다.
현재 스토어드 프로시저를 사용하고 있습니다(콜스테이트먼트가 하드코드 되어 있습니다).이제 모든 사람들이 불평할 첫 번째 것은 당신이 데이터베이스에 묶여 있다는 것입니다.너야.데이터베이스를 얼마나 자주 변경했습니까?다른 코드에 의존하는 수, DBA 재교육, 데이터 마이그레이션 등 시도조차 할 수 없다는 것을 알고 있습니다.그것은 매우 비싼 수술이 될 것이다.그러나 고객이 DB를 즉시 변경해야 하는 경우에는 SP가 아웃될 수 있습니다.
앞으로 코드 생성 툴과 함께 스토어드 프로시저를 사용하여 Oracle 패키지에서 Java 클래스를 만들고 싶습니다.
2013-01-31 편집: 몇 년 후 DBA가 Hibernate를 사용하므로 꼭 필요한 경우에만 SQL(DB에 저장된 프로세서)로 이동합니다.이것이 최선의 해결책이라고 생각합니다.99%의 DB는 SQL에 대해 걱정할 필요가 없으며, 1%는 이미 익숙한 곳에 있습니다.
ORM(휴면 상태 등)을 사용하면 SQL 문을 걱정할 필요가 없습니다.퍼포먼스는 보통 허용 가능한 수준이며 벤더에 의존하지 않습니다.
SQL 코드를 "코드" 또는 "메타데이터" 중 어느 것으로 간주해야 합니까?
코드
저장 프로시저는 성능 최적화에만 사용해야 합니까, 아니면 데이터베이스 구조의 적법한 추상화입니까?
저장 프로시저는 다른 저장 프로시저 내부를 포함하여 재사용할 수 있습니다.즉, 데이터베이스로 한 번 이동하여 지원 명령을 실행할 수 있습니다.최소한의 트래픽량이 이상적입니다.ORM 또는 sproc, db & back으로 가는 회선상의 시간은 회복할 수 없습니다.
ORM은 추상화 때문에 최적화에 적합하지 않습니다.IME, ORM은 참조 무결성의 결여를 의미하기도 합니다.데이터베이스를 보고하기 어렵게 만듭니다.복잡성이 줄어들던 것이 이제는 데이터를 제대로 활용할 수 있게 되었습니다.
퍼포먼스가 결정의 핵심 요소입니까?벤더에 의한 제약은 어떻습니까?
아니, 단순함은.데이터베이스에서도 벤더 록인이 발생합니다.SQL은 비교적 표준화 되어 있지만 벤더 고유의 작업 방법이 있습니다.
Java 세계에서의 벤더 록인에 대한 두려움은 흥미롭다.
Oracle Enterprise에 $5,000의 CPU를 지불하지 않고, Mysql로 바로 전환하기 위해 최소 공통분모만 사용하셨기를 바랍니다.우수한 DBA라면 누구나 알 수 있듯이, 특히 잠금 모델과 그 일관성 확보 방법에 대해 서로 다른 유명 데이터베이스 간에 미묘한 차이가 있습니다.
따라서 벤더에 의존하지 않는 SQL의 원칙만을 바탕으로 SQL 콜을 구현하는 방법에 대해 결정하지 마십시오. 실제 (비즈니스) 이유가 있습니다.
SQL Inside Stored Procedures는 데이터베이스 시스템에 의해 최적화되고 속도를 위해 컴파일됩니다.이것은 SQL의 자연스러운 홈입니다.SQL은 데이터베이스 시스템에서 인식되며 데이터베이스 시스템에서 구문 분석됩니다.SQL은 가능하면 데이터베이스에 보관합니다.저장된 프로시저나 함수 또는 데이터베이스 시스템이 제공하는 로직 단위로 정리하고 사용자 또는 다른 사용자가 언급한 도구 중 하나를 사용하여 SQL에 대한 간단한 호출을 수행합니다.
데이터베이스 시스템의 SQL 코드를 DB 외부에 저장하는 이유는 무엇입니까?개발 속도를 위해 자주 사용됩니다.ORM 매핑을 사용하는 이유는 무엇입니까?- ORM 매핑을 통해 여러 데이터베이스 시스템 간에 호환성이 제공된다고 하는 사람도 있습니다.그러나 실제로 어플리케이션이 구축되었을 때 데이터베이스 플랫폼에서 벗어나는 경우는 거의 없습니다.특히 레플리케이션 등의 고도의 기능을 사용하기 시작할 때 데이터베이스 시스템이 이행하는 경우는 드물지만, 데이터베이스 시스템이 이행하는 경우는 거의 없습니다.일부 작업이 보증됩니다.ORM의 단점 중 하나는 SQL 지식이 부족하거나 db에서 코드화하는 데 주의가 부족하다는 것을 대신하는 경우가 많다고 생각합니다.또한 ORM은 네이티브 데이터베이스의 퍼포먼스에 근접해도 결코 필적하지 않습니다.
저는 SQL 코드를 데이터베이스에 보관하고 당신이 사용하고자 하는 API나 인터페이스를 통해 SQL 코드를 간단하게 호출하는 편입니다.또한 이러한 호출을 추상 클래스나 OO 인터페이스 뒤에 배치하여 데이터베이스 호출이 이루어지는 지점을 추상화함으로써(메서드로 표현됨) 새로운 종류의 데이터 소스에서 스왑을 수행하는 경우 비즈니스 계층에 원활하게 연결될 수 있습니다.
명확한 답변이 있는 유일한 질문은 "SQL 코드인가 메타데이터인가?"입니다.이것은 확실히 코드이기 때문에 소스 코드 제어에 보관하고 최신 버전으로 쉽게 업데이트하여 문제가 발생하지 않을 경우 롤백할 수 있는 시스템을 갖추어야 합니다.
응용 프로그램에서 SQL을 실행하는 세 가지 방법을 살펴보았는데 각각 장단점이 있습니다.최선의 방법은 없지만, 가장 좋은 것은 당신의 어플리케이션과 잘 맞는 것을 선택하고 그것을 고수하는 것입니다.
- ORM - 필요한 SQL의 양을 줄이고 많은 세부사항을 처리합니다.몇 가지 사용자 지정 SQL을 수행해야 합니다.이 문제를 정상적으로 처리하는 ORM이 있는지 확인합니다.
- 데이터 액세스 개체 - 데이터에 액세스하는 개체에 SQL을 유지합니다.그러면 데이터베이스가 캡슐화되어 나머지 애플리케이션에서 기본 DB 구조에 대해 알 필요가 없으며 이러한 개체에 대한 인터페이스만 알 필요가 없습니다.
- 스토어드 프로시저 - 모든 SQL을 데이터베이스에 저장하여 DBA가 상황을 쉽게 파악할 수 있도록 합니다.필요한 것은 코드로부터 저장된 프로를 호출하는 것 뿐입니다.
iBatis SQL 매퍼를 사용하게 되었습니다.이것은 Hibernate와 같은 ORM보다 금속에 가깝습니다.iBatis에서는 SQL 문을 클래스 경로에 있어야 하는 XML(리소스 파일)에 넣습니다.
@ocdecio의 ORM 옵션을 추가하면 접근법 목록이 상당히 포괄적으로 보입니다.ORM을 사용하는 것과 SQL 매퍼와 리소스 파일을 사용하는 것이 가장 좋은 방법이라고 생각합니다.SQLJ는 별로 활용되지 않아 Java와 밀접하게 연결되어 있지 않습니다.또한 스토어드 프로시저는 특정 데이터베이스 벤더와 연결되므로 사용하지 마십시오(스토어드 프로시저에는 표준이 거의 없습니다).
대부분의 사용자와 마찬가지로 저도 Gamut 전체를 살펴보았지만 SQL을 최고의 언어로 생각해야 합니다.SQL이 DB에 저장되어 풀다운되었다가 다시 실행되는 경우도 있습니다.
지금까지 본 것 중 가장 성공한 시스템은 저장 프로시저, 기능 및 뷰를 채택하고 있습니다.
저장된 프로세서는 SQL 텍스트를 DB에 보관하고 배포 및 사용자 지정(이를 지원하려면 적절한 설계가 많이 필요)에 의해 비교적 신속하게 변경할 수 있습니다.
모든 투영은 동일한 이유로 뷰와 단순 선택을 통해 이루어져야 하며, 모든 투사 논리가 뷰 내에 포함되어야 합니다.
공장 배치에 DAO를 사용할 것을 권장합니다.필요한 오브젝트의 예는 다음과 같습니다.
public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO
이 스타일은 데이터 상호작용을 레이어하기 때문에 데이터베이스를 전환하거나 ORM 테크놀로지로 이행하는 경우 코드의 레이어를 하나만 변경하면 됩니다.
이 세 가지 사이에는 큰 차이가 없습니다.
- 비즈니스 오브젝트로 하드 코드화
- SQLJ 절에 포함됨
- 다른 클래스로 캡슐화한다.데이터 액세스 오브젝트
문자열 형식의 SQL 코드를 Java 코드에 직접 삽입할 것으로 예상됩니다.1과 3은 아마도 JDBC(또는 Apache DbUtils 등의 일부 도구)를 직접 사용하는 반면, 2는 스택에 프리프로세서 기술을 추가하여 컴파일 전에 관련 JDBC 코드를 생성합니다.
따라서 기본적으로 이러한 솔루션에 SQL이 포함되어 있다면 다음 기술 중 하나를 사용하는 것이 좋습니다.
- JPA Criteria API, Java에서 JPQL을 내부 도메인 고유 언어로 모델링
- jOOQ, Java에서 내부 도메인 고유의 언어로 SQL 모델링
또한 SQLJ 또는 실제 문자열 연결을 사용하는 것보다 더 쉽게 Java에 SQL을 삽입할 수 있는 다른 도구도 있을 수 있습니다.
지금까지 경험으로 볼 때 DAO 오브젝트에서 sql 문을 하드 코딩하는 것이 널리 사용되는 방식이지만, 가장 선호되지 않는 방식이라고 생각합니다.sql 문을 속성 파일에 저장하는 것이 가장 좋습니다.또한 java.util과 같은 속성 파일에 대한 인터페이스를 통해 DAO 개체의 문을 가져옵니다.속성.Prepared Statement 접근 방식을 통해 sql 문에 ?s를 삽입하여 매개 변수를 전달할 수 있습니다.
이러한 접근 방식은 애플리케이션 비즈니스 로직에서 SQL 로직을 분리하는 데 도움이 됩니다.이를 통해 모든 sql 문의 중앙 저장소를 사용할 수 있게 되어 쉽게 수정할 수 있으므로 애플리케이션 로직 내에서 데이터베이스 문을 검색할 필요가 없습니다.이해력도 향상됩니다.
내 것은 자원 번들로 끝납니다.정상적이지 않다는 것을 알지만, 저와 "나"가 아닌 누구라도 유지하기가 가장 쉽습니다.그것은 간단하고 논리적이다.
사실 제 접근 방식을 사용하는 사람이 있는지 궁금해요.
rexem이 기술한 SQL 스테이트먼트는 코드입니다.이것은 코드처럼 취급해야 합니다.외부화되어서는 안 됩니다(정당한 이유가 있습니다).그 스테이트먼트에서 SQL 데이터를 처리하는 코드와 함께 배치해야 합니다.오늘날 프레임워크 ORM/iBatis는 일상적인 JDBC 개발에 많은 심플화를 제공합니다.
질문에 대한 답변은 다음 질문에서 찾을 수 있습니다.SQL 문이 저장되는 방법은 응용 프로그램의 중요도에 따라 달라집니다.무엇을 원하십니까?고도의 보안, 코드 또는 유지보수의 용이성, 크로스 플랫폼 또는 벤더 록인다음 질문은 순수한 SQL 또는 ORM 프레임워크가 필요한가요?
* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects
가장 심플한 솔루션(P), 유지보수가 어렵다(C)
* Embedded in SQLJ clauses
Beter 구문 검사(P), 동적 쿼리 부족(C), JDBC보다 낮은 성능(C), 인기 없음(C)
* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)
(C) 또는 ORM(P)을 의미하는 경우에는 특정 케이스여야 합니다.
* External files (e.g. Properties or Resource files)
저장하기는 쉽지만(P), 오류 확인은 어렵다(C)
* Stored Procedures
높은 기밀성(P), 벤더 록인(lock-in) 문제를 일으키기 어려운 코드(C)
언급URL : https://stackoverflow.com/questions/1661921/java-programming-where-should-sql-statements-be-stored
'source' 카테고리의 다른 글
| Panda DataFrame을 사전으로 변환 (0) | 2023.01.08 |
|---|---|
| 요소 외부의 클릭을 감지하려면 어떻게 해야 합니까? (0) | 2023.01.08 |
| Java 인터페이스의 옵션 메서드 (0) | 2023.01.08 |
| Python 파일의 일반적인 헤더 형식은 무엇입니까? (0) | 2023.01.08 |
| MySQL 쿼리에서 UNION 및 LIMIT 작업 결합 (0) | 2023.01.08 |