postgresql-table-design
Entwerfen Sie PostgreSQL-Schemata mit Expertenberatung
Das Design von PostgreSQL-Schemata erfordert Kenntnisse über Datentypen, Indizierungsstrategien, Einschränkungen und Leistungsmuster. Diese Fähigkeit bietet umfassende Anleitungen zu PostgreSQL-spezifischen Best Practices, erweiterten Funktionen und häufigen Fallstricken, um Ihnen zu helfen, effiziente und wartbare Datenbankschemata zu erstellen.
Die Skill-ZIP herunterladen
In Claude hochladen
Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen
Einschalten und loslegen
Teste es
Verwendung von "postgresql-table-design". Wie sollte ich Geldbeträge in PostgreSQL speichern?
Erwartetes Ergebnis:
Verwenden Sie NUMERIC(p,s) für Geldbeträge, niemals Float-Typen. Zum Beispiel: amount NUMERIC(10,2) für Währung mit zwei Dezimalstellen. Dies bietet exakte Dezimalarithmetik ohne Gleitkomma-Präzisionsprobleme. Vermeiden Sie den veralteten money-Typ.
Verwendung von "postgresql-table-design". Was ist der Unterschied zwischen BIGINT GENERATED ALWAYS AS IDENTITY und UUID für Primärschlüssel?
Erwartetes Ergebnis:
- BIGINT GENERATED ALWAYS AS IDENTITY: Sequenzielle Integer-IDs. Bevorzugt für die meisten Anwendungsfälle. Vorteile: kleinere Speicherung, schnellere Indizierung, bessere Lokalität. Verwenden Sie, wenn globale Einzigartigkeit über Systeme hinweg nicht erforderlich ist.
- UUID: Global eindeutige Bezeichner. Verwenden Sie bei: Zusammenführen von Daten aus mehreren Datenbanken, Föderierung von Systemen oder wenn Sie undurchsichtige nicht-sequenzielle IDs benötigen. Generieren Sie mit uuidv7() auf PostgreSQL 18+ oder gen_random_uuid() auf älteren Versionen.
Verwendung von "postgresql-table-design". Sollte ich Indizes auf Fremdschlüsselspalten hinzufügen?
Erwartetes Ergebnis:
Ja, fügen Sie immer explizite Indizes auf Fremdschlüsselspalten hinzu. PostgreSQL indiziert FK-Spalten nicht automatisch wie einige andere Datenbanken. Dies beschleunigt Joins und verhindert Sperrprobleme beim Löschen oder Aktualisieren der Elterntabelle. Beispiel: CREATE INDEX ON orders (user_id) für user_id-Fremdschlüssel.
Sicherheitsaudit
SicherThis skill is a documentation-only resource providing PostgreSQL schema design guidance. All 237 static findings are false positives triggered by SQL examples and technical terminology in markdown code blocks. The skill contains no executable code, network calls, or file system access. Safe for publication.
Qualitätsbewertung
Was du bauen kannst
Entwurf eines neuen Datenbankschemas
Erhalten Sie Anleitungen zu Tabellenstruktur, Datentypen, Einschränkungen und Indizierungsstrategien beim Entwerfen einer neuen PostgreSQL-Datenbank für eine Anwendung.
Optimierung der Leistung vorhandener Schemata
Erfahren Sie mehr über Indizierungsstrategien, Partitionierungsoptionen und Leistungsmuster zur Verbesserung der Abfrageleistung und Reduzierung von Datenbank-Bloat.
Überprüfung von Schema-Designentscheidungen
Validieren Sie Datentypwahl, Einschränkungsverwendung und Normalisierungsentscheidungen anhand von PostgreSQL-Best Practices vor der Implementierung.
Probiere diese Prompts
Ich muss eine users-Tabelle mit E-Mail, Namen und Zeitstempeln erstellen. Was ist das empfohlene PostgreSQL-Schema?
Ich speichere Produktpreise, IP-Adressen und Benutzereinstellungen. Welche PostgreSQL-Datentypen sollte ich verwenden?
Meine orders-Tabelle hat Abfragen, die nach user_id, status und created_at filtern. Welche Indizes sollte ich erstellen?
Ich muss Millionen von Sensormesswerten pro Tag speichern mit Abfragen, die nach Gerät und Zeitbereich filtern. Wie sollte ich das Schema und die Partitionierung gestalten?
Bewährte Verfahren
- Beginnen Sie mit normalisierten Schemata bis zur dritten Normalform und denormalisieren Sie nur, wenn Sie gemessene Leistungsprobleme mit bestimmten hochwertigen Abfragen haben
- Verwenden Sie TIMESTAMPTZ für alle Zeitstempelspalten, TEXT für Strings, NUMERIC für Geld und BIGINT GENERATED ALWAYS AS IDENTITY für Primärschlüssel, es sei denn, Sie benötigen UUIDs
- Erstellen Sie Indizes für Spalten, die in WHERE-Klauseln, JOIN-Bedingungen und ORDER BY-Klauseln verwendet werden, und fügen Sie immer explizite Indizes auf Fremdschlüsselspalten hinzu
Vermeiden
- Verwenden Sie keine VARCHAR(n) oder CHAR(n)-Datentypen; verwenden Sie TEXT mit CHECK-Einschränkungen für Längenbeschränkungen, falls erforderlich
- Verwenden Sie nicht TIMESTAMP ohne Zeitzone, den money-Typ oder SERIAL; verwenden Sie stattdessen TIMESTAMPTZ, NUMERIC und GENERATED ALWAYS AS IDENTITY
- Denormalisieren Sie Daten nicht vorzeitig, bevor Sie tatsächliche Leistungsprobleme gemessen haben; vorzeitige Denormalisierung schafft Wartungsaufwand ohne nachgewiesene Vorteile