인터넷에서 찾은 설명은 데이터베이스 전환을 용이하게 하고 SQL 작성을 피하라는 것입니다. 이 두 가지 항목이 잘 이해가 되지 않습니다.
첫 번째는 데이터베이스를 전환하는 것이 MySQL에서 SQL Server로 전환하는 것과 비슷하지만 테이블 구조가 동일하다면 기본 SQL을 변경할 필요가 없다는 것입니다. 및 쿼리 생성자.
둘째, 긴 SQL 작성을 피하세요. 쿼리 생성자도 이 작업을 수행할 수 있습니다.
쿼리 생성자와 ORM의 차이점은 쿼리 생성자는 SQL을 생성하는 클래스이고 ORM은 테이블에 매핑되는 클래스이며 필드는 멤버 변수에 매핑된다는 것입니다. 또 다른 질문이 있습니다. 테이블과 필드가 많으면 ORM 클래스가 너무 장황해지지 않을까요? 제가 이해하고 있는 부분이 잘못된 부분을 바로잡아주세요.
$user = DB::table('users')->where('name','Laravel')->first();//laravel 쿼리 생성자
$posts = Post::where('id','<',3)->orderBy('id','desc')->take(1)->get();//laravel orm
맞습니다. 테이블이 많고 필드가 많으면 ORM 클래스가 매우 장황해집니다.
ORM의 본질은 데이터베이스 테이블과 테이블 간의 관계를 개체 및 개체 관계로 매핑하는 것입니다. 이 매핑 관계는 양방향이지만 개체->RDB 방향에는 몇 가지 문제가 있다는 점에 유의해야 합니다. 왜냐하면 RDB의 엔터티 설명은 Object의 엔터티 설명만큼 풍부하지 않기 때문입니다.
당신이 언급한 두 가지 이유에 대한 설명:
데이터베이스 전환이 편리하다는 점은 개인적으로 ORM이 이런 기능을 제공하긴 하지만 실제 프로젝트에서 데이터베이스를 전환하는 경우가 드물기 때문에 흔하지 않다고 생각합니다.
SQL 작성을 피하는 것이 ORM을 사용하는 중요한 이유입니다. 프로그래머가 게으르고 SQL을 배우고 싶어하지 않기 때문입니다(SQL은 배우기 쉽지만). 이는 ORM이 원래 만들어진 중요한 이유이기도 합니다.
간단히 말하면 ORM은 Object Relational Mapping의 약자로 Object는 Object, Relational은 Relation, Mapping은 Mapping입니다. 객체 관계형 매핑은 상당히 추상적인 것처럼 보이며, 그렇습니다. 추상적인 개념입니다. 프로그래밍 구문의 관점에서 보면 비즈니스 개체를 구체적으로 운영할 때 더 이상 복잡한 SQL 문을 처리할 필요가 없고 개체의 속성과 메서드만 조작하면 됩니다.
그럼 두 가지 질문에 답해주세요
먼저, mysql과 sqlserver 사이에는 많은 차이점이 있습니다. 프로그램에서 사용하는 mysql_로 시작하는 함수는 sqlserver에서 인식되지 않습니다. 그렇다면 코드를 변경하지 않고 어떻게 마이그레이션합니까?
둘째, ORM에는 테이블과 클래스 간의 매핑뿐만 아니라 다음과 같은 매핑 관계도 포함되어 있습니다.
데이터베이스의 클래스 및 테이블 매핑: 데이터베이스의 각 테이블은 프로그래밍 언어의 클래스에 해당합니다
테이블의 개체 및 레코드 매핑: 관계형 데이터베이스의 테이블에는 여러 레코드가 있을 수 있으며 각 레코드는 클래스의 인스턴스에 해당합니다
클래스 속성과 데이터베이스 테이블 필드 간의 매핑: 데이터베이스 테이블 필드의 데이터 유형과 클래스 속성 유형도 일대일로 대응됩니다