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.

🗺️ Stufe 0 | 📚 Aktuell | 📟 2026 06 15 | 📍 Datenbank - Benutzer Views & Prozeduren

  • 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_ID

Util_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_attribut

p_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