Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m290_guko:learningunits:lu08:theorie:b_fk-grundlagen [2025/10/18 20:59] – gkoch
+++ modul:m290_guko:learningunits:lu08:theorie:b_fk-grundlagen [2025/10/20 14:17] (aktuell) – gkoch
@@ Zeile 41: / Zeile 41: @@
 <WRAP round 80% center>
 **Warum nur //eine// Kategorie pro Zeile?**
-Komma-Listen wirken bequem, sind aber **ungünstig**:
+Komma-Listen wirken bequem, sind aber ungünstig:
   * **Keine Prüfung / kein FK((Foreign Key = Fremdschlüssel)).** Die Datenbank (DB) kann bei «Belgien, Städtereise» **nicht** prüfen, ob diese Kategorien wirklich existieren. ((Wenn Kategorien und Posts in **separate Tabellen** liegen und per Fremdschlüssel verbunden sind, kontrolliert die DB beim Speichern, ob «Belgien» in der Kategorien-Tabelle vorhanden ist.)) → Tippfehler bleiben unbemerkt ((z. B. «Belgien, Städtereisen» statt «Belgien, Städtereise»)).
-  * **Unzuverlässiges Filtern.** Suchen mit LIKE liefern leicht Teiltreffer/Varianten (Leerzeichen, Reihenfolge). Beispiel: WHERE category_name LIKE '%Guinea%' trifft auch «Equatorial Guinea», «Guinea», «Guinea-Bissau» und «Papua New Guinea» – vier verschiedene Länder.
+  * **Unzuverlässiges Filtern.** Suchen mit LIKE liefern leicht Teiltreffer/Varianten. Beispiel: ''WHERE category_name LIKE '%Guinea%''' trifft auch «Equatorial Guinea», «Guinea», «Guinea-Bissau» und «Papua New Guinea» – vier verschiedene Länder.
-  * **Schwierig auszuwerten & langsam.** Zählen/Gruppieren erfordert Strings zu zerlegen; darauf kann die DB nicht sinnvoll indexieren((**Index**: Ein Index ist wie ein Inhaltsverzeichnis der Datenbank. Er beschleunigt Suchen/Sortieren auf **einzelnen** Spaltenwerten. Bei Komma-Listen stecken **mehrere** Werte in **einem** Feld – darauf lässt sich kein brauchbarer Index aufbauen; zudem können Suchmuster wie LIKE '%Wort%' einen vorhandenen Index oft nicht nutzen.)).
+  * **Schwierig auszuwerten & langsam.** Zählen/Gruppieren erfordert Strings((Zeichenketten)) zu zerlegen; darauf kann die DB nicht sinnvoll indexieren((**Index**: Ein Index ist wie ein Inhaltsverzeichnis der Datenbank. Er beschleunigt Suchen/Sortieren auf **einzelnen** Spaltenwerten. Bei Komma-Listen stecken **mehrere** Werte in **einem** Feld – darauf lässt sich kein brauchbarer Index aufbauen; zudem können Suchmuster wie LIKE '%Wort%' einen vorhandenen Index oft nicht nutzen.)).
 **Besser:** Pro Zeile **eine** Kategorie. Für mehrere Kategorien pro Post (N:M-Beziehung) verwenden wir eine **Zwischentabelle** //post_category//.
@@ Zeile 56: / Zeile 56: @@
 **Auszug:**
-<WRAP center box 80% round>
+{{ :modul:m290_guko:learningunits:lu08:theorie:all_in_one_table_1.png?nolink&900 | Tabelle mit allen Posts}}
-^ id ^ post_title                          ^ author_name   ^ author_email                   ^ category_name ^ created_at           ^
-| 1  | Hasselt – 10 Highlights             | Martin Merten | martin@wetraveltheworld.de     | Städtereise   | 2025-05-07 10:15:00 |
-| 2  | Utrecht – 10 Sehenswürdigkeiten     | Martin Merten | martin@wetraveltheworld.de   | Städtereise   | 2025-06-05 09:30:00 |
-| 3  | Lissabon – 8 Tipps zu den wichtigsten Sehenswürdigkeiten  | Caro Steig    | caro@wetraveltheworld.de      | Portugal      | 2025-03-21 08:40:00 |
-</WRAP>
 <WRAP box round 80% center>
@@ Zeile 68: / Zeile 63: @@
   * **Fehleranfällig**: Kategorienamen können unterschiedlich geschrieben werden.
   * **Aufwendig**: E-Mail-Wechsel eines Autors → alle Zeilen suchen und ändern.
+  * **Nur eine Kategorie möglich**: Idealerweise möchten wir aber mehrere Kategorien pro Blog-Post vergeben – z.B. beim Blog-Post «Utrecht – 10 Sehenswürdigkeiten»: Niederlande, Städtereise.
 </WRAP>
@@ Zeile 110: / Zeile 106: @@
 //Gleicher Autor, unterschiedliche E-Mail → Daten sind inkonsistent.//
+<WRAP center tip round 80%>
-==== Warum N:M (Posts ↔ Kategorien) auflösen? ====
+[[https://www.youtube.com/watch?v=W4UkIK2BwS8|Beziehungen in relationalen Datenbanken (1:n, n:m, 1:1) – einfach erklärt]]((Patrick Boekhoven / YouTube)) -> (9:02, de) Grundlagen zu PK/FK und warum wir Beziehungen brauchen; zeigt, wie man 1:n modelliert und warum n:m ohne Zwischentabelle nicht direkt geht.
-Ein Post kann **mehreren** Kategorien zugeordnet sein (z. B. *Hasselt* → *Belgien* **und** *Städtereise*). Eine Kategorie enthält **viele** Posts. Das ist **N:M**.
-**Fehlversuch 1 – Duplikate statt Beziehung:**
-<WRAP center box 80% round>
-^ id ^ post_title               ^ author_name   ^ category_name ^
-| 4  | Hasselt – 10 Highlights  | Martin Merten | Belgien       |
-| 5  | Hasselt – 10 Highlights  | Martin Merten | Städtereise   |
-</WRAP>
-//Titel steht doppelt → Änderungen/Löschungen an mehreren Stellen (fehleranfällig).//
-**Fehlversuch 2 – Kommaliste in einer Spalte:**
-<WRAP center box 80% round>
-^ id ^ post_title               ^ category_name (Text) ^
-| 4  | Hasselt – 10 Highlights  | Belgien,Städtereise  |
-</WRAP>
-//Für die DB ist «Belgien,Städtereise» nur Text: keine Prüfbarkeit, mühsame Abfragen (LIKE-Tricks), langsam bei vielen Daten.//
-<WRAP tip round 80% center>
-**Besser (wie in LU08c umgesetzt):**
-Trennung in **users**, **posts**, **categories** und die **Zwischentabelle post_category** (eine Paarung pro Zeile: //(post_id, category_id)//).
-So bleiben Schlüssel **eindeutig**, Daten **prüfbar** und Abfragen **klar**.
 </WRAP>
 ==== Ausblick ====
-In **LU08c** bauen wir genau dieses Mehrtabellen-Schema **mit Fremdschlüsseln** auf und füllen es mit den obigen Reiseblog-Beispieldaten. In **LU08d** steuern wir dann mit **Referenzaktionen** (*RESTRICT*, *CASCADE*, *SET NULL*), was beim Löschen/Ändern verknüpfter Daten passiert.
+Auf der nächsten Seite bauen wir genau dieses Mehrtabellen-Schema **mit Fremdschlüsseln** auf und füllen es mit den obigen Reiseblog-Beispieldaten.