Ich arbeite an einer modularisierten Java Web App. Die Abhängigkeiten zwischen den Modulen (sichtbare Ebene) und der Geschäfts-/Datenbankebene werden nach Gradle aufgelöst. Aus technischer Sicht muss meine Datenbank nur Tabellen für die Entitäten enthalten, die tatsächlich von den implementierten sichtbaren Modulen verwendet werden. Dies kann jedoch zu potenziellen Problemen führen, wenn ich die Datenbank in der Produktionsumgebung migrieren möchte. Anders als beim Erstellen des Datenbankschemas aus den Abhängigkeiten sehe ich zwei Optionen:Modulares Datenbanklayout: Ein richtiger Ansatz für meinen Anwendungsfall?
1) Ich habe immer ein einziges Schema für alle verfügbaren Entitäten. Meine tatsächliche Datenbank enthält daher die Tabellen für alle Entitäten, auch für diejenigen, die von keinem der implementierten Module verwendet werden. Dies macht die Migration in einer Produktionsumgebung sehr einfach, aber verschleiert die Datenbank und die Ordner, die die Entitäten während der Entwicklung enthalten.
2) Ich habe mehrere unabhängige Schemata, die logisch getrennt sind. Jedes Schema führt zu einer Datenbank auf dem Server. Welche Schemas benötigt werden, wird durch die Modulabhängigkeiten aufgelöst. Ich migriere jedes Schema für sich. Die Migration wird also weiterhin überschaubar bleiben.
Der Server für die Datenbanken würde wie folgt aussehen:
- MYSQLServer
- AuthorizationDatabase
- Usertable
- RoleTable
- UserRoleRelationshipTable
- BlogPostDatabase
- PostTable
- CommentsTable
- AuthorizationDatabase
etc ..
Aber ich weiß nicht, ob die Idee von vielen kleineren Datenbanken statt einer monolithischen Datenbank zu möglichen Problemen führen. Vor allem in Bezug auf die Leistung.