Fehlermeldung beim Abfangen von Fehler 3022

[MzKlMu]

Hallo,
zu den Feldnamen zitiere ich mich aus einem Thema des TE vom Februar 2024:

Die Feldnamen die Du da gemacht hast sind gruselig. Du als Entwickler weist das natürlich. Aber eine Fremder tut sich da schwer mit. Und wenn Du 4 Wochen an der DB nichts gemacht hast, weist Du das auch nicht mehr.

Auch bei "Ref" oder "_F", wie es Klaus meistens macht - meine Meinung nach wie vor: Man macht sich das Leben nur schwerer.

Es geht mir dabei ja nur um die Anfänger, wie ich bereits mehrfach schon schrieb.
Hier im Forum gab es erst vor kurzem ein Thema bei dem PS und FS verwechselt wurden. Bei Verknüpfen von/nach PS/FS verwechselt und bei Kombis zur Auswahl auch.
Erst das Anfügen eines _F hat die Sache sehr schnell gekärt.
Muss mal schauen, ob ich das Thema noch finde.
Ich möchte keine erneute Diskussion darüber, sondern nur noch mal meine Gründe schildern.

[Bitsqueezer]

Hallo Klaus,

alles gut. Jeder hat so seine Meinungen und Methoden. Ich habe nie gesagt, daß Deine falsch oder völlig daneben ist... Meine ist auch nichts für Jeden.

Gruß

Christian

[KonradR]

Hallo Christian,

danke für deine sehr ausführliche Antwort.

Die Nährwerte passen hier gar nicht.

Danke. Das nächste mal prüfe ich besser
. Ich würde in der Tabelle "tblZutaten" auch die Gewichte weglassen, denn die sind ja schon in der Tabelle "tblProdukte" enthalten.

In die Produkttabelle gehören auch keine Gewichte.

Hier soll es darum gehen, dass ein Esslöffel Rama z.B. 10 Gramm und ein Esslöffel Erdnussbutter von Marke XYZ 8 Gramm wiegt. Das ist wichtig, wenn ich ein Rezept als Zutat für ein anderes Rezept haben und die Nährwerte berechnen will. Dann brauche ich immer das Zugabegewicht vom Produkt und dessen Nährwert pro 100 Gramm, damit ich die tatsächlich zugeführte Nährwertmenge berechnen kann.

Nun kannst Du zu jedem Produkt beliebig viele Nährwertarten erfassen und eingeben, was nicht vorliegt, wird auch nicht eingegeben.

In meiner bisherigen Datenbank, gab es viel Probleme mit Feldern, die noch NULL sind. Das fällt damit weg. Sehr hilfreich.

Eine Standard-Einheit wird in den Stammdaten der NährwertArt als EinheitID hinterlegt

Mir ist nicht ganz klar, was du mit Stammdaten meinst. Meinst du die Felder oder meinst du die Eigenschaft "Standardwert" in den Eigenschaften eines Feldes oder meinst du etwas Anderes?

In die Produkttabelle gehören auch keine Gewichte. Das wird ja in der Zuordnung der Verpackungseinheit geregelt.

Das kann sein, aber wie sonst soll ich die Gewichte für die einzelnen Rezepteinheiten den Produkten zuordnen? Wenn ich die Nährwertmenge für das gesamte Rezept bestimmen will, dann muss ich wissen, wieviel z.B. ein EL von Rama oder Erdnussbutter wiegt, um ihn dann mit der durch 100 geteilten Nährwertangabe für den entsprechendn Nährwert multiplizieren zu können. Das mit allen Zutaten für das Rezept für alle Nährwerte, ergibt die gesamte Nährwertmenge für das Rezept.

Für eine Rezepttabelle würde ich es an die ProduktID anhängen, da kommt es nicht auf zu kleine Details an und der Eingabeaufwand ist dann extrem viel geringer.

Das würde ich auch so machen. Das reicht mir vollkommen aus.

Bei der RezepteZuZutaten-m:n würde ich keine Einheit verlinken.

Alles klar. Aber  wenn ich ein Rezept als Zutat verwenden will. Z.B. Mehl aus Leinsamen, Sonnenblumenkernen und Mandeln, dann muss ich wissen, was ein EL davon wiegt und dafür benötige ich das Gewicht für einen EL für dieses Rezept

Zeit getrennt zu erfassen - naja, kann man machen, wenn man errechnen will, wie lange die Herstellung benötigt.

Ja, absolut. Um zu filtern, welches Rezept unter 30 oder 15 oder irgendeiner anderen Zeitvorgabe für die Zubereitung benötigt, wenn ich nicht so viel Zeit habe.

Arbeitsschritte würde ich allerdings 1:n definieren. Ich denke, es gibt nur wenige Rezepte, die die gleichen Arbeitsschritte wiederverwenden.

Z.B. ,,Zwiebeln (xyz) hacken" oder dito mit ,,schneiden" oder ,,dünsten".

Man könnte sich hier überlegen, eine "Makrotabelle" zu erzeugen, um Basistexte zu hinterlegen, von denen man einen auswählen und in die Arbeitsschritte übernehmen zu können, dort aber noch anpassen zu können.

Das wäre dann wahrscheinlich mit VBA zu lösen?

Die Tabelle Produkte würde ich hier vor allem an die ZutatID binden (also mit hinein). Denn ein Produkt "Motoröl" wird sicher nie an eine Zutat "Butter" gebunden werden.

Ich bin mir nicht ganz sicher, ob ich das richtig verstanden habe. Ich habe das mal so gelöst, wie im Bild dargestellt.

Bei der Eingabe vereinfacht es sich dann auch: Wenn man Zutaten verwalten will, hat man ein Endlosformular mit der Zutatentabelle (1 Formular = 1 Tabelle), darin ein Unterformular, auf die Produkte-Tabelle als Endlosformular (wieder 1 Formular = 1 Tabelle), hier kann man dann auch gleich neue Produkte erfassen, die dann automatisch zu genau dieser Zutat gehören.

Du meinst wahrscheinlich ein übergeordnetes Formular mit einem Unterformular für die Tabelle ,,tblZutaten" und auf dem übergeordneten Formular ein weiteres Unterformular für die Tabelle ,,tblProdukte". Denn meines Wissens, kann ich in ein Endlosformular kein Unterformular einfügen.

Meinst du in der Tabelle ,,tblZutaten"? Da ist keine Einheit hinterlegt.

Ich empfehle auch, die Namensgebung zu überdenken.

Ja, das ist nicht ideal. Bei dem Präfix mit den vorangestellten 5 Buchstaben der die Tabelle beschreibt werde ich bleiben, damit, wenn ich später mit Abfragen in der DB arbeite auch immer weis, welches Feld zu welcher Tabelle gehört. Aus dem Bildschirmfoto vom Beziehungsfenster ist das ersichtlich.
Sie dürfen in diesem Board keine Dateianhänge sehen.

[Bitsqueezer]

Hallo Konrad,

Hier soll es darum gehen, dass ein Esslöffel Rama z.B. 10 Gramm und ein Esslöffel Erdnussbutter von Marke XYZ 8 Gramm wiegt. Das ist wichtig, wenn ich ein Rezept als Zutat für ein anderes Rezept haben und die Nährwerte berechnen will. Dann brauche ich immer das Zugabegewicht vom Produkt und dessen Nährwert pro 100 Gramm, damit ich die tatsächlich zugeführte Nährwertmenge berechnen kann.

Ja, das ist OK, wenn man unbedingt "Esslöffel" als Einheit speichern möchte. Da Du ja aber ohnehin ausrechnest, wieviel Gramm das ist für welche Zutat, würde ich das gleich als Gewicht speichern und Bezeichnungen wie "Esslöffel" oder "Prise" usw. im Freitext der Rezeptbeschreibung (bei den Arbeitsschritten) belassen, da diese keinerlei Informationswert für Gewichts- oder Nährwertberechnungen haben. Zumal "ein Esslöffel" oder "eine Prise" für unterschiedliche Menschen auch unterschiedliche Mengen bedeuten können.

Zitat von: Bitsqueezer am Januar 31, 2025, 12:57:01
    Eine Standard-Einheit wird in den Stammdaten der NährwertArt als EinheitID hinterlegt

Mir ist nicht ganz klar, was du mit Stammdaten meinst.

Die Tabelle "NährwertArt" ist eine Stammdatentabelle. Stammdaten sind solche, die man ständig braucht, aber die selbst so gut wie nie verändert werden. Wie etwa "Kalorien" - weder der Name wird sich ändern noch seine Bedeutung. Stammdatentabellen nennt man meistens auch "Lookup-Tabellen". Sie bestehen meistens aus nur wenigen Feldern, meistens ID, Name und Beschreibung (aber können natürlich auch viel mehr Felder haben).

Zitat von: Bitsqueezer am Januar 31, 2025, 12:57:01
    In die Produkttabelle gehören auch keine Gewichte. Das wird ja in der Zuordnung der Verpackungseinheit geregelt.

Das kann sein, aber wie sonst soll ich die Gewichte für die einzelnen Rezepteinheiten den Produkten zuordnen? Wenn ich die Nährwertmenge für das gesamte Rezept bestimmen will, dann muss ich wissen, wieviel z.B. ein EL von Rama oder Erdnussbutter wiegt, um ihn dann mit der durch 100 geteilten Nährwertangabe für den entsprechendn Nährwert multiplizieren zu können. Das mit allen Zutaten für das Rezept für alle Nährwerte, ergibt die gesamte Nährwertmenge für das Rezept.

Ein gutes Datenbankdesign zeichnet sich dadurch aus, daß eine Tabelle nur die absolut minimal notwendigsten Informationen zu einem Objekt beschreibt. Ein Produkt hat einen Produktnamen. Ein Produkt hat einen Hersteller. Wenn ich also "Schrauben" speichere, dann gibt es die gleiche Schraube in x unterschiedlichen Verpackungen und demnach Gewichten. Sobald ich also mehrere Daten der gleichen Art zu einem Item habe, dann gehören sie in eine eigene Tabelle. Also eine Liste von Verpackungen und -gewichten, die alle zum gleichen Produkt gehören. Oder in Datenbanksprache: 1:n. So einfach ist Datenbankdesign. Und wenn die exakt gleiche Schraube von zwei Herstellern hergestellt wird, dann ist die Beziehung zwischen Hersteller und Produkt auch keine 1:n-Beziehung mehr, sondern eine m:n-Beziehung. Ein Hersteller stellt m Produkte her und ein Produkt wird von n Herstellern hergestellt. Eine m:n ist auch immer wie eine 1:n handhabbar, denn wenn man auf einen Hersteller filtert, gibt es dazu n Produkte nur dieses Herstellers - und umgekehrt.

Das Datenbankdesign betrachtet dabei nicht, was Du später damit machen willst. Es gilt die Regel, Redundanzen zu vermeiden und sich in einer Tabelle auf ein konkretes Objekt zu beschränken, das mit vielen Attributen beschrieben werden kann - aber immer bezogen auf den konkreten Zweck, unabhängig von jeder anderen Tabelle.

Wenn man also eine Tabelle "Produkt" erstellt, interessiert es im Datenbankdesign nicht, ob Du ein ERP-System erstellst, in dem Du Produkte zum Bau verwalten willst, ob Du später eine Bestell- und Rechnungsverwaltung damit machen willst oder ob Du Produkte für Rezepte speicherst. In allen Fällen ist "Produkt" eine von ihrer Umgebung völlig unabhängige Tabelle, die für sich alleine so unabhängig designt wird, daß Du sie mit Copy/Paste in ein ERP-System oder eine Bestelldatenbank einfügen kannst und sofort verwenden kannst. Hier und da mal Anpassungen für bestimmte Regeln, aber die Idee des Datenbankdesigns bleibt immer gleich: Die kleinstmögliche Menge an Informationen, die exakt zu diesem einen Objekt gehören, hier das Produkt. "Objekt" meint dabei natürlich nicht automatisch ein physisches Objekt wie ein Produkt, sondern i.d.R. ein logisches Objekt, ein Gedankenkonstrukt. Diese Konzentration auf die konkreten Attribute eines Objektes führt genau dazu, daß man keine Redundanzen erzeugt (bzw. so wenig wie möglich, nicht immer vermeidbar und "sture Normalisierung" ist auch nicht in allen Fällen möglich oder sinnvoll).

Also zurück zur Frage: Das Gewicht ist einerseits etwas, was zum Produkt gehört - aber nicht zur Produktbeschreibung. Morgen wirft der Hersteller alles über den Haufen und hat statt 10,20,50 auf einmal 20,60,100 Gramm-Verpackungen. Die Verpackungen ändern aber nicht das geringste am Produkt: Der Name ändert sich nicht, es gibt keine Gewichtsangabe in einem Produkt, die Produktbeschreibung ändert sich nicht usw. Die Produkttabelle und ihre Daten bleiben von der Änderung komplett unbetroffen. Geändert werden nur die Verpackungsinformationen. Dabei würden im Beispiel die Datensätze 10,20,50 mit einem Gültigkeitsdatum (GültigBis) versehen werden, damit sie nicht gelöscht werden - denn die alten Datensätze werden vielleicht noch irgendwo verwendet und sollen weiterhin anzeigen, was einmal gespeichert gewesen ist und bei Aufruf zeigt "gültig bis" im Formular, daß man hier Anpassungen vornehmen muß, weil es diese Verpackungsgröße nicht mehr gibt (alternativ automatisiert man das und wenn sie nicht mehr verwendet werden, kann man sie dann löschen, außer man möchte noch nachsehen können, daß es sie mal gab).

Stammdaten sind hier also die Liste der Produkte, weil sie sich nur wenig ändern. Bewegungsdaten sind dann die Verpackungen mit ihren Gewichten. Generell ist die Grenze der Bezeichnungen aber fließend, denn man kann natürlich auch sagen, einmal eingegeben, nie mehr verändert, dann sind es eher Stammdaten und umgekehrt.

Und um auf die Rezepte zurückzukommen: Das Gewicht definiert einzig und allein die Rezeptdetails-Tabelle. Du hast die übergeordnete Rezepte-Tabelle, die beschreibt den Namen des Rezeptes und vielleicht eine Kategorie wie "vegan" usw. sowie einen Freitext - was auch immer. Viel mehr wird es nicht.
Du hast eine RezeptDetails-Tabelle, was nichts anderes als eine m:n-Tabelle ist, in der Du Informationen zum Rezept zusammenführst. Also welche Zutat wird mit welchem Gewicht benötigt? 5g Butter, also über die ausgewählte Zutat erhältst Du "Butter", die Zutat regelt die EinheitsID, also "g", und wenn Du die Produkte mit einem ZutatID-Feld versehen hast, dann gilt die ZutatID quasi als Kategorie für das Produkt. Was umgekehrt bei der Rezepteingabe auch gleich möglich macht, die bekannten (also der Datenbank bekannten) Produkte einer Zutat aufzuzeigen sowie deren Verpackungsgrößen (und Läden, die wir hier noch der Einfachheit halber weggelassen haben).

Wenn Du "1 Esslöffel" erfassen willst, dann hat ein Esslöffel Butter ein anderes Gewicht als 1 Esslöffel Mehl. Also ist die verbindende Einheit z.B. g oder ml (bei Flüssigkeiten). Warum soll ich das bei jedem Rezeptdetail erst eingeben? Mehl hat immer "g" und Milch hat immer "ml". Also gehört die Einheit fest einer Zutat zugeordnet, dann kann man sie im Frontend automatisch und unveränderlich anzeigen, ohne Bestandteil der RezeptDetails-Tabelle zu sein - und ohne sie eingeben zu müssen. Und wenn man dem User helfen möchte, dann definiert man eine Hilfstabelle, in der z.B. Größenordnungen wie "Prise" und "Esslöffel" und "gehäufter Teelöffen" und ähnliche solcher frei interpretierbarer "Mengen" über eine weitere m:n-Tabelle zum Produkt jeweils ein Gewicht zugeordnet wird, als "g" oder "ml" oder was auch immer. Die Einheit definiert hier wiederum die Zutat, das Produkt ist unabhängig von seinen Verpackungen, und das Gewicht wird in der m:n-Tabelle definiert. Also ID_Zutat,ID_Produkt, ID_Mengendefinition, Mengenwert (nicht "Gewicht", kann ja z.B. ml oder g sein oder was auch immer). In der Mengendefinitionstabelle stehen die o.g. Größeneinheiten als Stammdaten, also "Esslöffel" oder "gehäufter Teelöffel" oder "Prise". Die werden sich danach nie mehr ändern.

Diese Tabellen kann man dann im Frontend anbieten, wenn man das Rezept definieren will, um Größeneinheit auswählen zu können und Menge davon, also "Esslöffel" und "1". Die brauchen nicht gespeichert zu werden, denn sie werden im Frontend dann anhand der m:n-Tabelle in Gewicht umgerechnet und das Gewicht (besser: Mengenwert) wird in den Rezeptdetails gespeichert. Sie sind dann quasi nur ein "Textbaustein".
Wenn man später die Auswahl wieder anzeigen möchte, kann man die Auswahl "Esslöffel" und "1" natürlich zusätzlich speichern, aber nötig wäre es nicht. Entscheidend ist der Mengenwert, besonders für die Nährwertberechnung.

Alles klar. Aber  wenn ich ein Rezept als Zutat verwenden will. Z.B. Mehl aus Leinsamen, Sonnenblumenkernen und Mandeln, dann muss ich wissen, was ein EL davon wiegt und dafür benötige ich das Gewicht für einen EL für dieses Rezept

Das wäre damit ja bereits beschrieben.

Zitat von: Bitsqueezer am Januar 31, 2025, 12:57:01
    Arbeitsschritte würde ich allerdings 1:n definieren. Ich denke, es gibt nur wenige Rezepte, die die gleichen Arbeitsschritte wiederverwenden.

Z.B. "Zwiebeln (xyz) hacken" oder dito mit "schneiden" oder "dünsten".

    Zitat von: Bitsqueezer am Januar 31, 2025, 12:57:01
    Man könnte sich hier überlegen, eine "Makrotabelle" zu erzeugen, um Basistexte zu hinterlegen, von denen man einen auswählen und in die Arbeitsschritte übernehmen zu können, dort aber noch anpassen zu können.

Das wäre dann wahrscheinlich mit VBA zu lösen?

Wie in dem Beispiel mit den Esslöffeln: Man definiert sich solche Textbausteine, die dann z.B. einen Eintrag "Zwiebel hacken" enthalten, und diese kann man dann in ein Arbeitsschritt-Freitext-Feld (per VBA) einfügen, also etwa an das Ende des bestehenden Textes anfügen, so daß der Benutzer es anpassen kann. Also etwa zu "Zwiebel besonders fein hacken". Du willst ganz sicher nicht JEDE Sonderformulierung als Lookup-Tabelle definieren, dann dauert auch die Suche nach dem richtigen Eintrag ewig lang. Der Arbeitsschritt an sich ist auch nicht sonderlich wichtig für Auswertungen. Daher ist hier Freitext genau richtig.
Nebenbei würde ich hier auch die Zeit für einen Arbeitsschritt unterbringen. Damit entfällt die Zeitangabe im Rezept selbst, das Rezept kann dann durch Aufsummieren der Arbeitsschritt-Zeiten errechnet werden - und Du kannst die Arbeitsschritte, einmal mit Zeit definiert, auch für andere Rezepte wiederverwenden und mußt dann nicht erneut überlegen, wie lange der Schritt kostet. Die Zwiebel zu hacken, wird in jedem anderen Rezept sicherlich nicht unterschiedlich viel Zeit kosten. Wieder eine Eingabe gespart, wieder mehr Details in der Datenbank. Zum Beispiel abzufragen, welche Rezepte besonders viel Zeit für passive Tätigkeiten wie backen brauchen und welche besonders viel Zeit für aktive wie "Zwiebel hacken". Was man mit einer Gesamtzeit nicht ermitteln kann.

Wieder das Prinzip, zusammengehörende Daten in eine Tabelle. Der Arbeitsschritt kostet Zeit. Das Rezept mit der Zutatenliste kostet keine Zeit. Die Zutatenliste soll die Zutaten listen (ach.. ) und die Arbeitsschritte sind es, die Zeit kosten.

Zitat von: Bitsqueezer am Januar 31, 2025, 12:57:01
    Die Tabelle Produkte würde ich hier vor allem an die ZutatID binden (also mit hinein). Denn ein Produkt "Motoröl" wird sicher nie an eine Zutat "Butter" gebunden werden.

Ich bin mir nicht ganz sicher, ob ich das richtig verstanden habe. Ich habe das mal so gelöst, wie im Bild dargestellt.

Habe ich ja hier bereits beschrieben: In die Tabelle ProduktID gehört die ZutatID, da es wie eine Kategorie zu sehen ist. Produkt "Landliebe Butter" und "Kerrygold Butter" ist jeweils Kategorie/Zutat "Butter".

Zitat von: Bitsqueezer am Januar 31, 2025, 12:57:01
    Bei der Eingabe vereinfacht es sich dann auch: Wenn man Zutaten verwalten will, hat man ein Endlosformular mit der Zutatentabelle (1 Formular = 1 Tabelle), darin ein Unterformular, auf die Produkte-Tabelle als Endlosformular (wieder 1 Formular = 1 Tabelle), hier kann man dann auch gleich neue Produkte erfassen, die dann automatisch zu genau dieser Zutat gehören.

Du meinst wahrscheinlich ein übergeordnetes Formular mit einem Unterformular für die Tabelle ,,tblZutaten" und auf dem übergeordneten Formular ein weiteres Unterformular für die Tabelle ,,tblProdukte". Denn meines Wissens, kann ich in ein Endlosformular kein Unterformular einfügen.

Ja, das ist leider ein uraltes Problem der Falschmeldung von Access. Beim Versuch bekommst Du immer die (falsche) Information, daß man kein UFo in ein Endlosformular einbauen kann, was aber Unsinn ist. Du kannst keins im Detailbereich einfügen, aber sehr wohl im Kopf-/Fußbereich eines Formulares. Wenn Du es versuchst, wird Access Dein Endlosformular nach der Meldung auf Einzelformular umstellen. Einfach ignorieren und wieder auf Endlosformular umstellen - fertig. Schon hast Du im Detailbereich die Endlosliste und bei Auswahl einer Zeile im z.B. Fußbereich die zugehörigen Daten. Das kannst Du auch verschachteln, abhängig von der Bildschirmgröße. Also das UFo kann seinerseits einen Fußbereich haben mit einem weiteren UFo. Funktioniert problemlos. Man sollte es nur nicht übertreiben und vor allem kompakt designen, sonst wird aus dem "Endlosformular" ein Einzeiler...
Beispiel, wie sowas aussehen kann, in dem Beitrag hier in der Ausweis-Demodatenbank: https://www.access-o-mania.de/forum/index.php?msg=165961

Meinst du in der Tabelle "tblZutaten"? Da ist keine Einheit hinterlegt.

Ja, stimmt, die fehlt dort ja noch, wie nun hier ja ausführlich beschrieben.

Zitat von: Bitsqueezer am Januar 31, 2025, 12:57:01
    Ich empfehle auch, die Namensgebung zu überdenken.

Ja, das ist nicht ideal. Bei dem Präfix mit den vorangestellten 5 Buchstaben der die Tabelle beschreibt werde ich bleiben, damit, wenn ich später mit Abfragen in der DB arbeite auch immer weis, welches Feld zu welcher Tabelle gehört.

Das ist ja genau der Irrglaube. Sowohl in SQL und auch im Abfragedesigner sieht Du es IMMER genau:

Code [Auswählen] Erweitern

SELECT MeineTabelle.MeinFeld
FROM MeineTabelle
Es ist also klar, daß "MeinFeld" aus "MeineTabelle" kommt, oder nicht? Im Abfragedesigner steht der Tabellenname unter dem Feld.

Was Du machst ist:

Code [Auswählen] Erweitern

SELECT MeineTabelle.MeineTabelleMeinFeld
FROM MeineTabelle
Also welchen Mehrwert bietet Dir nun "MeineTabelleMeinFeld"? Keinen, es verlängert und verkompliziert nur den Feldnamen, ist grundsätzlich immer überflüssig.

Zum Datenmodell:
Laden UND Marke der m:n hinzuzufügen, ist wieder Redundanz. Die Beschreibung der Verpackungseinheit zum Produkt ist die Information, die in eine Tabelle gehört. Mit dem Laden fügst Du wieder überflüssige Redundanz ein, denn jetzt mußt Du für "Rewe", "Lidl", "Aldi" drei Datensätze mit den gleichen Informationen einfügen, nur mit unterschiedlichen Läden.

Produkt zu Verpackung ist die Information, die diese Tabelle beschreiben soll. Diese Tabelle hat eine eigene ID, und diese verlinkt man in einer weiteren m:n zu den Läden. Also PdouktZuVerpackungID zu LadenID. So kann man in drei Zeilen dieser weiteren m:n-Tabelle alle Läden erfassen, die genau dieses Produkt in genau dieser Verpackungsgröße anbieten. Ansonsten müßtest Du bei einer Auflistung aller Verpackungsgrößen eines Produktes immer alle Duplikate ausfiltern. Im gegenwärtigen Modell würdest Du drei Zeilen mit der gleichen Verpackungsgröße definieren, obwohl es immer die gleiche Verpackungsgröße ist. Was zusätzlich zu Eingabefehlern führen kann. Wenn ich also später vom Laden unabhängig die Verpackungsgrößen eines Produktes listen will, ergeben sich 3 Zeilen aus dieser Tabelle, wenn man den Laden wegläßt, hast Du drei gleiche Zeilen. Die müßte man dann mit GROUP BY oder DISTINCT erst wieder zu einer Zeile machen. Das ist eben Redundanz. Das Datenbankdesign hat grundsätzlich nichts mit den Formularen zu tun und dem Benutzerkomfort.

Redundanz hast Du prinzipiell auch in Deiner Nährwerttabelle, denn alle Felder hier sind wiederum Aufzählungsfelder. Du hast als Beispiel 2 Felder mit "Energie", zwei Felder mit "Fett".

Schau Dir mal eine einfache Nährwerttabelle an:
https://www.dge-medienservice.de/media/productattach/File-1560509394.pdf

Da ergibt sich bereits einen ganzen Haufen an Definitionen, die Du mit Deiner Tabelle so nie abdecken kannst. Die Darstellung dieser PDF ist bereits eine PivotDarstellung, und muß für den Datenbankdesigner in einzelne Tabellen aufgetrennt werden, wenn man diese sinnvoll verwalten will.
Im Allgemeinen ist die Einheit hier "g", aber ebenso "Mikrogramm" oder "kcal" oder "kcal/g". Es gibt Kategorien wie "Mineralstoffe", "Vitamine", "Energie", "Eiweiß", "Kolenhydrate", "NaCl", "Alkohol", "Fett", "Wasser", die wiederum Unterkategorien aufweisen. Diese werden je nach Produktkategorie wie "Fleisch/Fisch" und "Getränke" usw. unterschiedlich verwendet, was also, wenn man es korrekt handhaben will, einige zusätzliche Tabellen und Beziehungen braucht, um produktunabhängig Nährwerte zu verwalten. Dann kann man sich überlegen, ob man diese einer Zutat zuordnen will wie "Butter" (wie es auch die PDF macht), oder spezifischer den Herstellerangaben zu einem Produkt.

Da es halt doch sehr viele und sehr unterschiedliche Arten von Nährwertbetrachtung gibt, reicht Deine Tabelle hier nicht aus. Ein Getränk ist anders zu bewerten wie Butter. Entsprechend muß man die Art des Nährwertes auswählen können (wie "Energie: kcal" oder "Energie: kJ", was zwei Zeilen in der Tabelle sind), den Wert und die Einheit.
In Deiner Tabelle könntest Du z.B. keine Mineralstoffe und keine Vitamine verwalten.

Kleiner Tip am Rande: Vermeide Tabellennamen wie "tblKategorie" oder "tblArt" usw. Das sagt absolut nichts über den Inhalt aus und Kategorien gibt es, wie man sieht, an allen Ecken und Enden einer Datenbank. Es sollte immer im Namen zu sehen sein, zu was die Kategorie gehört.

Das war's erst mal wieder dazu.

Vergiß auf jeden Fall erst mal die Formularerstellung, solange das Datenmodell noch nicht vollständig und durchdacht ist. Darüber macht man sich erst zum Schluß Gedanken.

Ich denke, das Prinzip habe ich nun ausführlich beschrieben, Du solltest dann mal entsprechende Tutorials durchgehen, da ich hier keinen Datenbankdesignkurs geben kann.

Gruß

Christian

[KonradR]

Hallo Christian,

Danke für deine Mühe bis hierhin.

Ich denke, das Prinzip habe ich nun ausführlich beschrieben, Du solltest dann mal entsprechende Tutorials durchgehen, da ich hier keinen Datenbankdesignkurs geben kann.

Das werde ich erst mal machen und dann deine Tips durcharbeiten.