PHP : 하나의 거대한 데이터베이스 클래스 또는 여러 개의 작은 클래스?

Question

현재 응용 프로그램의 경우 데이터베이스 변수를 비즈니스 로직에서 멀리 유지하고 데이터베이스 코드를 쉽게 바꿀 수 있으므로 모든 데이터베이스 기능을 단일 클래스에 배치하기로 선택했습니다. 다른 DBMS. 그러나 최근에 내 데이터베이스 클래스는 상당히 커졌으며 (정보 편집 : 약 53k), 일반적으로 각 요청에 대해 구문 분석되어야하기 때문에 볼륨으로 인해이 파일을 구문 분석하는 속도가 걱정됩니다.

보통 한 번에 하나의 데이터베이스 호출 (예 : 사용자 시스템 호출, 자산 시스템 호출, 시스템 호출 시스템 호출, 세션 시스템 호출 등)이 한 가지 또는 두 가지 유형으로 이루어 지므로 하나의 옵션 필자는 작업을 일련의 데이터베이스 개체 "조각"으로 분해 한 다음 함수 요청을 기반으로 런타임에 동적으로로드하는 방법을 고려했습니다.

다른 한편으로 나는 이렇게하는 것이 (a) 메모리에서 많은 양의 병렬 실행 (즉, 각 슬라이스에 이제 쿼리 메서드, 독립 쿼리 로그 등이 있음) 기존의 모든 코드를 수정하여 새로운 작은 객체를 가리 키도록 강요하거나 (b) 이미 작성된 코드로 작업하기 위해이 기능을 백 해킹 (back-hack) 할 때 상대적인 성능 손실을 야기합니다 부모의 쿼리 함수뿐만 아니라 직접 메서드 액세스 대신 장소 전체에서 __call을 갑자기 사용하여 발생하는 실적 적중률)에 영향을줍니다.

이 시나리오에서 더 정확한 행동 방침은 무엇입니까?

EDIT 추가 정보 :이 파일은 읽기 쉽도록 확장 된 SQL 모델을 사용하므로 비뚤어진 것으로 간주 될 수 있지만 현재 약 2,350 줄의 파일이 약 53kb입니다 (아직 완료되지 않았습니다).

SELECT 
    foo, 
    bar, 
    baz 
FROM 
    someTable st 
    LEFT JOIN someOtherTable sot 
     ON st.id = sot.stId 
WHERE 
    cond > otherCond 

70 개 쿼리 기능, 나는이 개 놀랄만큼 비슷한 결과 세트가 필요한 경우 단순히 내가 각각의 시간이 필요하지 않는 것을 무시하고 같은 쿼리를 다시 사용할 수 있습니다 (약간의 중복과 함께, 몇 가지 독특한 작업을 수행하는 각각이 있습니다).

편집 : 예 기능 :

public function alarm_getActiveAlarmsByAsset($tier, $id) { 
    if ( !Redacted::checkNumber($tier, $id) 
     || $id < 0 
     || $tier > Redacted::ASSET_LOWEST_TIER 
     || $tier < Redacted::ASSET_TIER_CUSTOMER 
    ) { 
     return false; 
    } 

    $sql = " 
     SELECT 
      alarmId, 
      alarmTime, 
      server, 
      source, 
      reason, 
      train, 
      server_sites.siteId AS `siteId` 
     FROM 
      alarm_alarms 
    "; 

    $join = ''; 

    switch ($tier) { 
     case Redacted::ASSET_TIER_CUSTOMER: 
      $join = ' 
       LEFT JOIN red_campus 
        ON red_campus.campId = red_site.campId 
      '; 
     case Redacted::ASSET_TIER_CAMPUS: 
      $join = ' 
       LEFT JOIN red_site 
        ON red_site.siteId = server_sites.siteId 
      ' . $join; 
     case Redacted::ASSET_TIER_SITE: 
      $join = ' 
       LEFT JOIN server_sites 
        ON server_sites.servId = alarm_alarms.server 
      ' . $join; 
    } 
    $table = isset(self::$dbTierMap[$tier + 1]) ? self::$dbTierMap[$tier + 1]['table'] : 'server_sites'; 
    $field = isset(self::$dbTierMap[$tier + 1]) ? self::$dbTierMap[$tier + 1]['parent'] : 'site'; 
    $sql .= $join . " 
     WHERE 
       ackId IS NULL 
      AND {$table}.{$field}Id = {$id} 
    "; 

    $r = $this->query($sql); 

    if (!$r) { 
     return false; 
    } 

    $alarms = array(); 
    while ($alarm = mysql_fetch_assoc($r)) { 
     $alarms[] = $alarm; 
    } 
    return $alarms; 
} 

Answer 1

파싱 시간과 코드 품질에 대해 걱정이된다면 일부 컴파일러 캐시, 예 : APC .

큰 클래스가있는 경우 가독성을 위해 작은 클래스로 리팩토링해야 할 가능성이 높습니다. 수업에서 필요한 것을 쉽게 찾을 수 없다면 (예를 들어 그것을 수정하기 위해), 유지하기에는 너무 큰 것입니다.
리팩터링하기로 결정했다면 유지 관리 가능성과 코드 품질이 에서보다 훨씬 더 빠릅니다 (데이터베이스 I/O는 코드 실행보다 느립니다).

Answer 2

의 DB 방식을 알지 못하고 말할 수 있지만 항상 쉽게 여러 클래스 하나의 큰 것보다 (예를 들어 논리적 개체 당 하나 개의 클래스/DB 테이블)

을 유지하기 어렵다

데이터베이스 (및 모든 네트워크 요청)에 대한 요청이 항상 오래 걸리므로 구문 분석 시간에 대해 걱정할 필요가 없습니다.

Answer 3

일반적으로 많은 작은 클래스를 유지하는 것이 더 쉽습니다.(주로 PHP와 함께 사용) MySQL을위한 몇 가지 클래스 발전기를 사용할 수있다 :

sourceforge: php Class Generator - PCG

sourceforge: PHP Class Generator

은 아마 당신이 새로운 아이디어를 찾을 수 있습니다.

Answer 4

내가 아는 한, 데이터베이스 클래스는 기본적으로 가능한 전체 쿼리를 보유하고 있으며, 전체 응용 프로그램에서 만들어진 하드 코드 된 것입니까?

데이터베이스 계층 추상화를 달성하는 더 좋은 방법은 쿼리를 내부적으로 일관된 형식으로 추상화하고 모델과 데이터베이스 어댑터를 사용하여이를 실제 SQL로 변환하는 것입니다. 예 : 특정 테이블에

$customer = $Customer->find(array(
    'fields' => array('name', 'id'), 
    'condition' => array('ssn' => $ssn) 
)); 

고객 클래스 맵 및 다른 컬럼에 스키마 매핑 할 수 있습니다 필요한 경우 :

class Customer extends BaseModel { 
    public $table = 'xe_a3_cstmr'; 
    public $schema = array(
     'name' => 'ze_42_nm', 
     … 
    ); 
} 

BASEMODEL은 어떤 데이터베이스에 따라 실제 SQL에 이러한 추상화 된 쿼리를 설정하거나 해제 할 수

SELECT `xe_a3_cstmr`.`ze_42_nm`, `xe_a3_cstmr`.`…` FROM `xe_a3_cstmr` 
WHERE `xe_a3_cstmr`.`ssn` = 123235; 

데이터베이스 층은 앱에서 확인해야합니다 모든 새 쿼리 기하 급수적으로 증가하지 않습니다이 방법은, 여전히 maintaing하면서 유연성 : 그것은 이야기 할 필요가 쿼리를 다른 데이터베이스에 매핑합니다. 이를 ORM이라고합니다. 이것은 실제로 훨씬 더 쉬운 추상화를 제공한다는 것은 말할 것도 없습니다. 하드 코딩 된 모든 쿼리를 다시 작성해야하는 대신 다른 데이터베이스 어댑터 만 작성하면됩니다.

메모에 Mewp가 제안 했으므로 시작할 수있는 좋은 곳은 Doctrine입니다.