Die Empfehlung, dass jeder Entwickler ein eigenes Datenbankschema zur Verfügung haben sollte, kommt ebenfalls aus dem DbUnit-Projekt [DbUnit Best Practices, 2010]. Die Idee dahinter ist klar: Für die Durchführung von integrativen Datenbanktests kann nur ein Test zurzeit laufen. Wenn sich mehrere Entwickler ein Datenbankschema teilen, erfordert das einiges an Abstimmungsbedarf und führt im schlimmsten Fall zu Wartezeiten. Das erinnert ein wenig an alte Zeiten, in denen ein zwei Stunden Zeitfenster ausreichen musste, um einen Stapel Lochkarten auszuführen und die auftretenden Fehler zu entdecken. Diese Situation passt nicht in die heutige Entwicklerwelt, in der dem Team alle Beschränkungen aus dem Weg geräumt werden sollen.
Abbildung 7.1, „Eine Datenbank pro Entwickler“ skizziert das angesprochene Problem. Der Software-Entwickler verwendet für die lokale Anwendung und für die checkerberry db-Tests das gleiche Datenbankschema. Zum einen ergibt sich das Problem, dass die lokale Anwendung und die Tests nicht parallel ausgeführt werden können. Zum anderen löscht checkerberry db regelmäßig die Daten in dem Schema, sodass sich der Entwickler keine Testdaten für die lokale Anwendung aufbauen kann.
Abbildung 7.2, „Zwei Datenbanken pro Entwickler“ zeigt die Lösung des Problems. Sowohl die lokale Anwendung als auch die checkerberry db-Tests verwenden ein eigenes Schema und können so unabhängig voneinander ausgeführt werden.
Aus unserer Sicht geht die Forderung ein Datenbankschema pro Entwickler bereitzustellen in die richtige Richtung, wobei es konkreter „mindestens ein Schema“ heißen müsste. In den meisten Projekten haben Entwickler lokale Installationen der Kundenanwendungen. Diese Anwendungen werden zum Entwickeln, Testen oder zur Fehleranalyse verwendet. Die Anwendungen benötigen häufig umfangreiche Daten, die sequentiell durch den Entwickler aufgebaut werden. Es ist nicht sehr förderlich, wenn diese Datenbestände jedes Mal gelöscht werden, wenn lokal integrative Datenbanktests durchgeführt werden. Natürlich kann der Entwickler die Daten sichern und neu einspielen. Dieser Schritt ist jedoch fehleranfällig, insbesondere da er einfach vergessen werden kann. Die Korrektur dieses Datenverlustes kostet Zeit und Nerven. Durch die Einrichtung von mehreren Datenbankschemata pro Entwickler kann man diesen Problemen aus dem Weg gehen.
Die Forderung eines eigenen Datenbankschemas für jeden Entwickler ist effizient nur durch eine entsprechende Infrastruktur zu gewährleisten. Die Installation eines neuen Datenbankschemas muss so einfach wie möglich sein, damit neue Entwickler schnell ein eigenes Schema bekommen können und damit Änderungen der Datenbankstruktur schnell für alle Entwickler verfügbar sind. In vielen Umgebungen, wie z.B. Maven, kann die Anlage oder Änderung eines Datenbankschemas durch die Ausführung eines parametrisierbaren Skripts erfolgen.
Wenn diese Infrastruktur aufgebaut ist, macht es keinen großen Unterschied, ob jeder Entwickler ein oder zwei Datenbankschemata zur Verfügung hat. Es bleibt abhängig von den fachlichen Anforderungen, wie viele Datenbankschemata für die effiziente Software-Entwicklung erforderlich sind. Es sollte jedoch darauf geachtet werden, dass einheitliche Namenskonventionen verwendet werden z.B. "USR4711" und "USR4711_TEST" o.ä.