Question

For the current app I am writing I have elected to place all database functionality into a single class, as it allows me to keep the database code away from the business logic and easily replace the database code if we ever have need to switch to another DBMS. However, recently my database class has become rather large (EDIT for info: approximately 53k), and I’m worried about the speed of parsing this file due to its volume, since it generally must be parsed for each request.

Typically only one, or maybe two, different “Types” of database calls are made (e.g., user system calls, asset system calls, map system calls, session system calls, etc) at any given time, so one option I was considering was breaking the tasks into a series of database object “slices” and then dynamically loading those at run time based on the functions requests.

On the other hand, I’m worried that doing this would either (a) lead to a large amount of parallel execution in memory (i.e., each slice now has a query method, an independent query log, etc) as well as forcing me to modify all the existing code to point to the new, smaller objects or (b) cause relative performance losses as I back-hack in this functionality to work with the code that’s already written (e.g., have each slice point back to the parent’s querying functions as well as the performance hit to be incurred by suddenly using __call all over the place instead of direct method access).

What is the more correct course of action in this scenario?

EDIT For More Info: The file is approximately 53kb with about 2,350 lines at present (and it is not done), although this may be considered skewed as I use an expanded SQL model for readability, e.g.

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

There are 70 querying functions, each one performing some unique task, with very little overlap (If I need two startlingly similar result sets I can simply ignore what I don’t need each time and reuse the same queries).

EDIT: Example function:

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

If you are worried about parsing time, and not code quality, you could use some compiler cache, such as APC.

However, if you have a big class, it’s likely that you should refactor it into smaller ones just for readability. If you can’t easily find what you need in the class (to modify it, for example), then it’s probably too big to maintain.
If you decide to refactor, remember that maintainability and code quality are far more important than execution speed (database I/O is slower than executing code anyway).