Frage zur Tabellenstruktur in mysql

[xoni]

Hallo Liebe Leute,

folgende Struktur habe ich hier vorliegen...

Tabelle: Dünger
------------------
id | name
01 | Blühfix


Tabelle: Wirkstoff
id | name
------------------
01 | FloraFix_1000
02 | BlühExplode_007
03 | Co2Killer_42


Tabelle: Wirkstoff_to_Dünger
Wirkstoff_id | Dünger_id
-------------------------
01 | 01
02 | 01
03 | 01


Die Tabellenstruktur ist denke ich selbsterklärend.

Problem hierbei:
Die Wirkstoffe können in unterschiedlichen Konzentrationen
auftreten, also mal 12% mal 37% oder was weiß ich in welcher Konzentration.

Wie geht man da am Besten vor?

Für jeden Wirkstoff und %-Satz einen eigenen Eintrag in der Tabelle Wirkstoff?

Tabelle: Wirkstoff
id | name
------------------
01 | 01% FloraFix_1000
02 | 02% FloraFix_1000
03 | 03% FloraFix_1000
04 | …

Oder wie lässt sich so etwas am Besten abbilden?

Vielen Dank für Eure Tipps…

[Melegrian]

Tabelle: Wirkstoff
id | name | konzentrationen
------------------
01 | FloraFix_1000 | 0.06

Where mit > oder einen anderen entsprechenden Operator. Brauchst doch nicht für alles einen neuen Datensatz anlegen, wenn sich nur die Prozente unterscheiden, es sei denn da unterscheidet sich noch mehr, wie der Preis oder so. Oder es gibt zu viele Varianten.

Tabelle: Wirkstoff
id | name | kon6 | kon7 | kon8
------------------
01 | FloraFix_1000 | - | 0.07 | -

[xoni]

@ Melegrian

vielen Dank für die fixe Antwort.

Verwende ich Deine Lösung, habe ich für den Wirkstoff
`Florafix_1000` 100 Einträge in der Tabelle stehen (1 bis 100%).

Sollte sich der Name `Florafix_1000` einmal ändern, sind also
100 Datensätze von einem UPDATE/DELETE betroffen.

Sollte ich da noch weiter normalisieren oder ist das OK so?

[Melegrian]

So richtig durchdacht war das auch noch nicht von mir. Kommst vielleicht besser weg mit einer Tabelle nur für Prozente und dann die Tabellen und Abfrage damit verknüpfen?

Dann brauchte das Produkt nur einmal aufgeführt werden und bei der Abfrage wird nachgeschaut, ob in der gewünschten Konzentration vorhanden.

Irgendwie gefällt mir das so oder so nicht. Ich meine gibt es da für jedes Mittel in 100 Abstufungen?

[xoni]

Hallo Melegrian,

ich werds mal so versuchen...

Tabelle: Wirkstoff
id | Wirkstoffbezeichnung_id | Konzentration
------------------
01 | 01 | 0.10
02 | 02 | 0.50


Tabelle: Wirkstoffbezeichnung
id | name
------------------
01 | FloraFix_1000
02 | BlühExplode_007
03 | Co2Killer_42


Dann habe ich den Wirkstoff auch nur noch ein mal
in der Tabelle, die %-Werte schreieb ich dahinter.

Ich denke, das kann man so machen.

Lieben Dank für Deine Hilfe...

[elmex]

Tja, die liebe Normalisierung

Oder anders gesagt, was dem Datenbankdesigner seine Freud ist dem Applikationsprogrammierer sein Leid

Ich frage da immer zuerst, was passiert öfter, Anpassungen der Werte in der Datenbank oder Abfragen aus den Datenbanken und versuche dann den passenden Kompromiss zwischen Normalisierung und Performance zu bilden.

Wenn man unbedingt beides geniessen muss, dann gibt es ja noch die Views.

PS. Letzte Antwort - so würde ich es auch aufbauen. Außer bei vielen Abfragen, dann doch lieber die Joins vermeiden und chronologisch oder nach Änderungen Views erzeugen.

[xoni]

Tja, die liebe Normalisierung

ehe, ja da bin ich schon ein paar Mal drüber
gestolpert. Toll ist es, wenn typische n:m Beziehungen
als VARCHAR Kommasepariert in einem Feld
abgelegt werden....

Dann geht das gefrickel los.

[elmex]

Diese VARCHAR Felder kenne ich auch

Aber so joins haben auch ihre Tücken, schlechte Indizies auf den Tabellen, viele Einträge und bisschen Traffick, schon raucht mal schnell die Datenbank.

Ist krass, was man da in der Praxis manchmal an "lebendigen" Systemen vorfindet.

Das Gegenteil von den erwähnten Kommalisten im Varchar sind so kaputt normierte Daten, dass man über ein dutzen Tabellen joinen muss oder die Subqueries mehrfach verschachteln darf. Da will man dann plötzlich bei 10 gleichzeitigen Nutzern auf der Datenbank einen Loadbalancer