PHP：一个巨大的数据库类还是几个较小的类？

Question

对于我正在编写的当前应用程序，我选择将所有数据库功能放在一个类中，因为它允许我将数据库代码远离业务逻辑，并在需要切换时轻松替换数据库代码到另一个 DBMS。但是，最近我的数据库类变得相当大（信息编辑：大约 53k），由于它的体积，我担心解析这个文件的速度，因为它通常必须针对每个请求进行解析。

通常在任何给定时间只进行一种或两种不同“类型”的数据库调用（例如，用户系统调用、资产系统调用、地图系统调用、会话系统调用等），所以一个选项 I正在考虑将任务分解为一系列数据库对象“切片”，然后根据函数请求在运行时动态加载这些对象。

另一方面，我担心这样做会（a）导致内存中的大量并行执行（即每个切片现在都有一个查询方法、一个独立的查询日志等）以及强迫我修改所有现有代码以指向新的、更小的对象或（b）导致相对性能损失，因为我在此功能中反向破解以使用已编写的代码（例如，让每个切片指向父的查询功能以及突然在整个地方使用 __call 而不是直接方法访问所招致的性能损失）。

在这种情况下，更正确的做法是什么？

编辑了解更多信息：该文件大约 53kb，目前大约有 2,350 行（尚未完成），尽管这可能被认为是有偏差的，因为我使用扩展的 SQL 模型来提高可读性，例如

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

据我了解，您的数据库类基本上包含在整个应用程序中进行的所有可能的查询（硬编码）？

实现数据库层抽象的更好方法是将查询抽象为内部一致的格式，并使用模型和数据库适配器将这些转换为实际的 SQL。例如：

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

Customer 类映射到特定的表，如果需要，可以将架构映射到不同的列：

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;

这样，您的数据库层不会随着您需要在应用中进行的每个新查询而呈指数级增长，同时仍保持将查询映射到不同数据库的灵活性。这被称为ORM。更不用说这实际上提供了更容易的抽象。您无需重写每个硬编码查询，只需编写不同的数据库适配器。

正如 Mewp 在 cmets 中建议的那样，Doctrine 是一个不错的起点。

Answer 2

通常维护许多小类更容易。对于 MySQL（主要与 PHP 一起使用），有几个可用的类生成器：

sourceforge: PHP Class Generator

sourceforge: php Class Generator - PCG

也许你可以在那里找到新的想法。

Answer 3

如果您担心解析时间而不是代码质量，您可以使用一些编译器缓存，例如APC。

但是，如果您有一个大类，您可能应该将其重构为更小的类，以提高可读性。如果您无法在类中轻松找到所需的内容（例如修改它），那么它可能太大而无法维护。
如果您决定重构，请记住可维护性和代码质量远比执行速度重要（无论如何，数据库 I/O 比执行代码慢）。

Answer 4

如果不知道数据库方案就很难分辨，但维护多个类总是比维护一个大类更容易（例如，每个逻辑实体/数据库表一个类）

您不必担心解析时间，因为对数据库的请求（以及任何网络请求）总是需要更长的时间