Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m290_guko:learningunits:lu08:theorie:b_fk-grundlagen [2025/10/18 22:23] – gkoch
+++ modul:m290_guko:learningunits:lu08:theorie:b_fk-grundlagen [2025/10/20 14:17] (aktuell) – gkoch
@@ Zeile 44: / Zeile 44: @@
   * **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. 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((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.)).
@@ 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 111: / Zeile 106: @@
 //Gleicher Autor, unterschiedliche E-Mail → Daten sind inkonsistent.//
+<WRAP center tip round 80%>
-==== Warum eine N:M-Beziehung (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 einzelner Post kann zu mehreren Kategorien gehören (z. B. //Hasselt// → //Belgien// und //Städtereise//). Umgekehrt enthält eine Kategorie viele verschiedene Posts. Das ist eine klassische **N:M-Beziehung**. Versucht man, das ohne Zwischentabelle abzubilden, entstehen typische Probleme:
-**Variante 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>
-Hier wird derselbe Post mehrfach angelegt, nur um verschiedene Kategorien zu speichern. Ändert sich der Titel oder der Autor, müssen mehrere Zeilen angepasst werden. Beim Löschen bleibt schnell ein „Zwilling“ übrig – das macht Datenpflege fehleranfällig.
-**Variante 2: Komma-Liste in einer Spalte**
-<WRAP center box 80% round>
-^ id ^ post_title               ^ category_name (Text) ^
-| 4  | Hasselt – 10 Highlights  | Belgien, Städtereise  |
-</WRAP>
-In dieser Form steckt mehr als ein Wert in einer Zelle. Die Datenbank kann nicht prüfen, ob „Belgien“ und „Städtereise“ tatsächlich gültige Kategorien sind (kein Fremdschlüssel). Abfragen werden umständlich („LIKE“-Suchen, Trennen von Texten), zählen pro Kategorie ist mühsam und bei grossen Datenmengen langsam.
-<WRAP tip round 80% center>
-**Bessere Lösung:**
-Wir trennen **posts** und **categories** und führen eine **Zwischentabelle** //post_category// ein. Jede Zeile dieser Tabelle speichert genau **ein Paar** //(post_id, category_id)//. So bleiben Primärschlüssel eindeutig, Fremdschlüssel prüfbar und Abfragen klar und schnell.
-</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.