Shop Projekt - Dokumentation
Shop LDM
Teil 03: Benutzer Views & Prozeduren
Dieses Modul erweitert das User-Modul um Views und Prozeduren, die komplexe Abfragen und Geschäftslogik kapseln.
Views vereinfachen häufig verwendete SELECT-Abfragen, während Prozeduren komplexe Operationen und Geschäftslogik sicher und wiederverwendbar bereitstellen.
- v_user: Gibt Benutzer mit Rolle und Status zurück.
- util_user_reference: Steuert, welche Tabellen einen Hard-Delete blockieren.
- p_check_can_delete_user: Prüft, ob ein Benutzer physisch gelöscht werden darf.
- p_delete_user_associated_data: Bereinigt persönliche oder temporäre Daten.
- p_clear_user: DSGVO-konforme Anonymisierung eines Benutzers.
- p_delete_user: Zentrale Hauptprozedur zum Entfernen eines Benutzers.
Dieses Modul wird kontinuierlich erweitert, je nach Anforderungen des Shops.
v_user View
Zweck: Gibt Benutzer mit zugehöriger Rolle und Status zurück.
Felder:
- u.* -- Alle Benutzerfelder aus tb_user
- u_role (rol_key) -- Rollenabkürzung (z.B. 'A', 'U')
- u_role_name -- Rollenname (für Entwickler)
- u_status (ust_key) -- Statusabkürzung (A, N, D, R)
- u_status_name -- Statusname (für Entwickler)
Quelle:
- FROM tb_user u
- JOIN tb_user_role r ON r.rol_ID = u.rol_ID
- JOIN tb_user_status s ON s.ust_ID = u.ust_ID
Sortierung: ORDER BY u.u_IDUtil_user_reference (Referenz-Hilfstabelle)
Zweck: Steuert, welche Tabellen einen Hard-Delete blockieren und welche Daten bei Löschung bereinigt werden.
Felder:
- urc_ID (PK)
- urc_table_name VARCHAR(64) NOT NULL -- Tabelle, die geprüft oder gelöscht wird
- urc_column_name VARCHAR(64) NOT NULL -- Spalte, die auf den Benutzer zeigt
- urc_is_blocking BOOLEAN DEFAULT TRUE -- TRUE = Hard Delete verboten
- urc_is_child BOOLEAN DEFAULT FALSE -- TRUE = indirekt über Zwischentabelle
- urc_to_table VARCHAR(64) DEFAULT NULL -- Parent-Tabelle (bei indirekter Beziehung)
- urc_to_column VARCHAR(64) DEFAULT NULL -- Spalte im Parent
Constraints:
- UNIQUE (urc_table_name, urc_column_name)
- CHECK (Child-Referenzen sind nur löschbare Referenzdaten)
- CHECK (Bei Child muss Parent angegeben sein)p_check_can_delete_user Prozedur
Zweck: Prüft, ob ein Benutzer physisch gelöscht werden darf (Hard Delete) oder ob Referenzen in geschäftskritischen Tabellen dies verhindern.
Input:
- p_user_id INT
Prozess:
1. Scannt tb_util_user_reference nach Einträgen mit urc_is_blocking = TRUE
2. Prüft für jede Tabelle mittels p_check_has_one, ob Datensätze existieren
Output:
- p_can_delete BOOLEAN (TRUE | FALSE)
- p_reason VARCHAR(128) ('BLOCKED: tb_purchase.u_ID_buy' | 'OK')p_delete_user_associated_data Prozedur
Zweck: Bereinigt das System von persönlichen oder temporären Daten, die bei einer Löschung oder Anonymisierung nicht erhalten bleiben müssen.
Input:
- p_user_id INT
Prozess:
1. Nutzt Cursor auf tb_util_user_reference (urc_is_blocking = FALSE)
2. Löscht Daten in korrekter Reihenfolge (zuerst is_child, dann Parent)
3. Vermeidet Fremdschlüssel-Fehler
Betroffene Tabellen (Auszug):
- tb_alarm, tb_trigger_log, tb_trigger_queue
- tb_index_want_search, tb_wantlist, tb_pw_content
- tb_saved_search, tb_cs_content, tb_manager_rights
- tb_reward_log, tb_article, tb_art_storage
- tb_address, tb_user_attributp_clear_user Prozedur
Zweck: DSGVO-konforme Anonymisierung eines Benutzers, falls ein Hard Delete nicht möglich ist.
Input:
- p_user_id INT
- p_deleted_by INT (Admin-ID oder User-ID selbst)
- p_reason ENUM('self', 'admin', 'inactive', 'dsgvo')
Prozess:
1. Setzt ust_ID auf Status 'D' (Deleted)
2. Überschreibt personenbezogene Daten:
- u_name → '__u[ID]_deleted'
- u_mail → '__u[ID].deleted@brulsim.ch'
- u_phone, u_fname, u_lname, u_avatar → NULL
- u_password → anonymer Hash (SHA2)
3. Speichert Lösch-Metadaten in tb_user_attribut:
- u_deleted_at (Zeitstempel)
- u_deleted_reason (Grund)
- u_deleted_by (wer gelöscht hat)p_delete_user Prozedur
Zweck: Die zentrale Hauptprozedur zum Entfernen eines Benutzers aus dem aktiven System.
Input:
- p_user_id INT
- p_deleted_by INT
- p_reason ENUM('self', 'admin', 'inactive', 'dsgvo')
Prozess:
1. Validiert, ob der User existiert
2. Ruft p_check_can_delete_user auf (Löschbarkeit prüfen)
3. Ruft p_delete_user_associated_data auf (persönliche Daten bereinigen)
4. Entscheidung:
- Falls v_can_delete = TRUE → DELETE FROM tb_user (Hard Delete)
- Falls v_can_delete = FALSE → CALL p_clear_user (Anonymisierung)
Fehler:
- Signal SQLSTATE '45000' wenn User nicht existiert