Mit der Tabelle wird das nichts. Bring die mal in die 3te Normalform, danach kann man dir eventuell helfen.

Digot schrieb:

Ich möchte aber nicht die Tags immer neu in eine andere Tabelle hinzufügen müssen

Ist doch aber mit einer Normalisierten DB viel einfacher ...
Tabelle: Sorten

Tabelle: Tags

Tabelle: Sorte_Tags

Hat sie doch ....
schau dir vielleicht mal das hier von ErfinderDesRades an

Die relationale Grundidee

@Manü
Deine Tag-Tabelle ist in meinen Augen ins Absurdum geführt.
Ich würde dieser Tabelle keine numerische Autoinkrement-ID geben, sondern den Text an sich als Unique Primary Key verwenden.
Zum einen ist es etwas lesbarer.
Zum anderen kann ich damit verhindern, dass jemand auf die Idee kommt, ein zweites Eis-Tag anzulegen.

Ansonsten gehe ich mit deiner Grundidee konform.

Die Tabelle soll nicht lesbar sein, sie soll funktionieren, und so funktioniert es nun mal. Er hat sie lediglich in die 3 Normalform gebracht und das ist auch richtig so. So wie ich das verstanden hab sind die Tags statisch, somit ist das Problem mit doppelten Tags nicht mehr in der Welt, ansonsten löst man es halt mit einer Abfrage (was man imho sowieso tun soltle).

Die dritte Normalform schreibt doch nicht vor, dass der Schlüssel numerisch sein muss.
Ich brauche keine numerische ID, um eine nicht numerischen eindeutigen Key zu adressieren.

petaod schrieb:

sondern den Text an sich als Unique Primary Key verwenden

ich glaube da hat mir vor einigen Jahren ein Lehrer mal ziemlich ins gewissen gesch... das eine Eindeutige Zuweisung immer über einen nummerischen Wert zu erfolgen hat ... das ist irgendwie in Fleisch und Blut übergegangen und daher immer eine ID
Zumal Unique-Wert als Zahl imho weniger gehrinschmalz beansprucht ... aber Ja in dem Fall wäre es möglich ... dann ist aber die Frage ob man sich die Tag-Tabelle nicht vielleicht komplett sparen kann

petaod schrieb:

Die dritte Normalform schreibt doch nicht vor, dass der Schlüssel numerisch sein muss.

Wie würde man zu Sheldon sagen? : "Das sind gesellschaftliche Konventionen"

Das würde ich gar nicht mal als Konvention beschreiben, sondern als Regel der Performance-Verbesserung und Speicherplatzeinsparung, die eigentlich bei jedem erstellten Projekt mit MySQL eine Rolle spielen sollte. Demnach ist es einfach vollkommener Schwachsinn Zeichenfolgen, die mehrmals vorkommen, immer wieder auszuschreiben.

Manü schrieb:

dann ist aber die Frage ob man sich die Tag-Tabelle nicht vielleicht komplett sparen kann

Wegen dem Unique Key bräuchte man sie.

Rinecamo schrieb:

als Regel der Performance-Verbesserung und Speicherplatzeinsparung

Speicherplatz kostet es weniger, wenn man die numerische Spalte weg lässt.
Die Performance wird von der Indextabelle bestimmt, die in beiden Fällen angelegt wird.
Performancekritisch wird es dann, wenn man die Tag-Tabelle nicht indizieren würde.

petaod schrieb:

Speicherplatz kostet es weniger, wenn man die numerische Spalte weg lässt.

Also belegen numerische Werte mehr Speicherplatz als größere Zeichenfolgen? Wo?

Man beachte das Smiley!

Wenn ich die numerische Spalte gar nicht anlege, spare ich natürlich die 4-8 Byte pro Record in der Tags-Tabelle.
Das Smiley soll andeuten, dass das eine Milchmädchenrechnung ist.
Sobald die Tag-Texte länger als als die Nummer sind, erhöht sich mit jedem Gebrauch des Tags in der Zwischentabelle der Platzbedarf schneller als bei Verwendung von Nummern.

Andererseits, wenn man die Tag-Länge tatsächlich auf CHAR(4) oder CHAR(8) begrenzt (je nachdem, ob der numerische Index als INT oder als BIGINT gespeichert wird), wird man im Falle der zusätzlichen numerischen Spalte immer mehr Platz benötigen.
Bei VARCHAR oder TEXT verschiebt sich die Aussage nochmals.

Allerdings ist die Diskussion darüber sehr akademisch.
Datenbankoptimierung wird seltenst auf Speicherplatzoptimierung ausgelegt.
Zumindest nicht in dem Bereich, den wir gerade besprechen.

Die Zuordnung der Tags wird erfolgt nicht in der Haupttabelle.
Das passiert nur in der Zwischentabelle.
Schau dir die Tabelle Sorte_Tags in Post #4 an.
Dort werden alle zutreffenden Kombinationen von Sorte und Tag als eigenständiger Record hinterlegt.

ja, ohne die relationale GrundIdee zu studieren und zu kapieren, wirst du hier den Leuts für alle Zeiten Löcher in den Bauch fragen.

Dort ist die Frage beantwortet, aber zunächstmal bitte klare Begrifflichkeiten: HauptTabellen gibts nicht, bestenfalls ParentTables, und davon gibts in diesem Falle 2.

So jetzt gugge Manüs hübsches Bildle, dass du genau unterscheidest, was ich mit "Sort", "Tag" und "Sorte_Tag" meine:
Mehrere Tags kannst du einem Sorten-Datensatz zuordnen, indem du mehrere Sorte_Tag-Datensätze anlegst, die auf denselben Sorte-Datensatz verweisen, aber mit dme anneren ForeignKey auf jeweils einen anneren Tag.

Jo - ist jetzt Datenbänker-Chinesisch ("ForeignKey", "verweisen"), aber das musste halt lernen (und ist eiglich nicht sooo schwer)

Ich kann dir auch aufzeigen, wie man das ganz praktisch umsetzt: vier Views-Videos
Beachte: Dort besteht ein relationales Datenmodell, aber es gibt noch keine Datenbank. Select-Abfragen würde man mit Linq formulieren, das ist so ähnlich, aber wesentlich sicherer und einfacher als Sql.
Meist braucht man aber nichtmal explizite Select-Abfragen, sondern setzt nur einfache Filter.

Jdfs Auf deinem Lernlevel täte ich von einer DB auch erstmal abraten: Datenbänkerei-Einstieg