다른 데이터베이스는 SQL 지원 & 구현의 차이점이 있습니다. 때로는 SQL 구문에 차이가 있으며 때로는 일부 SQL 명령에 대한 지원이없는 경우가 있습니다. 때로는 데이터베이스에 다른 데이터베이스에는없는 기능이 있습니다.여러 데이터베이스에 대한 SQL 작성에 대한 팁
개발자가 CakePHP, Codeigniter, Zend 등의 프레임 워크를 사용한다는 점을 감안하여 다른 데이터베이스 (MySQL, PostgreSQL, Oracle, MSSQL, SQLite)에 적합한 SQL 쿼리를 작성하는 좋은 사례로 간주됩니다.)는 데이터베이스 추상화 계층을 제공합니까? 개발자가 피해야하는 SQL 구문은 무엇입니까?
그런 다음 ORM을 사용하면 복잡한 쿼리에서 성능이 저하된다는 것을 알 수 있습니다. 성능이 좋은 SQL을 작성하는 것만으로는 충분하지 않습니다. DB 추상화 계층이 더 좋을 것으로 기대하지는 않습니다. 대부분의 ORM은 원시 저장 프로 시저를 지원합니다 ... ORM 사용 목적을 무효화합니다.
ANSI SQL은 데이터베이스간에 SQL을 더 이식성있게 만들기 위해 노력하고 있지만 채택은 공급 업체마다 다릅니다. 그리고 ANSI 구문은 고유 한 구문 (IE : COALESCE 대 네이티브 ISNULL/IFNULL/NVL/등)뿐만 아니라 성능을 반드시 의미하는 것은 아닙니다.
실제로는 최상의 성능을 발휘하는 데이터베이스 상호 작용을 얻으려면 관련된 각 공급 업체에 대해 사용자 지정 코드를 작성해야합니다. 일부는 이것을 중앙 응용 프로그램을 유지하기가 더 쉽기 때문에 데이터베이스가 기본 지속성 이상의 것이어야하는 이유를 설명하기도합니다. 그러나 응용 프로그램과 데이터베이스 간의 여러 번의 이동, 데이터 유형 지정 및 테이블 디자인의 어려움으로 인해 어려움을 겪는 사용량이 많은 응용 프로그램을 처리 할 때이 문제는 해결되지 않습니다. 솔직히 말해서 데이터베이스 낭비입니다 ...
전적으로 동의합니다. 추상화 계층은 모든 DBMS에서 응용 프로그램이 동등하게 느리게 실행되도록 보장합니다. –
당신은 Object-relational mapping (ORM)을 찾고 있습니다. 컴퓨터 소프트웨어 에서
객체 관계 매핑 (ORM, O는/RM, 및 O/R 매핑) 객체 지향 프로그래밍 언어에서 호환되지 않는 형 시스템 간의 변환 데이터의 프로그래밍 기법이다. 이는 실질적으로 을 생성하고 프로그래밍 언어 내에서 사용할 수있는 "가상 객체 데이터베이스" 을 생성합니다.
유명 전화 번호는 Doctrine입니다. 그냥 수행 quantumSoup는 언급으로
나는 그 프레임 워크에서 ORM이 구현되었다고 생각했다. – bancer
음, 그렇습니다. 그러나 그들은 대부분 별도의 패키지로 남아 있습니다. –
: 또한 살펴 있습니다. 나열된 각 프레임 워크를 살펴보면 데이터를 삽입/추출하기 위해 ORM 또는 일부 종류의 데이터베이스 추상화 계층을 사용함을 알 수 있습니다. 이를 통해 원하는 데이터 소스와 관계없이 작동하는 db 중립적 인 코드를 작성할 수 있습니다. 그런 다음 ORM은 올바른 데이터 소스 인 "드라이버"를 사용하여 의도를 각 데이터 소스가 이해하는 명령으로 변환합니다.
그래서 트릭은 1) ORM 또는 데이터베이스 추상화 계층을위한 범용 인터페이스를 정의합니다. 그런 다음 ORM에 적절한 드라이버를 작성하십시오. 그런 다음 새로운 유형의 데이터 소스 (플랫 파일 또는 CSV 포함)를 사용할 때마다 새로운 드라이버를 추가하는 것이 간단합니다.
때로는 현재 사용중인 데이터베이스에서 지원하지 않는 구문으로 쿼리를 만들 수 있습니다. F.ex. MySQL의 FULL JOIN. 나는 DB 추상화 레이어를 통과 한 쿼리를 만들 수 있었고 괜찮은 느낌이었다. 그러나 현재 데이터베이스는 해당 구문을 지원하지 않습니다. – bancer
"조심스럽게 ANSI SQL을 사용하십시오"는 질문에 대한 가장 직접적인 대답입니다.
그러나, 특히, 제레미 자 워드 니에서 마음 these words 유지 :
좋은 엔지니어가 자신의 도구 고유의 가장 강력한 장점 을 위해 작업에 가장 적합한 도구를 선택하고 그들이 할 수있는 모든 일을하려고 풍모. 데이터베이스 세계에서 이는 특정 힌트, 즉 인덱싱, 데이터 유형 및 심지어 테이블 구조 결정을 의미합니다. 모든 주요 RDBMS에 공통적 인 기능의 하위 집합으로 자신을 제한한다면 자신과 고객 모두에게 큰 불만을 품고있는 것입니다.
사람들이 실제로 바라는 것은 프로그래밍 언어 데이터 구조 (예 : Ruby 객체)로 쉽게 변형 될 수있는 비 관계형 데이터 저장소입니다. 이 기능이 필요한 경우, 많은 "NoSQL"옵션 중 하나를 검토해보십시오 (MongoDB, CouchDB는보다 성숙한 두 가지 옵션 중 하나입니다).
실제로는 특정 DBMS를 선택한 다음 마음에 드는 독점적 기능을 자유롭게 사용하는 것이 좋습니다. 물론 DBMS 선택을 통제 할 수없는 사람들 (또는 시장을 제한하고 싶지 않은 사람들)에게 팔려는 패키지를 작성하려는 경우처럼 항상 가능한 것은 아닙니다. – Jay
그게 바로 ORM 때문입니다. – quantumSoup
때때로 ORM이 쿼리를 올바르게 처리하지 못합니다. F.ex. MySQL의'FULL JOIN', SQLite의'RIGHT JOIN'. 나는 쿼리의 구문이 좋지만 데이터베이스가 그것을 지원하지 않는다는 것을 의미한다. – bancer