Struktur: Produktkategorien erweitern

[maddhin]

Um deine evtl. entstandene Enttäuschung über unseren Ausstieg
etwas zu mildern, hier noch ein paar Gründe für mich.

Lieber Ekkehard und auch Christian,

sorry für die Funkstille, diese hat eigentlich nichts mit Euch zu tun sondern damit, dass ich Sa/So mal den PC ausgelassen habe und heute noch nicht dazugekommen bin zu antworten

Enttäuschung: ja, aber nur ein bisschen:) Es wäre ja ziemlich vermessen zu erwarten, dass Ihr MEINE DB entwickelt! Ich bin für die Tipps und Kritik sehr dankbar. Das hilft mir beim Verständnis sehr. Insofern: no bad feelings!

a) deine Fragen zu theoretisch und zu stark abstrahiert sind
b) dein Projekt sich in einer stürmischen Entwicklungs-Phase befindet
c) noch nicht ganz klar ist, was du eigentlich erreichen möchtest.

Die ganze Diskussion ist für die eigentliche Frage hier etwas ausgeartet. Eigentlich hatte ich mir Mühe gegeben dass möglichst konkret darzustellen und wollte eigentlich nur wissen, ob ich wie in Beitrag #1 bzw. #8 dargestellt, die Cat3 einbauen kann Dazu sind wir irgendwie nicht gekommen LOL

Meine Idee ist/war konkrete Teile bzw. Probleme der DB hier zur Diskussion zu stellen. Das Gesamtprojekt anzugucken ist ja (siehe unsere Diskussion oben) zu kompliziert und kostet Euch zu viel Zeit. Aber eben gerade auf DB-Strukturebene finde ich Input von Profis wichtig - siehe meine vergessene m:n Corp-Product Tabelle.

Insofern: lieben Dank für Euren Input, ich schätze dies sehr!

Ganz konkret: was haltet Ihr von der Struktur in Beitrag #8? Machbar oder braucht man die weitere Hilfstabelle (siehe ursprünglicher Beitrag)? Meiner Meinung nach habe ich ich quasi nur eine Cat3 angehängt. Ob man die beiden Hilfstabellen (m:n Produkt-Cat2 und Cat2-Cat3) aber so zusammenmachen kann, weiß ich nicht. Da Cat3 für mich nur eine Zusatzinfo ist, sollte das eigentlich so passen.

Gruß und Dank!
Martin

[Beaker s.a.]

Hallo Martin,
Man kann es ja nicht lassen 
Ich habe mir das DM in #8 noch mal angeschaut. Wie selbst bemerkt
hast du da keine Abhängigkeit von Cat3 zu Cat2.
Vorschlag:
- lösche die Beziehung zwischen "Products_Cat3_Product" und "Cat3_Product"
(Key "ID_Cat3_Product")
- lösche den FK "ID_Cat3_Product"
- füge in "Cat3_Product" einen FK zu "Products_Cat3_Product" *) ein und erstelle
darüber die Beziehung der beiden Tabellen.
Nun hängt die Cat3 1:n an der n:m und du hast Zugriff auf die Cat2.
(siehe Anlage)
Ob das der Weisheit letzter Schluss ist, kann ich nicht sagen. Von mir bereits
erkannter Nachteil, du kannst eine Cat3 nur zuweisen, wenn es schon eine Cat2-
Zuweisung gibt, und auch nur eine.

gruss ekkehard

*) im Anhang zu Products_Cat2_Product geändert, ist irgendwie logischer
jetzt angefügt

[maddhin]

puh, dass das so kompliziert ist, konnte ich mir nicht vorstellen. Sorry.

Ich habe nochmal intensiv nachgedacht und warum das Rad neu erfinden?

Sie dürfen in diesem Board keine Dateianhänge sehen.
Ich habe jetzt 3 Kategorien wie "üblich" (glaube ich jedenfalls) hierarchisch definiert und jetzt jeweils eine m:n Tabelle zur Festlegung von Cat2 und Cat3  gemacht. Damit kann man Cat2 wie bisher festlegen und auch mehrere Cat2 pro Produkt festlegen (falls dies irgendwie logisch Sinn machen sollte). Analog dann Cat3.

Bei dieser Konstruktion muss man etwas aufpassen, damit zum Beispiel nicht nur Cat3 definiert wird und Cat2 frei bleibt, aber dies sollte über Formulare (z.B. Cat3 Dropdown abhängig von Cat2 Dropdown).

Meiner Meinung nach kann man mit dieser Struktur bei Bedarf Cat3 zuweisen und alles ist weiterhin logisch verbunden.

Ggf. kann man die beiden Product_Cat2_Product und Product_Cat3_Product Tabellen auch zusammenfassen und Cat2 als notwendige Eingabe definieren, dann hätte man sichergestellt, dass eine Cat3 immer zusammen mit Cat2 geschrieben wird.

Die Lösung von Ekkehard ist grundsätzlich auch gut, dies habe ich als Option 2 im Bild eingefügt. Aber hier hat mir die hierarchische Zuweisung der Cat3 zu Cat2 gefehlt.

Ich hoffe das macht jetzt Sinn 

[maddhin]

Hallo! 

Ohne, dass ich eine Antwort erwarte, will ich trotzdem hier meine "Lösung" posten, falls irgendwann mal jemand diesen Thread liest und ähnliche Probleme hat.

Ich habe das Ganze jetzt mal komplett neu aufgebaut. Ich glaube die bisherige Diskussion war irreführend in dem Sinne, als dass hier zu viele "Altlasten" beachtet wurden anstatt auf einem leeren Blatt anzufangen.

Ich habe das jetzt mit self-join und zwei m:n-Hilfstabellen gebaut:
Sie dürfen in diesem Board keine Dateianhänge sehen.

Das ganze Design soll folgendes können/bezwecken:

• Firmen mehrere Kategorien vergeben und per Kategorie auch einen (oder mehrere) Firmentyp(en) vergeben. Hintergrund: In der Kategorie "Saft-Fabrik-Equipment" kann die Firma "Hersteller" sein und in der Kategorie "Rohmaterialien für die Saft-Fabrik" zum Beispiel "Händler". Da ich für Firmen oft 2 Kategorien und oft auch 2 Firmentypen vergebe, gibt es in meiner aktuellen Struktur dann quasi 4 Einträge weil Access jeder Kategorie dann beide Firmentypen und vv. zuweist. Das ist datenbank-technisch nicht gut und ist auch eher kontraproduktiv, weil man nicht genau wissen kann, für welche Produkte die Firma nun was ist. Theoretisch könnte man nun mit der neuen Struktur über alle Kategorie- bzw. Listen-Ebenen einzeln definieren, was die Firma in dieser Liste ist. Praktisch möchte ich dies aber nur auf höchster Ebene.
• Kategorien flexibel erstellen und die Hierarchie bei Bedarf erweitern. Hintergrund: wie lange diskutiert, will ich in der aktuellen DB eine weitere Kategorie einbauen. Bei meiner Suche nach einer Lösung bin ich immer wieder über self-joins gestolpert und habe daher einen self-join Tabelle erstellt, die meiner Meinung nach gut die Problematik abdeckt.
  
• Produkte in mehrere Kategorien einordnen können.

Ich habe ein paar Tage mit der neuen Listen-Struktur gespielt und denke, das funktioniert soweit sehr gut für mich. Was ich noch rausfinden muss, ist, wie man Hierarchie-Ebenen in der jeweiligen Liste gut ansprechen kann. Z.B. um ein Listen- oder Dropdownfeld oder Queries nur mit Werten einer bestimmten Unterkategorie zu füllen. Das Handling über die ID_Cat(_parent)s z.B. mit DLOOKUP ist weniger intuitiv als die Cat1/2 Tabellen davor haha Wieder was zum Lernen...

Liebe Grüße
Martin

[ebs17]

Die jetzige Struktur sieht verständlich und brauchbar aus.

Was ich noch rausfinden muss ...

Datenmodell ist nicht alles, es setzt "nur" Grundlagen. Anschließen würde sich eine entsprechende Abfragetechnik, und jene kann mehr erfordern als ein schlichtes Zusammenklicken über eine GUI, die einige Standardfälle anbietet.

Mit Hierarchien hatte ich mich hier kurz auseinandergesetzt: Löschabfrage: Löschen von DS ohne Zugehörigkeiten in selbiger Tabelle
Vielleicht findest Du da einige verwertbare Punkte.

Demo dazu siehe Anlage.

Ansonsten ist das Einarbeiten in Abfragetechnik auch ein Lernprozess. Konkrete Fälle könnte man auch konkret besprechen.

[maddhin]

Lieben Dank, Eberhard!

Ja, das Arbeiten mit der Struktur ist gerade für mich als Anfänger recht mühsam, aber mir ist es wichtig, eine richtige und solide Struktur-Basis zu haben. Den Rest muss ich mir erarbeiten.

Herzlichen Dank für den Hierarchiebaum! Ich glaube, dass kann ich sehr gut gebrauchen! Werde mal versuche das nachzubauen!

[ebs17]

Anbei eine Version, die auch gleich die Bezeichnungs-Klarnamen im Hierarchiebaum darstellt

[maddhin]

Anbei eine Version, die auch gleich die Bezeichnungs-Klarnamen im Hierarchiebaum darstellt

Cool, dass ist sehr hilfreich und funktioniert! Ich werde mich jetzt ranmachen, herauszufinden, wie ich die Hierarchien am Geschicktesten ansprechen kann für Navi, Dropdown, etc.


PS: In ModHelpHierarchy sind übrigens zwei kleine Typos: da ist noch tmpT_H and statt " & NameHelpTable & " und Bezeichung statt " & Name_Description & " (unter  ' Ebenendatensätze einfügen /    ' --- Textbausteine).

[ebs17]

Danke für die Hinweise, viel brauchbarer als solche wie "wo muss ich das hinkopieren".
Das Ganze ist noch in der Entstehung, vom Zusammensetzen und Eigentlich-Funktionieren hin zu einer möglichst einfachen aber variablen Anwendung, und offensichtlich noch nicht abgeschlossen.

Die mit der Prozedur erzeugte Tabelle ist eine temporäre Tabelle. Zum Umgang mit temporären Tabellen habe ich mich hier ausgelassen:
Grundlagen - SQL ist leicht (13) - Temporäre Tabellen

[maddhin]

Die mit der Prozedur erzeugte Tabelle ist eine temporäre Tabelle. Zum Umgang mit temporären Tabellen habe ich mich hier ausgelassen:
Grundlagen - SQL ist leicht (13) - Temporäre Tabellen

lieben Dank, werde ich lesen!

Und noch eine echt dumme Frage, an der ich im Moment verzweifle: wie kann ich das if statement etc richtig schreiben, wenn ID_Parent leer ist?

Code [Auswählen] Erweitern

Private Sub ID_Cat_Parent_DblClick(Cancel As Integer)
'going up the category tree
Dim task As String
Dim strCat As String

If Me.ID_Cat_Parent = "" Then
task = "SELECT * FROM tblCategories WHERE ([ID_Cat_parent] ="")"

Else
strCat = DLookup("id_cat_parent", "tblcategories", "id_cat = " & Me.ID_Cat_Parent)
End If

task = "SELECT * FROM tblCategories WHERE ([ID_Cat_parent] = " & strCat & ")"
   
    Me.Form.RecordSource = task
    Me.Form.Requery

End Sub

Ich habe alle isNull, is Null, = "", = 0, mit und ohne .value durchprobiert. Irgendwie bekomme fehlt mir hier noch eine Variante von "ist leer"

[maddhin]

sorry, vergiss die dumme Frage, mein Problem ist eher in der Logik (glaube ich). 

[ebs17]

Code [Auswählen] Erweitern

' VBA: Variablen, Steuerelemente
If IsNull(Me.ID_Cat_Parent) ...

' SQL
WHERE FieldX Is Null

[maddhin]

Code [Auswählen] Erweitern

If IsNull(DLookup("id_cat_parent", "tblcategories", "id_cat = " & Me.ID_Cat_Parent)) = True Then
task = "SELECT * FROM tblCategories WHERE ([ID_Cat_parent] is null)"
Else
strCat = DLookup("id_cat_parent", "tblcategories", "id_cat = " & Me.ID_Cat_Parent)
task = "SELECT * FROM tblCategories WHERE ([ID_Cat_parent] = " & strCat & ")"
End IfDlookup war mein Problem.

Jetzt geht immerhin diese zusammengeschusterte Navi. Werde über die nächsten Tage mit Deiner Tabelle arbeiten und sehen,  wie das dann funktioniert

Danke!