managarten/manadeck/apps/mobile/Docs/database.md

Manadeck Datenbank-Dokumentation

Übersicht

Die Manadeck-Anwendung verwendet Supabase (PostgreSQL) als Backend-Datenbank. Die Datenbank ist für eine mobile Lern- und Karteikarten-Anwendung konzipiert und unterstützt Multi-User-Funktionalität mit Row Level Security (RLS).

Datenbankstruktur

Tabellen

1. profiles

Speichert Benutzerprofile und Einstellungen.

Spalte	Typ	Beschreibung	Constraints
id	uuid	Benutzer-ID (Referenz zu auth.users)	PRIMARY KEY, NOT NULL
username	varchar	Eindeutiger Benutzername	NOT NULL, UNIQUE
display_name	varchar	Anzeigename des Benutzers	NULL
avatar_url	text	URL zum Profilbild	NULL
bio	text	Biografie/Beschreibung	NULL
preferences	jsonb	Benutzereinstellungen als JSON	DEFAULT '{}'
created_at	timestamptz	Erstellungszeitpunkt	DEFAULT now()
updated_at	timestamptz	Letzte Aktualisierung	DEFAULT now()

Beziehungen:

• Foreign Key zu auth.users(id) über id

2. decks

Verwaltet Kartenstapel/Sammlungen von Lernkarten.

Spalte	Typ	Beschreibung	Constraints
id	uuid	Eindeutige Deck-ID	PRIMARY KEY, DEFAULT gen_random_uuid()
user_id	uuid	Besitzer des Decks	NOT NULL, FK zu auth.users
title	varchar	Titel des Decks	NOT NULL
description	text	Beschreibung des Decks	NULL
cover_image_url	text	URL zum Cover-Bild	NULL
is_public	boolean	Öffentlich sichtbar?	DEFAULT false
settings	jsonb	Deck-spezifische Einstellungen	DEFAULT '{}'
tags	text[]	Array von Tags	DEFAULT '{}'
metadata	jsonb	Zusätzliche Metadaten	DEFAULT '{}'
created_at	timestamptz	Erstellungszeitpunkt	DEFAULT now()
updated_at	timestamptz	Letzte Aktualisierung	DEFAULT now()

Beziehungen:

• Foreign Key zu auth.users(id) über user_id
• One-to-Many Beziehung zu cards

3. cards

Einzelne Lernkarten innerhalb der Decks.

Spalte	Typ	Beschreibung	Constraints
id	uuid	Eindeutige Karten-ID	PRIMARY KEY, DEFAULT gen_random_uuid()
deck_id	uuid	Zugehöriges Deck	NOT NULL, FK zu decks
position	integer	Position innerhalb des Decks	NOT NULL
title	varchar	Titel/Überschrift der Karte	NULL
content	jsonb	Karteninhalt (strukturiert)	DEFAULT '{}'
card_type	card_type (enum)	Typ der Karte	NOT NULL, DEFAULT 'text'
ai_model	varchar	Verwendetes AI-Modell	NULL
ai_prompt	text	AI-Prompt für Generierung	NULL
version	integer	Versionsnummer	DEFAULT 1
is_favorite	boolean	Als Favorit markiert?	DEFAULT false
created_at	timestamptz	Erstellungszeitpunkt	DEFAULT now()
updated_at	timestamptz	Letzte Aktualisierung	DEFAULT now()

Beziehungen:

• Foreign Key zu decks(id) über deck_id

Custom Types

card_type (Enum)

Definiert die verschiedenen Kartentypen:

• text - Reine Textkarte
• mixed - Gemischter Inhalt
• quiz - Quiz-Karte
• flashcard - Klassische Lernkarte

Sicherheit (Row Level Security)

Alle Tabellen haben RLS aktiviert mit folgenden Policies:

profiles Policies

Policy	Operation	Beschreibung
"Profiles are viewable by everyone"	SELECT	Alle können Profile einsehen
"Users can insert own profile"	INSERT	Authentifizierte Benutzer können eigenes Profil anlegen
"Users can update own profile"	UPDATE	Benutzer können nur eigenes Profil bearbeiten

decks Policies

Policy	Operation	Beschreibung
"View public decks and own decks"	SELECT	Öffentliche Decks und eigene Decks sind sichtbar
"Users can create own decks"	INSERT	Authentifizierte Benutzer können Decks erstellen
"Users can update own decks"	UPDATE	Nur eigene Decks können bearbeitet werden
"Users can delete own decks"	DELETE	Nur eigene Decks können gelöscht werden

cards Policies

Policy	Operation	Beschreibung
"View cards from accessible decks"	SELECT	Karten aus öffentlichen oder eigenen Decks sind sichtbar
"Users can create cards in own decks"	INSERT	Karten können nur in eigenen Decks erstellt werden
"Users can update cards in own decks"	UPDATE	Karten in eigenen Decks können bearbeitet werden
"Users can delete cards in own decks"	DELETE	Karten in eigenen Decks können gelöscht werden

Aktivierte Extensions

• uuid-ossp (v1.1) - UUID-Generierung
• pgcrypto (v1.3) - Kryptografische Funktionen
• pg_graphql (v1.5.11) - GraphQL-Unterstützung
• pg_stat_statements (v1.11) - Query-Performance-Monitoring
• supabase_vault (v0.3.1) - Sichere Speicherung sensibler Daten

Migrations-Historie

Die Datenbank wurde über folgende Migrationen aufgebaut:

1. 20250819065657_create_profiles_table - Erstellung der Profil-Tabelle
2. 20250819065714_create_decks_table - Erstellung der Decks-Tabelle
3. 20250819065733_create_cards_table - Erstellung der Cards-Tabelle
4. 20250819065806_enable_rls_and_policies - Aktivierung von RLS und initiale Policies
5. 20250819081009_fix_profiles_insert_policy - Korrektur der Profil-Insert-Policy
6. 20250819081105_update_all_rls_policies - Aktualisierung aller RLS-Policies
7. 20250819091919_fix_decks_rls_policy - Korrektur der Decks-RLS-Policy
8. 20250819092831_fix_decks_foreign_key - Korrektur des Foreign Keys in Decks
9. 20250819100624_fix_cards_rls_policies - Korrektur der Cards-RLS-Policies

Datenmodell-Beziehungen

auth.users
    ↓ (1:1)
profiles
    ↓ (1:n)
decks
    ↓ (1:n)
cards

Verwendung in der Anwendung

Supabase Client-Konfiguration

Die Anwendung verwendet den Supabase JavaScript Client (utils/supabase.ts) mit:

• AsyncStorage für Session-Persistenz
• Umgebungsvariablen für Konfiguration:
  • EXPO_PUBLIC_SUPABASE_URL
  • EXPO_PUBLIC_SUPABASE_ANON_KEY

Typische Operationen

1. Benutzerregistrierung: Erstellt automatisch einen Eintrag in profiles
2. Deck-Erstellung: Benutzer können mehrere Decks mit verschiedenen Einstellungen erstellen
3. Karten-Management: Karten können verschiedene Typen haben und AI-generiert sein
4. Öffentliche Decks: Decks können als öffentlich markiert und von anderen eingesehen werden

Best Practices

1. Immer RLS verwenden: Alle Datenzugriffe werden durch RLS-Policies geschützt
2. JSONB für Flexibilität: content, settings, preferences und metadata nutzen JSONB für flexible Datenstrukturen
3. UUID als Primary Keys: Verwendung von UUIDs für bessere Skalierbarkeit und Sicherheit
4. Timestamps: Automatisches Tracking von Erstellung und Aktualisierung
5. Soft Deletes: Können über das metadata JSONB-Feld implementiert werden

Optimierungsmöglichkeiten

1. Indizes: Zusätzliche Indizes auf häufig genutzte Spalten (z.B. user_id, is_public)
2. Partitionierung: Bei großen Datenmengen könnte Tabellen-Partitionierung sinnvoll sein
3. Materialized Views: Für komplexe Abfragen öffentlicher Decks
4. Full-Text Search: Implementierung mit PostgreSQL FTS für Deck- und Kartensuche
5. Caching: Redis-Integration für häufig abgerufene öffentliche Inhalte