Datenbankdesign - Entwicklungs-/Test-/Produktivumgebung

[Huwy]

Hallo zusammen,

ich tu mich gerade schwer, mein Thema in der Literatur irgendeinem Bereich zuzuordnen.

Kurz eine Erklärung:

Ich soll mich (eventuell auch bezüglich meiner anstehenden Bachelorarbeit) mit einem Datenbankdesign (ich weiß nicht einmal, ob das wirklich der richtige Begriff ist) beschäftigen, um auf unserer Datenbank klar Entwicklungs-, Test- und Produktivumgebung abzugrenzen. Da das im Moment sehr grob und schlampig gemacht wird (auf dem Produktivschema sind Tabellen, die keiner benötigt; auf dem Testschema liegen produktive Tabellen; Entwicklungsschema ist gar nicht vorhanden), soll ich mich in das Thema einarbeiten und einen Konzeptvorschlag vorstellen.

Nun ist mir der grobe Aufbau aus Ausbildung und Studium in etwa bekannt:

- auf dem Entwicklungsschema befinden sich Tabellen ohne relevante Inhalte

- auf dem Testschema befinden sich Tabellen mit relevanten Inhalten aus einem begrenzen Zeitraum

- auf dem Produktivschema befinden sich alle benötigten Tabellen mit allen benötigten Inhalten

Jedoch weiß ich nicht genau, wie ich an Literatur kommen soll, die das Thema behandelt. Muss ich eventuell in die Richtung Entwicklung nach Büchern und Quellen suchen und mich zuerst gar nicht mit Datenbanken auseinandersetzen? Welcher Begriff beschreibt denn diese klare Abgrenzung von Entwicklungs-, Test- und Produktivumgebung auf einer Datenbank? Kann mir da jemand weiterhelfen? Wäre wirklich dankbar für Literatur, Links, andere Quellen zu diesem Thema.

Falls das für euch noch relevant ist - bei uns ist Teradata 14 im Einsatz und zusätzlich Solid DBs. Entwickelt wird in C++, C#, Perl und Cold Fusion für Abfragen auf die Datenbank.

Viele Grüße

Bearbeitet 29. August 2013 von Huwy

[pr0gg3r]

Im Grunde geht es um folgendes:

Entwicklungssystem:

Hier werden die Datenbanken und das Programm entwickelt. Ist eine Entwicklung fertig, wandert sie ins Testsystem. Dies hat den Vorteil, dass das Produktivsystem nicht von Fehlern beeinflusst wird und somit zu keinem Zeitpunkt nicht lauffähig ist. Außerdem hat die Entwicklung nicht immer Zugriff auf die "richtigen" Daten zu tun, zum Beispiel wenn von einer externen Firma entwickelt wird, die aber keinen Zugriff auf die Unternehmensdaten haben soll.

Testsystem:

Hier wird getestet, ob die Entwicklung den tatsächlichen Anforderungen entspricht. Treten hier keine Fehler auf, werden die Updates in das Produktivsystem ausgerollt. Zugriff auf das Testystem hat sowohl das Entwicklungsteam als auch die projektleitende Seite, die das System verwendet. Dennoch sollten hier keine "richtigen" Daten drin sein, da das Entwicklungsteam noch Zugriff auf diese hat.

Produktivsystem:

Funktioniert (wenn man das oben beschrieben einhält) zu jeder Zeit einwandfrei. Beinhaltet die "richtigen" Daten, das Entwicklungsteam hat aber keinen Zugriff darauf.

Im Grunde geht es um zwei Dinge:

- den Laufenden Betrieb zu gewährleisten

- Entwicklung und produktiven Einsatz zu trennen

Das macht also erst ab einer gewissen Größe Sinn. Ist beides nicht notwendig, braucht man nicht unbedingt ein Trennung von Entwicklungs-, Test- und Produktivumgebung.

[Huwy]

Vielen Dank schon einmal für deine schnelle und ausführliche Antwort.

Genau diese beiden Dinge sollen in Zukunft gewährleistet werden, da das im Moment nicht der Fall ist, es jedoch auf Grund der Datenbank- bzw. auch Unternehmensgröße wirklich nötig ist.

Aber du weißt wahrscheinlich auch nicht, ob es zu dem Thema ausführlichere Literatur gibt oder? Deine Ausführungen helfen mir aber auf alle Fälle schon mal viel weiter.

[pr0gg3r]

Aber du weißt wahrscheinlich auch nicht, ob es zu dem Thema ausführlichere Literatur gibt oder?

Ich könnte mir vorstellen, dass das Thema in IT-Projektmanagement-Büchern angeschnitten wird. Oder auch in SAP-Einsteiger-Literatur wird mehr oder weniger ausführlich auf die Trennung von Entwicklung und Produktivumgebung eingegangen (da dort zwingend notwendig). Ich würde dir da fast dazu raten in einer Buchhandlung entsprechende Bücher durchzublättern.

[Huwy]

Super danke - genau sowas hab ich gemeint, weil ich es eben nicht richtig abgrenzen konnte

[lilith2k3]

Wobei sich mir die grundsätzliche Frage stellt, wozu man eine "Entwicklungsdatenbank" benötigt.

Generell sollte der Code, den ein Entwickler schreibt ohne eine Datenbank auskommen. Dafür gibt es Mockingframeworks.

Im Grunde reicht eine/mehrere Testdatenbank(en), die für alle Tests, die nicht durch Unittests abgedeckt werden können, genutzt werden kann; e.g. Stresstests.

Daneben gibt es dann das/die Produktivsystem(e).

Empfehlenswert ist beispielsweise auch, dass man eine extra-Replikation der Produktivdatenbank nutzt, um Reports drüberlaufen zu lassen, weil diese doch Ressourcen fressen.

[Huwy]

Genau deswegen habe ich hier ein Thema erstellt. Gut, dass ich verschiedene Sichten aufgezeigt bekomme.

Ich bin eben Student im Operating. Der Vorschlag kam nur von meinem Chef mit Entwicklungs-/Testdatenbank. Ich muss mich nicht unbedingt daran halten. Zusätzlich halte ich natürlich noch Rücksprache mit unserer Entwicklungsabteilung - vielleicht sagen die mir das gleiche wie du, dass sie eigentlich gar keine Entwicklungsdatenbank benötigen.

Die Replikation der Produktivdatenbank gibt es schon. Wobei allgemein die Produktivumgebung weniger meine Baustelle sein wird, da hier die gewünschten Anforderungen eigentlich schon gegeben sind - bis auf ein paar Ausreißertabellen.