Das logische Modell der Datenbank für die Anwendung sollte vollständig sein, bevor die Leistungsvergleichstests durchgeführt werden. Tabellen, Sichten und Indizes müssen definiert und mit Informationen gefüllt sein. Die Tabellen sollten normalisiert und mit realistischen Daten gefüllt sein, und die Anwendungspakete sollten gebunden sein.
Das endgültige physische Modell der Datenbank sollte bereits feststehen. Die Objekte des Datenbankmanagers sollten sich an ihren endgültigen Speicherpositionen befinden, die Protokolldateien sollten in bezug auf ihre Größe festgelegt, die Positionen der Arbeitsdateien und Sicherungskopien bestimmt, sowie die Sicherungsprozeduren gestestet sein. Darüber hinaus sollten die Pakete überprüft worden sein, um sicherzustellen, daß Leistungsoptionen wie Zeilenblockung aktiviert werden, wenn dies möglich ist.
Sie sollten einen Stand der Programmier- und Testphasen für die Anwendung erreicht haben, der es Ihnen ermöglicht, die Vergleichstestprogramme zu erstellen (siehe nächsten Abschnitt). Während der Vergleichstests können die praktischen Grenzen einer Anwendungen zutage treten. Jedoch ist das Ziel der Vergleichstests, die hier beschrieben werden, die Messung der Leistung und nicht die Feststellung von Fehlern oder abnormalen Beendigungsbedingungen.
Das Vergleichstestprogramm muß in einer möglichst wirklichkeitsnahen Nachbildung der tatsächlichen Umgebung ausgeführt werden. Im Idealfall sollte ein Server des gleichen Modells mit derselben Speicher- und Festplattenkonfiguration verwendet werden. Dies ist besonders dann von Bedeutung, wenn die Anwendung letztendlich eine große Anzahl von Benutzern und große Mengen von Daten verarbeiten soll. Das Betriebssystem und mögliche Einrichtungen der Datenübertragung oder des Dateiservice sollten auch bereits optimiert worden sein.
Darüber hinaus ist es wichtig, daß die Vergleichstests mit einer Datenbank durchgeführt werden, deren Größe tatsächlichen Geschäftsumgebungen entspricht. Eine einzelne SQL-Anweisung sollte die gleiche Menge an Daten liefern und den gleichen Aufwand für Sortiervorgänge bewirken wie später in der implementierten Geschäftsumgebung. Bei Beachtung dieser Regel ist sichergestellt, daß die Anwendung repräsentative Speicheranforderungen verursachen wird.
Die Art der zu testenden SQL-Anweisungen sollte entweder zur Kategorie repräsentatives SQL oder zur Kategorie Extremfall-SQL (Worst-Case) gehören, wie im folgenden erläutert wird:
Ein Beispiel hierfür ist eine Anwendung, die ausgeführt wird, wenn ein Telefonanruf von einem Kunden eingeht, und deren Anweisungen ausgeführt werden müssen, um Daten des Kunden abzurufen oder zu aktualisieren, während der Kunde wartet.
Ein Beispiel wäre eine Bankanwendung, die kombinierte Kontoauszüge über die monatlichen Kontobewegungen für sämtliche verschiedene Arten von Konten eines Kunden erstellt. Eine allgemeine Tabelle könnte vielleicht die Kundenadressen und die Kontonummern enthalten; jedoch müssen mehrere andere Tabellen verknüpft werden, um alle benötigten Daten über Kontotransaktionen verarbeiten und zusammenstellen zu können. Die Multiplikation des Aufwands, der für ein Konto erforderlich ist, mit den mehreren Tausend Konten, die im gleichen Zeitraum verarbeitet werden müssen, macht deutlich, das jede potentielle Zeiteinsparung die Leistungsanforderungen erhöht.
Ein Beispiel wäre eine Anwendung, die eine Liste der Arbeiten für Konten erstellt, die während des Arbeitstages auszuführen sind. Wenn die Anwendung gestartet wird, löst die erste größere SQL-Anweisung eine Verknüpfung über zahlreiche Tabellen aus, um eine sehr umfangreiche Liste aller Konten zu erstellen, für die der Benutzer der Anwendung verantwortlich ist. Die Anweisung wird vielleicht nur wenige Male am Tag ausgeführt, aber ihre Ausführung nimmt einige Minuten in Anspruch, wenn sie nicht ausreichend optimiert wurde.