Datenbankmodell

[heinetz]

Hallo Forum,

ich stehe vor folgender Aufgabe:

Ich habe in meiner MySQL-DB eine Tabelle 'Anbieter'. In der stehen
Informationen zum Anbieter, wie bzw. Name usw. und unter anderem auch
ein feld 'id'. Jetzt soll ein Tagging eingeführt werden: Einem Anbieter
ist ein oder mehrere Tags zugeordnet. Hinter diesen Tags verbergen sich
letzdenlich Namen wie z.B. 'Gartenmöbel', 'Planzen', 'Tiernahrung'. Nun
sollen z.b der Anbieter mit der anbieter_id 1 die Tags 'Gartenmöbel' und 'Planzen' und der Anbieter mit der anbieter_id 3 die Tags 'Planzen' und 'Tiernahrung' zugeordnet werden. Die Tags kann man ganz eifach mit einer Tabelle auflösen:

tag_id: 1; tag_name: 'Gartenmöbel',
tag_id: 2; tag_name: 'Planzen',
tag_id: 3; tag_name: 'Tiernahrung'

Dann müsste man nur die Kombination aus tag-id und anbieter_id in relation setzen. Nur wie?

Der für mich logisch naheliegende Gedanke ist ein weiteres Feld 'Tags'
in meine Anbietertabelle aufzunehmen, in der dann für jeden Anbieter
durch Komma getrennt, die ihm zugeordneten Tags stehen. Ich weiss aber
selbst, dass das Quatsch weil unsinniges DB-Modell ist. Nur wie macht
man 's richtig. Wenn ich das Thema 'Normalisierung' damals richtig
verstanden habe, würde man die Zuordnung in einer separaten Tabelle
machen, in der ein Datensatz dann nur aus:

tag-id und anbieter_id

... bestünde. Damit wären in dem Beispiel für den Anbieter anbieter_id:1
sowie für den Anbieter anbieter_id:3 jeweils 2 Datensätze vorhanden.

Was ich mir dabei schwierig vorstelle ist die Praxis:

ich stelle mir vor, die Tagzuordnug für den Anbieter über eine
Multiselectbox abzubilden. Das hiesse aber beim Update (ein Formular,
das diese Mulitselectbox wird verschickt) mit zwei SQL-Statements
gearbeitet werden muss:

1. lösche alle datensätze mit z.B. anbieter_id:3
2. füge 2 datensätze: anbieter_id:3 tag_id:2 UND anbieter_id:3 tag_id:3
   hinzu.

... korekt ?

Das geht sicher so, aber 'gefühlt' würde ich ein 'UPDATE' der Infoamtionen eines Anbieters für richtig halten.

Was meint Ihr ?

gute Nacht und

viele gruesse,
heinetz
für richtig halten.

[Rouven]

Hello,

Was meint Ihr ?

Ich kann dir nur bestätigen, dass die neue Tabelle der korrekte Ansatz ist. Zwischen Tags und Anbietern besteht eine n:m-Beziehungen. Wie uns die Datenbanktheorie lehrt löst man so etwas über eine zusätzliche Tabelle auf. Alles andere stellt dich genau so vor Probleme:

• finde alle Anbieter mit Tag x
• wie viele Tags hat Anbieter y

Der Datenbank ist es übrigens vollkommen egal, dass du da mehr als einen Datensatz pro Anbieter drin hast, vorausgesetzt du wählst den Primärschlüssel richtig. Auch die Abfrage wird (meiner Meinung nach) einfacher durch eine einzeln stehende Tabelle, also durch irgendwelches Mengen- oder Stringmischmasch.
Einzig dein Argument der Aktualisierung ist spannend. Alles Löschen und neu Anlegen ist eine Möglichkeit (solange das Löschen keine Auswirkung hat), ein schrittweiser Abgleich der Liste ist eine andere.

MfG
Rouven

[EKKi]

Mahlzeit Rouven,

Einzig dein Argument der Aktualisierung ist spannend. Alles Löschen und neu Anlegen ist eine Möglichkeit (solange das Löschen keine Auswirkung hat),

Wenn das verwendete Datenbanksystem Transaktionen unterstützt, sollte das kein Problem darstellen, wenn man "alle Tags für Anbieter X löschen" und "alle ausgewählten Tags für Anbieter X hinzufügen" in einer Transaktion unterbringt.

ein schrittweiser Abgleich der Liste ist eine andere.

Das stimmt zwar, aber ich würde für o.g. Möglichkeit plädieren - beim schrittweisen Abgleich muss man wieder unnötig mit mehreren Schleifen herumhampeln (und dass sowas gerne mal in die Hose geht, habe ich gerade in den letzten Tagen mal wieder erfahren dürfen, als ich uralten Schleifen-Code von Kollegen reparieren durfte, weil "da Einträge im Kalender fehlen" ... natürlich waren sie vorhanden, aber sie wurden schlicht nicht angezeigt, da sich mehrere Schleifen verheddert hatten).

MfG,
EKKi

[heinetz]

Prima,

danke für die Aufklärung. ich werde mir dennoch überlegen müssen,
ob das aus Gründen der Praktikablität so machen kann:

die Zuordnung der Tags soll zwar letzendlich über eine CMS-Lösung
stattfinden, aber die Erstbefüllung muss nun, weil die Lösung
erst gebaut werden muss, über CSV-Import stattfinden. Sprich:

Der Kunde muss die Zuordnung erstemal in einer Excell-Matrix
machen und die DB-Struktur als Excell-Matrix wird zu nach meiner Einschätzung zu unübersichtlich.

... darunter leidet dann erstmal das DB-Modell, was definietv falsch
ist, aber sich u.U. nicht ändern lässt ;(

danke,
gruesse,
heinetz