Prompt für das Datenbank-Schema-Design

Wann dieser Prompt sinnvoll ist

Nutzen Sie diesen Prompt, wenn Sie ein relationales Schemadesign benötigen und einen konkreten Ausgangspunkt statt generischer Entitätslisten suchen. Ersetzen Sie die fiktiven Details durch Ihre eigenen, bestätigten Geschäftsregeln, bevor Sie das Ergebnis in einer realen Umgebung einsetzen.

Der Prompt

## Rolle
Agiere als Backend-Datenbankarchitekt. Wende dein professionelles Urteilsvermögen an und gestalte deine technischen Entscheidungen so, dass sie für einen Software-Ingenieur auf mittlerem Erfahrungsniveau (Intermediate) klar nachvollziehbar sind.

## Kontext
KiteFleet betreibt einen mandantenfähigen Ausrüstungsverleih. Kunden mieten Schwermaschinen auf Tages- oder Wochenbasis. Das System muss den Bestand über verschiedene Depots hinweg, Buchungen mit mehreren Artikeln, Sicherheitskautionen und Wartungsinspektionen nachverfolgen. Geräte dürfen nicht vermietet werden, während eine aktive Inspektion läuft. KiteFleet nutzt PostgreSQL 16.

## Ziel
Entwirf ein normalisiertes relationales Schema, das Doppelbuchungen verhindert, Statusübergänge für Wirtschaftsgüter (Assets) protokolliert und die Kundenabrechnung von der Reservierungshistorie trennt.

## Zielgruppe
Die primären Nutzer sind Backend-Ingenieure. Gestalte das Ergebnis so, dass es unmittelbar für Migrationsskripte verwendet werden kann, und liefere ausreichend technischen Kontext, um Datentypen und Indizierungsentscheidungen zu begründen.

## Anforderungen
Liefere sauberes PostgreSQL-DDL; Tabellendefinitionen mit Primärschlüsseln, Fremdschlüsseln und Spalten-Constraints; Enum-Typen für Statuszustände; partielle oder eindeutige Indizes (Unique Indexes), um überschneidende Buchungen zu verhindern; sowie eine kurze Erklärung der relationalen Kardinalitäten für die Kernentitäten.

## Einschränkungen
Führe keine externen Microservices, Event-Streams oder Document-Stores ein. Arbeite strikt mit relationalen Tabellen in PostgreSQL. Erfinde keine Preisformeln oder Payment-Gateway-Integrationen, die über Standard-Guthabensalden hinausgehen. Lege alle Normalisierungsannahmen klar dar.

## Ton & Stil
Präzise, idiomatisch und technisch. Bevorzuge explizite Constraint-Namen, SQL-Standardkonventionen und snake_case-Benennungen. Füge kurze Inline-Kommentare für nicht offensichtliche Constraints hinzu.

## Ausgabeformat
Präsentiere zuerst das PostgreSQL-DDL-Skript in einem eigenen Codeblock. Darauf folgt eine Tabellenübersicht mit Details zu den Entitätsbeziehungen. Schließe mit einer Tabelle zur Index-Begründung und einer kurzen Liste von Randfällen (Edge Cases) ab, die auf Anwendungsebene durchgesetzt werden müssen.

## Was zu vermeiden ist
Vermeide unpräzise TEXT-Typen für eingeschränkte Statuswerte, fehlende Cascade-Regeln bei Fremdschlüsseln, Soft-Delete-Mechanismen ohne Berücksichtigung von Indizes und generische UUID-Schlüssel ohne Performance-Begründung.

## Erfolgskriterien
Ein Ingenieur kann das DDL ohne Syntaxfehler ausführen, versteht, wie überschneidende Reservierungen blockiert werden, und kann nachvollziehen, dass Wartungszustände die Buchung von Mietvorgängen verhindern.

## Klärungsfragen
Stelle maximal drei gezielte Fragen, falls fehlende Schemagrenzen die Normalformen der Tabellen verändern würden. Fahre andernfalls mit dem Szenario fort, dokumentiere Annahmen und hebe Trade-offs für den Produktivbetrieb hervor.

Warum er funktioniert

• Das Szenario definiert explizite Domänenlogik (Depots, überschneidende Mietzeiträume, Wartungssperren) anstelle eines abstrakten CRUD-Modells.
• Die Anforderungen verlangen produktionsreifes DDL und Schutz vor Nebenläufigkeitsproblemen (Concurrency) statt einfacher Entitätsdiagramme.
• Die Einschränkungen halten den Entwurf auf die relationale Transaktionsintegrität fokussiert, ohne voreilige verteilte Architekturen einzuführen.
• Die Erfolgskriterien stellen sicher, dass ausführbarer Code entsteht, der die Geschäftsregeln des Szenarios direkt umsetzt.

Anpassen und verwenden

Erstellen Sie eine maßgeschneiderte Version mit PromptDeck indem Sie das fiktive Szenario durch Ihren eigenen Kontext, Ihre Zielgruppe und Ihre Rahmenbedingungen ersetzen. Behalten Sie die Verifizierungsschritte bei, damit das Endergebnis exakt Ihren Anforderungen entspricht.