ORM에서 데이터베이스 추상화를 사용하면 어떤 이점이 있습니까? [닫은]

선택한 프레임 워크에서 권장하는 ORM을 사용하기 시작했으며 ORM이 제공하는 추가 추상화 계층에 대한 아이디어가 마음에 들지만 이것이 실제로 의미하는 것을 깨닫기 시작했습니다. 그것은 더 이상 내 데이터베이스 (mysql)로 작업하지 않고 mysql 관련 기능이 존재하지 않는 것처럼 창 밖으로 사라진다는 것을 의미합니다.

ORM의 아이디어는 모든 것을 데이터베이스에 무관하게 만들어서 나를 돕기 위해 노력하고 있다는 것입니다. 이것은 훌륭하게 들리지만 종종 특정 데이터베이스 시스템을 선택하는 이유가 있습니다. 그러나 데이터베이스에 독립적 인 경로를 사용함으로써 ORM은 가장 작은 공통 분모를 사용하므로 가장 작은 기능 세트 (모든 데이터베이스에서 지원되는 기능)로 끝납니다.

장기적으로 기본 데이터베이스를 전환하지 않을 것임을 알고 있다면 어떻게합니까? 데이터베이스 별 기능에도 액세스하지 않겠습니까?

나는 같은 방식으로 본다. 필요할 때 그 아래에 들어갈 수없는 추상화는 악의적입니다. 코드에서 모든 종류의 추악한 추상화 반전으로 이어지기 때문입니다.

직장에서 우리는 상당히 잘 작동하는 자체 개발 ORM을 가지고 있지만 기능이 명시 적으로 제공하지 않는 것이 필요할 때 문자열을 가져 와서 생성하는 쿼리에 직접 드롭하는 메소드가 있습니다. 필요할 때 원시 SQL을 사용합니다.

IMO이 기능이없는 ORM은 컴파일 된 비트의 가치가 없습니다.

ORM은 가장 작은 공통 분모를 취합니다.

나는 당신의 진술에 동의하지 않아야합니다. 내가 걸릴 것 nHibernate 수를 예로서. 이 프레임 워크는 대부분의 ORM과 마찬가지로 버전 (및 지원되는 기능)에 관계없이 가장 인기있는 데이터베이스를 포함하여 많은 데이터베이스를 지원합니다.

빠른 참고 사항 : 데이터베이스 추상화 만 언급합니다. 그것은 많은 이점 중 하나이지만, 객체 지향 기능이 더 강력하다고 생각합니다 (예 : 상속). 그리고 You design your domain model first...

... 추상화로 돌아갑니다. 가장 작은 공통 분모가 아닙니다. 에서 nHibernate 수 , 당신은 방언이있다. 동일한 코드를 사용하여 다른 데이터베이스를 쿼리 할 수 ​​있습니다. 방언은 기능 관리를 담당합니다. 올바른 진술은입니다 a given dialect will try to use all the power of a given database system.

예를 들어, SqlServer2005도입 될 때 새로운 SQL Server 2005 페이징 기능을 활용 하는 방언을 사용하십시오. 방언 대신 방언을 사용하면 SqlServer2000연주가 향상됩니다.

물론 예외도 있지만, nHibernate를 사용하여 수년 동안 단 한 건도 발생하지 않았으며 내 응용 프로그램은 데이터 중심적입니다.

아이디어는 깔끔하지만 ORM 도구를 사용하는 시점으로 이동 한 적이 없습니다. SQL을 직접 작성하거나 사용 된 스토리지를 처리하는 것은 문제가되지 않았습니다. 그러나 더 긴 제품 수명으로 더 적은 수의 프로젝트를 수행 할 수있는 고급 스러움을 느끼기 때문에 수작업으로 코딩 한 SQL 및 DB 조작이 완료되면 그 자리에있게됩니다. 또한 프로세스를 ORM 도구의 사고 방식에 맞추지 않고도 필요한 직접 SQL 쿼리를 처리 할 수 ​​있습니다.

따라서 질문을하기 전에 질문이 있어야한다고 생각합니다.

당신이 있습니까 실제로 그들을 사용하여 아무것도 얻는? 즉, ORM 도구를 구현하여 사용 가치를 높이고 시스템에 추가 복잡성을 추가하여 충분한 노력을 아끼지 않습니까? (이는 여분의 '조각'이 잠재적 인 지원 문제를위한 추가 벡터가되는 상용 앱의 경우 특히 그렇습니다)

그러면 추가 추상화 계층이 앱에 부정적인 영향을 미칩니 까? 수작업으로 코딩 한 SQL 등보다 느리게 진행됩니까?

O / RM은 정기적으로 비난을 받았습니다. Ted Neward 는 몇 년 전 " 베트남 컴퓨터 과학의 베트남 "이라고 불렀습니다 . O / RM

잘 시작하고, 시간이 지남에 따라 더 복잡해지며, 분명한 경계 지점, 명확한 승리 조건 및 명확한 출구 전략이없는 약속으로 사용자를 오래 붙잡기 전에.

자신 만의 임시 매핑을 작성하지 않는 한 (많은 경우에 이미 언급했듯이 좋은 솔루션 임) 비 관계형 데이터베이스 사용과 같은 대안을 살펴볼 수 있습니다. 어떤 사람들은 진정한 객체 데이터베이스가 더 좋다고 말하는데,이 맥락에서 언급 된 다른 용어는 LINQ, Ruby 및 Tutorial D입니다. 진정한 관계형 데이터베이스와 달리 진정한 객체 데이터베이스가 있다고 가정합니다. 그러나 실제로 개념 데이터 모델링 (즉, 데이터를 저장하려는 실제 객체와 이러한 객체가 서로 관련되는 방식)이 개념 모델을 표현하는 방법을 찾는 것이 더 중요하다는 것을 알았습니다. 프로그래밍 또는 데이터베이스 언어.

대안은 무엇입니까?

이것은 흥미로운 개념입니다. 기본 데이터베이스의 기능을 추상화하여 특정 데이터베이스 구현의 일부 기능을 확실히 잃어 버립니다. (특정 데이터베이스 기능에 의존해야하는지 여부는 또 다른 논증입니다.)이 기능은 특정 기능에 액세스 할 수있는 데이터베이스 별 ORM을 통해 해결할 수 있지만 가치가 있고 문제가되는 단계보다 더 문제가 될 수 있습니다. 잘못된 방향.

하루가 끝나면 스스로에게 물어보십시오- 대안은 무엇입니까?

ORM 사용을 중단하고 모든 데이터베이스 액세스를 직접 작성해야합니까? 물론 ORM을 통해 일부 데이터베이스 기능에 액세스 할 수 없지만 구식 기술을 사용하여 항상 데이터베이스 기능에 액세스 할 수 있습니다. 결국 생산성이 얻는 이익은 단점보다 훨씬 중요합니다.

ORM은 기본적으로 " 저장되지 않은 프로 시저 "입니다. 거기서 나는 용어를 만들었다.

ORM이 수행하는 모든 작업을 뷰, 트리거 및 저장 프로 시저로 복제 할 수 있습니다. 원시 SQL을 추상화하고 표준화 된 데이터베이스의 일관성을 유지할 수 있습니다. 그러나 간단한 경우에만 잘 작동합니다. 처리 할 데이터가 너무 많으면 성능이 저하 될 수 있습니다. (PHP의 ORM은 종종 SQL 빌더 체인이 모든 것을 추상화 할 수 없기 때문에 데이터 스크립트 측을 사용합니다.)

그러나 평소와 같이 모두 응용 프로그램과 작업에 달려 있습니다.

ORM을 사용하는 데 어려움을 겪는 것 중 하나는 많은 팬들이 더 이상 SQL 및 RDB 이론을 알 필요가 없다고 주장하는 경향이 있다는 것입니다. 결과는 웃기거나 완전히 치명적입니다. ORM이 ORM 을 올바르게 사용하고 구성하기 위해서는 SQL 및 RDB 이론을 잘 알고 있어야 한다는 말이 ORM의 제조 및 전문가들의 수백만 번에도 불구 하고 있습니다.

사람들이 많은 용도로 사용되는 도구를 사용하지만 모든 문맥이 마술처럼 보편적으로 적용 가능한 은색 총알에있는 것은 아닙니다.

작년에 자주 변경되는 사내 앱에서 작업했으며 ORM을 사용하여 매우 기뻤습니다. 이 앱은 변경 관리 팀을위한 지원 앱이었으며, 대규모 프로젝트가 발전함에 따라 우리의 작은 앱은 존재하지 않았고 몇 달 전에 예측할 수 없었던 상황에 대한 새로운 요구 사항을 얻었습니다.

ORM ( PHP의 Propel) 덕분에 코드에 대한 일부 논리를 분할하여 하나의 함수가 쿼리의 "기록이 유효합니다"부분을 추가하고 다른 부분은 보안 부분을 추가했습니다 ( "사용자의 경우에만 이러한 레코드 표시" 기본 구조가 변경된 경우 ( "레코드 유효성"에 대해 고려해야하는 추가 필드) 20 개의 SQL 절이 아닌 하나의 함수 만 변경하면됩니다.

우리는 모든 SQL 절이 별도의 XML 파일에 저장되어 "데이터베이스 변경을 쉽게 처리 할 수있는"상황에서 왔습니다. 그들이 아니라고 믿습니다. 한 부분이 너무 끔찍해서 매일 Daily WTF에 제출해야했습니다 .

쿼리가 Propel Criteria로 표현하기에 너무 복잡하거나 공급 업체별 기능 (주로 MySQL을 사용했기 때문에 전체 텍스트 검색)이 필요한 경우에는 Propel에 아무런 문제가 없었습니다. 사용자 지정 기준을 추가 하거나 실제로 필요할 때 원시 SQL을 사용했습니다 ( 이제 실제 Propel 객체와 더욱 쉽게 결합 할 수 있음 ). 공급 업체별 애드온을 생성 된 클래스에 쉽게 추가 할 수 있으므로 앱 코드에 SQL은 없지만 데이터베이스 엔진의 모든 기능을 갖춘 두 가지 이점을 모두 누릴 수 있습니다.

그러나 요점은 데이터베이스에서 멀리 떨어져 프로그래밍해야한다는 것입니다. 즉, 데이터베이스에 있다고 생각할 필요가 없습니다.

나는 C #에서 일하고 LINQ를 많이 사용하므로 많은 유창한 방법을 사용합니다. 개체 수준을 저장하거나 찾거나 프로그램 수준에서 저장하는 방법, 비즈니스 계층 수준에서는 거의 고려할 필요가 없습니다.

특정 데이터베이스 자체에서 제공하는 메소드가 DB 커넥터에서 사용되는 경우가 많으므로 해당 내용을 알 필요없이 최적화를 수행 할 수 있습니다.

여전히 DB 쪽에서 함수를 작성할 수 있습니다. 종종 당신은 그들을 통해 매핑 할 수 있습니다.

무엇보다도 이러한 분리는 테스트 가능성을 허용하고 더 나은 구조화 된 코드를 작성하도록 강요합니다.

ORM 을 사용하면 데이터베이스 별 기능에 액세스 할 수 있으며 사용중인 ORM 및 제공하는 기능에 따라 다릅니다.

예를 들어, 현재 작업중 인 프로젝트에서 Java Persistence API와 Hibernate를 사용하고 있습니다. 그럼에도 우리는 soundex를 사용하여 테이블을 검색하는 것과 같은 몇 가지 데이터베이스 특정 기능을 사용합니다.

저에게 ORM 사용의 주요 이점은 반드시 응용 프로그램 데이터베이스를 무의식적으로 만드는 것이 아니라고 생각하지만 (사실 좋은 것도 있지만) 대부분의 경우 물건을 저장하는 방법에 대해 생각할 필요가 없습니다. 검색했습니다.

하나 어떤 시점에서는 응용 프로그램의 요구 사항에 따라 어쨌든이에 대해 생각해야 할 가능성이 큽니다. ORM은 마법이 아닙니다.

나는 선택하고 쉽게 삽입 할 수 있도록 내 자신을 썼다.

Evey db 고유의 것이 가능합니다. 라이브러리가 도와주는 쿼리를 직접 작성하면됩니다 (매개 변수 이름을 지정하고 .Add를 사용하는 대신 '?'와 params를 사용할 수 있습니다)

내 반쪽이 반쯤 빠는 것 같아 ORM 세계에서 도움을 받고 쿼리 세계에서 중요한 부분을 수행합니다.

인라인 또는 저장된 procs를 삽입 및 선택, 업데이트하고 DAL을 통해 다시 매핑하는 코드를 작성하는 것이 예외적 인 경우에만 일반적으로 유리합니다. 사용 가능한 ORM, 지원 데이터베이스 및 언어는 왜 ORM을 사용하지 않는지 묻는 질문입니까?

그것들은 표준화되었거나 보편적이며 명시 적이거나 일반적입니다. 더욱 빠르고 쉽게 구현할 수 있습니다. 아음속, linq-to-sql 및 엔터티 프레임 워크를 사용했습니다. 이를 통해 개발자는 데이터베이스 매핑 대신 논리 및 비즈니스 규칙에 집중할 수 있습니다.

내 (간단한) 2 센트 :

1 : ORMS가 있고 ORMS가 있습니다. 일부 ORMS는 Active Record를 기반으로하고 일부는 Data Mapper를 기반으로합니다. 그 자체는 관련 고려 사항이지만 그 의미를 이해하려면 약간의 조사가 필요합니다. 일반적으로-PHP에 대한 나의 경험은 ORMS가 전자를 지원하고 후자는 거의 지원하지 않는다는 것입니다. 활성 레코드 기반 ORM은 두 가지 효과 중 하나 인 것 같습니다. 데이터베이스를 비정규 화하거나 객체 상호 작용을 지원하기 위해 많은 클래스를 호출합니다.

2 : ORM의 장점은 실행해야하는 쿼리의 복잡성과 직접적인 상관 관계가 줄어 듭니다. 사용자-> 게시물과 같은 멋진 간단한 관계가 있으면 매우 잘 작동 할 수 있습니다. 이것이 대부분의 ORM / 프레임 워크가 이와 같은 예제를 사용하는 이유입니다. 그러나 복잡한 쿼리를 실행해야하는 경우 생성해야하는 ORMQL의 양은 일반 SQL 쿼리의 문자열 길이와 비슷하지만 쿼리를 실행하는 개체 그래프로 인해 성능이 떨어집니다. 추출. 간단히 말해, ORM은 데이터베이스 작업의 처음 30-50 %에는 훌륭하지만 마지막에는 끔찍합니다. 이것이 AR이 널리 보급 된 또 다른 이유라고 생각합니다.

3 : 왜 데이터베이스에서 숨겨야합니까? 자바 스크립트를 추상화하기 위해 서버 측 언어를 사용 하시겠습니까?

개인적으로 나는 그 접근법을 혼합합니다.

• 기본적으로 ORM을 사용하여 "사용자"로드
• 미리 구운 여러 SQL 쿼리가 포함 된 DAO를 사용하십시오 (예 : selectLike, selectWhere).
• 보다 구체적이지만 재사용 가능한 사용자 지정 쿼리를 추가해야하는 경우 DAO 확장
• DAO를 통해 간단한 데이터베이스 액세스를 제공하십시오 (예 : $ data = Dao-> query (sql 문자열)).

모든 것을 말했듯이 Doctrine 2가 곧 나올 것입니다.

SQL 기능을 사용하려면 myBatis와 같은 SQL 매퍼 프레임 워크를 사용할 수 있습니다.