데이터 영역에서 SQL 문을 관리하는 방법

PHP 프로젝트에서 우리는 이미 비즈니스 로직과 데이터베이스 액세스를 분리했습니다. 모든 데이터베이스 작업은 데이터베이스 및 주제별로 그룹화 된 서로 다른 데이터베이스 클래스에 캡슐화됩니다. Theses classes are very horrible, 소스의 절반은 params로 채워지는 SQL 문자열입니다. 우리는 SQL을 리소스 파일이나 다른 것과 같은 "다른"위치에 두는 것을 고려했습니다. 무엇이 가장 좋은 연습으로 간주되며 PHP를 지원하는 도구/라이브러리를 알고 있습니까?데이터 영역에서 SQL 문을 관리하는 방법

친절 감사

스테판

출처

2009-03-30 DaSteph

가능한 경우 저장 프로 시저를 사용해야합니다. 그렇게하면 성능, 보안 및 코드 유지 관리가 향상됩니다. 이것이 첫 번째 접근 방법입니다.

SP 쿼리를 DAL에서 분리하려는 경우 데이터베이스에 저장하지 않는 이유는 무엇입니까? 다른 쿼리를 추출하려면 쿼리가 필요하므로 추상화를 위해 SQL 쿼리를 데이터베이스에 저장하는 것이 이상하게 보일 수 있습니다. 이것은 실제로 매우 일반적인 접근 방식으로, 특정 조건과 일치하는 쿼리를 선택할 수 있으며 (필요할 경우) 쿼리를 동적으로 구축 할 수 있습니다.

또 다른 방법은 쿼리가 동적으로 작성되는 쿼리 클래스를 만드는 것입니다.

class FruitQuery { 
    ... 
    public function addTypeCriteria($type) { 
     $this->internalSQLCriterias[] = "fruit=:type"; 
     $this->internalSQLParameters[] = array(':type', $type); 
    } 
    ... 
    public function create() { 
     $this->internalSQLQuery = "SELECT ... FROM Fruits"; 

     if (sizeof($this->internalSQLCriterias) > 0) { 
      $this->internalSQLQuery .= " WHERE "; 
      $moreThanOne = ''; 

      foreach ($this->internalSQLCriterias as $criteria) { 
       $this->internalSQLQuery .= $moreThanOne . $criteria; 
       $moreThanOne = " AND "; 
      } 
     } 
    } 
    ... 
    public function execute() { 
     /* Bind the parameters to the internalSQLQuery, execute and return results (if any) */ 
    } 
...

이 클래스는 절대적으로 어떤 방법으로 완료되지 않으며, 당신은 그것의 구조를 재고 할 수 있습니다 -하지만 당신은 아마 내가 만들려고 점을 얻는다. :) 물론 보안 위반을 피하기 위해 쿼리 빌더에 대한 입력을 필터링해야합니다!

출처

2009-03-30 11:42:01

저장된 procs와 views를 저장하려고합니다. 또한 엄격한 작업 집합을 수행하여 잠재적 인 보안 문제를 상당 부분 해결할 수 있습니다. –

글쎄, 당신은 항상 다른 데이터베이스에 일관된 API에 대한 PDO을 사용하고 portable SQL statements을 작성할 수 있습니다.

또 다른 옵션은 Zend_DB과 같은 데이터베이스 추상화 계층을 사용하는 것입니다.

출처

2009-03-30 09:58:32 Andy

우리는 이미 PDO를 사용합니다. 내가 놓친 부분은 프로젝트에서 SQL 문을 저장하는 가장 좋은 장소입니다. 현재는 데이터베이스 클래스의 함수에 정의 된 문자열입니다. – DaSteph

데이터베이스 액세스 계층에 SQL이 거의 없어야합니다. 실제로 통신하고있는 실제 SQL과 관계없이 데이터베이스와의 통신을 추상화해야하기 때문입니다.

현재 유명한 MVC 패턴에서 비즈니스 로직 은 일반적으로 모델 레이어를 구성하는 SQL을 포함하는입니다.

이러한 "종교적인"정의를 제쳐두고, 당신이 지금 보통으로하는 것은 SQL 더미로 끝나는 것입니다. SQL은 어딘가에 존재해야합니다.

를 SQL 눈에 띄는 반복이 있다면, 나는 모든 일반적인 숨길 빠른 리팩토링 반복 던질 것 : 우선 순위와 여기에 성능 요구 사항에 따라 내가 (성능 타협에 의해 명령) 할 것 인 것이다 메소드 내부의 SQL. 메서드는 반드시 실행하지 않아도되지만 빌드하면됩니다. 그것은 모두 응용 프로그램에 따라 다르며 SQL이 복잡한 방식입니다. 데이터베이스와 실제 통신을 수행하는 하위 레이어가 없다면 리팩토링의 일부가 추가 될 수 있습니다.
쿼리 빌더를 고려해 보겠습니다. 성능과 유연성 사이에 아주 좋은 균형이 있습니다. 쿼리 작성기는 ORM 또는 데이터베이스 액세스 레이어 (Zend_Db 및 하위 구성 요소와 같은), Propel 및/또는 Doctrine의 일부로 만 찾을 수 있습니다. 따라서 전체 계층을 사용하지 않고도 쿼리 빌더 중 하나를 프로젝트에 이식 할 수 있습니다 (실제로 모든 것이 PDO 기반이므로 어렵지 않습니다).이것은 현저한 성능 문제를 추가해서는 안됩니다.
나는 교리의 ORM을 고려할 것입니다. 성능에 상당한 영향을 미칩니다. 그러나 당신은 매우 maintainable 코드로 끝날 것입니다.

마지막으로 나는 SQL을 리소스 또는 이와 유사한 것으로 간주하지 않습니다.

출처

2009-03-30 14:04:14

PHP는 잘 모르지만 다른 언어로 된 경험으로 볼 때이 정도는 말할 수 있습니다. 데이터 액세스 레이어는 architecture astronauts의 주요 대상입니다. 그들 중 누구도 최고가 아닌 매우 많은 "모범 사례"가 있습니다. DAL을 디자인 할 때, 너무 추상적 인 함정에 빠지기 쉽습니다. 네가 필요로하는만큼 멀리 가라.

성능상의 이유로 스파게티 코드를 피하고 데이터베이스의 인증을 단순화하기 위해 거의 항상 저장 프로 시저를 사용합니다. 저장된 procs의 성능 향상은 데이터베이스 엔진이 데이터베이스를 준비하는시기와 방법의 복잡성으로 인해 어려워 질 수 있습니다. 반면에 많은 입력이있는 검색 화면 에서처럼 매우 유연한 데이터베이스 작업을 코딩해야하는 경우 SQL에 코드를 넣을 때가 있습니다. 때때로 그것은 당신이 그것을 어디에 두든 읽을 수없는 혼란이 될 것입니다. 어딘가에서 일해야합니다.

SQL과 프로 시저 코드를 (불필요하게) 섞어 놓지 않으면 SQL을 응용 프로그램의 범위와 스케일에 가장 적합한 위치에 놓습니다. 죄송합니다 나는 PHP에 대한 도구 및 libs에 대한 귀하의 질문에 대답 할 수 없지만, 이것이 도움이되기를 바랍니다.

출처

2009-03-31 16:52:04

데이터 영역에서 SQL 문을 관리하는 방법

답변

관련 문제