Juli 14, 2020, 21:29:00

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Kategorie-abhängige Eigenschaften/Felder

Begonnen von maddhin, Juni 30, 2020, 06:07:41

⏪ vorheriges - nächstes ⏩

maddhin

Hallo,

ich baue gerade eine Lieferanten, bzw. Firmendatenbank auf und gebe Firmen über n:m-Beziehung bzw. Hilfstabelle bestimmte Kategorien (ID_Cat1_Biz) wie z.B. "Hersteller" oder "Händler":

Sie dürfen in diesem Board keine Dateianhänge sehen.

Ich speichere die Werte in der Hilfstabelle (unter ID_Cat1_Biz) wobei eine Firma mehrere Kategorien haben kann/soll, weil zum Beispiel einige Hersteller auch Produkte anderer Firmen/Hersteller verkaufen.

Was ich möchte ist, dass ich je nach Kategorie der Firma noch weitere Informationen der Firma gespeichert werden können. D.h. wenn die Firma ein Hersteller ist, möchte ich noch Firmenzertifikate, nahegelegener Hafen, etc. zur Firma speichern oder wenn es ein Händler ist, Exporterfahrung, etc. Ich möchte bzw. muss dies später auch analog bei Produkten machen, die ja nach Produktkategorie sehr unterschiedliche Eigenschaften/Felder haben sollen.

Das Ganze soll dann später im Formular auch möglichst schick aussehen und automatisch die entsprechenden Felder anzeigen, je nach dem, welche Kategorie(n) man für Firma/Produkt auswählt.

Ich habe gerade angefangen mich mit Access zu beschäftigen und diese Fragestellung erscheint mir nicht trivial. Ich würde gerne eine ordentliche Lösung implementieren. Im Moment habe ich noch nicht den Überblick, wie man sowas am Besten machen könnte. Im Moment kann ich z.B. die Auswahl der Kategorien im Firmen-Stammdaten-Formular noch nicht mal richtig lösen, weil ich noch nicht weiß, wie man mehrere Kategorien dort auswählen kann und richtig speichern kann (in mehreren Zeilen). Das finde ich aber noch raus und sollte hier nicht das Hauptproblem sein.

Sicherlich könnte man manuell je Kategorie eine Tabelle mit Extra-Eigenschafen anlegen, aber ich weiß nicht, ob das richtig und praktikabel ist - und wie das dann am besten abgebaut ist damit man das dann später "verarbeiten" kann. Theoretisch könnte man ja auch alle Extra Eigenschaften in die Firmen-Tabelle (tbl_Company) machen und dann ggf. Felder basierend auf der Kategorie filtern? Aber beides erscheint mir nicht richtig.

Ich wäre über jeden Kommentar und Hilfe dankbar!


crystal

Hallo maddhin,
das Ganze scheint doch ziemlich kompliziert und ich möchte trotzdem meinen unbedarften Senf dazu geben.
Achtung: der Text meiner Antwort könnte etwas lang geraten sein...

Du scheinst aus der "Excel-Ecke" zu kommen, wo alles viel einfacher scheint... Der Wechsel von Excel zu Access ist leider oft sehr schwierig und wirft zunächst viele einfache Fragen auf - wieso geht das nicht in Access?

Prinzipiell müsstest du für die unterschiedlichen Firmen-Typen (eigentlich) jeweils eigene Tabellen anlegen, in denen die passenden Attribute gespeichert werden und diese Zusatz-Tabellen jeweils 1:1 mit der Haupt-Tabelle verknüpfen.
Also:
Firmen-Typ = Hersteller -> zusätzliche Attribute in Hersteller-Tabelle speichern
Firmen-Typ = Lieferant -> zusätzliche Attribute in einer Lieferanten-Tabelle speichern
Firmen-Typ = Beides -> zusätzliche Attribute in beiden Tabellen speichern

Wenn die Anzahl der Daten für die unterschiedlichen Typen überschaubar ist, könntest du diese Zusatz-Daten auch direkt in der Haupt-Tabelle speichern, was evtl. einfacher zu handeln ist.

Das klingt zunächst logisch und nachvollziehbar.
Aber wie bringe ich das an die Oberfläche, so dass der Nutzer es auch einfach eingeben und pflegen kann?

Mein Tipp wäre es hier, die verschiedenen Zusatz-Attribute optisch getrennt anzubringen, z. B. in einem Tab-Formular.
Gemeint ist:
Das Haupt-Formular ist als Tab-Formular gestaltet und enthält im Tab "Hauptdaten" allgemeine Informationen und in weiteren Tabs "Hersteller" und "Lieferant" entsprechende Felder.
Je nach Eingabe in einem Steuerelement (z. B. mittels Select-Box-Gruppe oder Radio-Button "Hersteller/Lieferant/beides" oder Kombobox) gibt man im Haupt-Tab an, um welchen Firmen-Typ es sich handelt und die zusätzlichen Tabs werden dann per VBA aktiv/passiv geschaltet.
Das könnte auch relativ einfach in Form-Current-Event ausgewertet werden, also wenn man sich durch eine Selektion der Haupt-Firmen bewegt (z. B. suche alle Firmen mit PLZ 20* oder sowas).

Ähnliches könnte man auch machen, indem du je nach Typ spezifische Unter-Formulare aktivierst, was aber schon dann schwierig wird, wenn eine Firma sowohl Lieferant als auch Hersteller ist. Da müsstest du die entsprechenden Unterformulare dann im Hauptformular z. B. per Button ("Lieferanten-Daten", "Hersteller-Daten", "Beides-Daten" geht dann natürlich nicht) auswählen/wechseln lassen...

Der Einsatz von Tabs wäre m. E. für den Nutzer eine plausible Möglichkeit. Wenn z. B. eine Firma kein Lieferant ist, ist der betreffende Tab ausgeblendet oder ausgegraut und nicht anwählbar. Erst wenn im Haupt-Bereich irgendwie als Typ auch "Lieferant" definiert wird, erscheint der betreffende Tab zur Eingabe der Lieferanten-spezifischen Daten. Dies macht aber nur dann Sinn, wenn die Zahl der Firmen-Typen überschaubar klein ist (was hier ja wohl der Fall ist). Auch könnten dann ALLE Daten in der Firmen-Tabelle gespeichert werden, ohne eine separate Tabelle für die Typen verwenden zu müssen. Unbenommen hiervon wären weitere Tabellen wie "Ansprechpartner": die wären aber eher Typ-unabhängig (und könnten als Endlos-Formular recht elegant in einem Tab "Ansprechpartner" untergebracht werden, ggf. weiter attributiert z. B. "AP für Allgemeines", "AP für Rechnungen", "AP für blabla").

Schwieriger könnte es bei den Produkten werden, denn hier könnte ich mir eine größere Varianz der Produkt-Typen vorstellen, die nicht mehr unbedingt in Tab-Formularen abbildbar wäre, allenfalls für "Haupt-Typen" mit jeweils spezifischen "Untertypen" in Endlos-Formularen (ähnlich attributiert wie oben bei den Ansprechpartnern), z. B.

Produkt-Haupttyp-->Untertyp-->Attribut-->Wert
----------------------------------------------------
Konserve-->Metall-->Verpackung-->Eisenblech verzinkt
Konserve-->Metall-->Verpackung-->Alu-Tube
Buch-->gebunden-->Heftung-->Fadenheftung
Buch-->geleimt-->Art-->Paperback
Ei-->roh-->Haltung-->Stall
Ei-->roh-->Haltung-->Freiland
Ei-->gekocht-->Haltung-->Freiland

Dein Ansatz, hier die Firmen-Typen in einer separaten Tabelle zu hinterlegen, ist einerseits lobenswert (Normalisierung), andererseits aber schwierig zu handeln, wenn es z. B. um die simple Darstellung an der Oberfläche geht. Du musst die Daten dieser Tabelle im "Kopf" der Firmendaten lesen und interpretieren, um dann z. B. Unterformulare oder Tabs an der Oberfläche aktiv/passiv zu schalten, je nach dem, um welchen Firmen-Typ es sich handelt. Auch könnte es schwierig werden, Daten per Abfrage zu suchen, weil du wegen der 1:n-Hilfstabelle (übrigens nicht n:m) und den anderen Zusatz-Tabellen (wieder 1:n oder 1:1) schwierige Konstrukte formulieren müsstest und am Ende nicht mehr recht weißt, wie du die Daten dann an der Oberfläche darstellen sollst oder kannst.

Denke immer so: du sucht nach genau einer Firma und wählst genau diese eine Firma aus - erst an der Oberfläche wird dann, also danach, entschieden, welche Daten zu dieser einen Firma angezeigt werden. (Access arbeitet primär immer mit einzelnen Datensätzen.)

Bei Firmen mit nur wenigen unterschiedlichen Typen (Lieferant/Hersteller/beides) ist es noch recht einfach, aber bei Produkten mit z. B. mehreren Dutzend verschiedenen Typen???? Hier ist es m. E. zunächst einmal erforderlich zu hinterfragen, welche stark unterschiedlichen Daten bei verschiedenen Produkt-Typen eigentlich zu erfassen und zu pflegen wären. Könnte man solche stark unterschiedlichen Daten z. B. in Gruppen zusammenfassen? Wie soll das an der Benutzer-Oberfläche kompakt und ergonomisch dargestellt werden (siehe Beispiel oben)?

Wenn deine Haupt-Tabelle nur wenige Typen "kennt", kannst du diese mit Tabs vermutlich noch elegant darstellen und bearbeiten. Gerät die Anzahl der möglichen Typen über eine gewisse Grenze (z. B. 5 oder 8 ), wird sowohl die Darstellung an der Oberfläche als auch die Suche nach "passenden" Datensätzen schnell sehr schwierig. Ich empfehle hier die Attributierung nach oben angegebenem Beispiel. Aber auch das ist schon schwierig zu implementieren, weil Access in Endlos-Formularen "so seine Eigenheiten/Macken hat" (z. B. weil sich irgendwelche Aktionen in einem einzelnen Datensatz eines Endlos-Formulars [eher ungewollt und unerwartet] plötzlich auf alle dargestellten Datensätze des Unterformulars auswirken [Beisiel: "textfeld.Farbe = Rot" bewirkt, das dieses textFeld in ALLEN angezeigten Datensätzen der Unterformulars rot wird - und eben nicht nur im aktuellen]; Access bietet leider keine Möglichkeit, solche Aktionen auf den genau EINEN angewählten Datensatz des Endlos-Unterformulars zu beschränken).

-----
Ich glaube, das reicht erstmal zum Nachdenken und zum Experimentieren.

Eine einfache Lösung für deine Wünsche und Vorstellungen gibt es in Access leider nicht. Alles ist mit viel Programmier-Aufwand verbunden, es sei denn du willst auch den Anwendern ein tiefes Verständnis von relationalen Datenbanken vermitteln, bevor sie mit deiner Anwendung arbeiten können.

Es sind eben (mindestens) zwei Paar Schuhe: ein Datenmodell mit Referenzen erstellen und das an der Benutzer-Oberfläche sinnvoll und einfach darstellen. Das ist mit Access ebenso schwierig wie mit anderen DB-Systemen...

Dieser lange Text soll dich zum Nachdenken über Konzepte bewegen und dich vor einer Erfahrung bewahren/schützen/warnen: (auch) in Access muss man alles selber machen und dauernd über das "was wäre wenn" nachdenken.

Nichts für ungut,

crystal
PS: Dein Fehler war - du hast geschrieben:
ZitatIch wäre über jeden Kommentar und Hilfe dankbar!

Wer Fehler in meinen Antworten findet, darf sie behalten, muss sie aber kommentieren. ;-)
Dies ist keineswegs arrogant gemeint, sondern soll nur unterstreichen, dass meine Antworten - natürlich - nicht immer fehlerfrei sind und sein können.
Devise: bitte immer erst selbst probieren!

maddhin

Juli 01, 2020, 07:31:18 #3 Letzte Bearbeitung: Juli 01, 2020, 08:53:43 von maddhin
Lieber Crystal,

ganz herzlichen Dank für Deine Antwort, über die ich mich sehr freue, denn genau so eine Antwort habe ich erwünscht! Auch wenn mir eine einfache und elegante Lösung lieber gewesen wäre  haha

Ich hatte hier eigentlich schon einen langen Text getippt, aber leider verloren, weil ich kurz unten auf mein Bild im Betrag geklickt habe  :'(  Daher nun nur die Quintessenz von meinem vorherigen Blabla:

Der Sinn meiner DB ist eine Master-DB aufzubauen, wo ich alle Firmen-, Kontakt- und Produktdaten speichern kann. Bis auf einige Überlappungen sind die Daten eigentlich - projektweise könnte man sagen - getrennt. Wie Du schon richtig sagst, hatte ich davor Exceltabellen wo jeweils ein Produkt eine Zeile ist. Dies ist allerdings wenig bequem und bei vielen Daten sogar sehr nervig, da es auch viel Redundanz gibt (jede Zeile hat Firmen- und Kontaktdaten, etc). Daher jetzt meine Überlegungen, wie man das in Access besser machen kann.

Ein plastisches Beispiel zum Verständnis:
Ich muss eine Fruchtsaftfabrik bauen. Dazu muss ich Saftpressen etc. kaufen und möchte die Hersteller, Kontakte und Maschinen speichern damit ich vergleichen und ordentlich mit den Herstellern arbeiten kann.

Gleichzeitig bin ich aber auch Betreiber der Saftfabrik und muss Früchte, Flaschen, etc. einkaufen. D.h. ich spreche mit Obstbauern, etc. und muss hier Firmen, Kontakte und Produkte (mit ggf. Unterkategorien) speichern und damit arbeiten.

Überlappungen gibt es jetzt, wenn z.B. ein Hersteller von Saftpressen auch Äpfel verkauft (Hersteller) bzw. vertreibt (Händler ggf. sogar für einen Apfelhersteller in der DB).
Ähnlich bei Kontakten, die beispielsweise Saftpressen, etc. und auch Früchte vertreiben. Es kann auch sein, dass es einen direkten Kontakt zum Hersteller und einen Händler-Kontakt zu einem Hersteller gibt.

Mein Gedanke ist nun, dass diese Verbindungen in der DB sein sollen, so dass man bei einem Kontakt sehen kann, welche Hersteller / Produkte er vertritt, etc.

Des weiteren sollen natürlich (zukünftige) Kunden oder zuständige Behörden erfasst werden.

Grundsätzlich kann/will ich über Kategorien die einzelnen "Geschäftsfelder/Projekte" trennen. D.h. eine Kategorie ist "Saft-Press-Maschinen" und einen andere "Früchte-Einkauf". Solche Kategorien gibt es sicherlich mehr als 5 oder 10, d.h. hier sollte die Struktur so sein, dass das "zukunftsfähig" ist.

Ich hatte ursprünglich daran gedacht, Firmen nach Kategorien in einzelnen Tabellen zu speichern und so alle Daten zu trennen. Aber dies erscheint noch komplizierter als mit Kategorien zu arbeiten...

Ich hänge zur Info mal meine aktuelle Struktur an. Ist noch nicht alles umgesetzt, insb. die Kontakt-Struktur. Bin primär dabei das alles richtig aufzubauen. Im Moment verzweifle ich auch etwas, wie man mit m:n Hilfstabellen-Daten in Formularen arbeitet, insb. bei Dingen wie mehreren Kategorien pro Firma... Muss noch viel lernen.

DANKE!

Sie dürfen in diesem Board keine Dateianhänge sehen.

maddhin


Beim Thema "Produkte mit unterschiedlichen Eigenschaften" müsste es doch eigentlich gut funktionieren, wenn man eine Produktstammdaten-Tabelle macht und eine zusätzliche, kategorie-abhängige Tabelle, wo die kategorie-spezifischen Eigenschaften untergebracht sind. So wie Du im Prinzip vorschlägst.

Wie die Zusatz-Tabellen genau aussehen müssen, weiß ich nicht, aber ich denke mit ID_Produkt und ID_Kategorie als FK müsste das irgendwie funktionieren. Werde mal überlegen.

Im Formular müsste man dann doch eigentlich "einfach" (nicht, dass ich wüsste wie, habe aber sowas mal bei Youtube gesehen. Glaube ich.) das richtige Unterformular laden können, wenn man die entsprechende Kategorie in den Stammdaten auswählt.
Hier gibt es ja eigentlich auch keine Probleme, weil je Kategorie genau ein Unterformular geladen werden soll. Irgendwo muss dann wohl noch hintergelegt werden, welches UF für welche Kategorie.

Wie das jetzt ausgewertet werden kann, weiß ich nicht - das ist dann ein Problem für morgen haha

crystal

Hallo maddhin,

schön, dass dir meine Antwort gefallen hat. Ich war etwas unsicher, weil sie doch recht ausführlich ausgefallen ist...

Ich denke, du bist auf dem richtigen Weg. Mach dir erst ausführlich Gedanken und entwerfe Konzepte mit Papier und Bleistift.

Ich glaube, deine z. B. Firmendaten sind gar nicht so unterschiedlich, wie du vermutest. Eine Firma hat allgemeine Daten (Adresse etc.) und bestimmte Attribute (Hersteller/Händler/Landwirt/Produzent usw.). Diese Attribute bedeuten aber nicht zwingend, dafür jeweils eigene Unter-Formulare und separate Tabellen benutzen zu müssen.

Welche Daten willst du z. B. für einen HERSTELLER grundsätzlich anders eingeben als für einen HÄNDLER? Daten wie "Vereinbarter Rabatt", "Zufriedenheit" usw. können doch für beide "Firmen-Typen" identisch sein. Wenn es keinen "vereinbarten Rabatt" gibt, bleibt das Feld einfach leer. Dann brauchst du doch "nur" das Attribut "Ist ein Hersteller" und/oder "Ist ein Händler" zu speichern - und brauchst dafür keine zwei unterschiedlichen (Unter-)Formulare mit separaten Tabellen.

Wichtiger wäre es doch, hier die Ansprechpartner (AP) zu speichern und denen jeweils ein Attribut zu geben wie "AP für Rabatt-Verhandlungen", "AP für Bestellungen", "AP für Zertifikate" usw. Das ginge einfach mit Hilfe einer "Ansprechpartner-Typen-Tabelle" und einer entsprechenden Kombobox zur Auswahl beim aktuellen AP. Weitere Datenfelder wie Name, Telefon, E-Mail-Adresse, Notizen usw. wären dann für alle Ansprechpartner gleich - egal um welchen "Typ" es sich handelt.

Wenn du die Typisierung/Attributierung auslagern möchtest, brauchst du dafür eine Tabelle, in der zu jeder Firma (Firmen-ID) ein oder mehrere Attribute (Hersteller, Händler usw.) gespeichert werden. Eine solche Tabelle könnte als Primärschlüssel einfach einen Autowert (laufende Nummer) haben. Bei sehr geringer Zahl von Typen kannst du das aber auch in der Firmen-Tabelle selbst in entsprechenden J/N-Feldern ("IstHersteller", "IstHaendler" usw.) speichern und im Firmen-Formular schlicht mit Häkchen versehen, denn weiter muss ja nichts passieren, weil es im Grunde nur wenige wirklich unterschiedliche Datenfelder für "Hersteller" und "Händler" gibt. Nicht benutzte Datenfelder bleiben dann einfach leer.
Typ-spezifische Unterformulare kann man zwar vorsehen, das Handling wäre aber (an der Oberfläche) nicht ganz so einfach und die spätere Suche nach solchen Daten (z. B. innerhalb eines Projektes) auch nicht trivial.

Es geht dabei eigentlich immer um die Frage: "Was will ich wann/wie mit diesen Daten machen". Stell dir z. B. eine Suche vor: zeige mir alle Firmen, die "Hersteller" sind. Wenn dieser "Typ" in einer Tabelle gespeichert ist, musst du immer zwei Tabellen abfragen, nämlich die Firmen-Hauptdaten und die Attribut-Tabelle - verknüpft mittels einer 1:n-Beziehung. Wenn das Attribut hingegen in der Haupt-Tabelle selbst gespeichert ist, brauchst du nur in dieser einen Tabelle zu suchen. Bei EINEM Attribut ist das beides kein Problem, wenn du aber zur Firma auch andere Attribute in separaten Tabellen speichern möchtest, kann es schon schwieriger werden, denn du kannst in Access einer Haupt-Tabelle zwar (beliebig) viele Zusatz-Tabellen per Beziehung zuordnen, irgendwann verweigert Access dann aber die direkte Änderungs-Möglichkeit in so mehrfach verknüpften Tabellen...du kannst zwar suchen, aber die gefundenen Daten können ggf. nicht mehr unmittelbar geändert, sondern nur angezeigt werden. Hier kommt es aber darauf an, wie das im Einzelfall programmiert und wie das betreffende Formular gestaltet ist...

Fang doch mal "am anderen Ende" an: du möchtest ein neues Projekt anlegen. Neben allgemeinen Daten (Beschreibung etc.) willst du z. B. ein paar Firmen zuordnen, die für das Projekt wichtig wären und vielleicht jeweils einen oder mehrere Ansprechpartner, weiter ein Aktivitäts-Log oder eine ToDo-Liste usw.

Ausgehend vom Projekt brauchst du dann also einige separate Tabellen, die jeweils auf andere Tabellen verweisen, z. B.
Projekt-->Firmen (mit Verweis auf Firmen-Tabelle), WAS ist diese Firma im Bezug auf das Projekt
Projekt-->Ansprechpartner (mit Verweis auf AP der betreffenden Firma)
Projekt-->Aktivität (mit Verweis auf z. B. Ansprechpartner) und Datum/Uhrzeit des Kontakts, Kommentar etc. dazu
Projekt-->Aktion (Datum/Uhrzeit, Was-soll-getan-werden, erledigt J/N, erledigt von... am... um...)

Das alles könntest du mit einem Tab-Formular realisieren (je Tab unterschiedliche Endlos-Formulare) oder mit speziellen Einzel-Formularen (Projekt-Firmen erfassen, Projekt-Aktivitäten erfassen, usw.)

Im Tab (oder separatem Formular) "Projekt-Firmen" stellst du ein Unterformular zur Verfügung, in dem Firmen ausgewählt werden können. Zu jeder Firma kannst du dann weitere Daten eingeben, die genau für diese Kombination Projekt+Firma gelten und eben für "Anderes Projekt+gleiche Firma" anders sind.

Im Tab "Ansprechpartner" werden nur die AP derjenigen Firma angezeigt/angeboten, die im Tab "Firma" angewählt wurde. Oder es gibt in diesem Tab eine Kombobox, in der die Firmen dieses Projektes auswählbar sind.

Wenn du bei deinen Überlegungen so vorgehst, wird dir schnell klar werden, welche Firmen-Typen du einem Projekt zuordnen willst. Ist es hier wichtig zu wissen, ob eine Firma Hersteller oder Lieferant ist? Kannst du das mit entsprechenden Such-Buttons lösen (Suche alle Firmen, suche nur Hersteller, suche nur Lieferanten usw.)? Wie soll der Anwender solch verschiedene Suchen auswählen? Eigene Buttons oder Kombobox oder Radio-Buttons? Wäre es vielleicht sogar wichtiger, alle Firmen der näheren Umgebung angezeigt zu bekommen oder nur die Firmen, mit denen du in der Vergangenheit sehr gute Erfahrungen hattest?

Also nochmal: wenn du dir überlegst, welche Daten wann/wie/warum in der fertigen Anwendung gesucht/abgerufen/zugeordnet/ergänzt werden sollen/können/müssen, kannst du - nach kritischer Prüfung - dein Datenmodell anpassen und entscheiden, welche Daten in welchen Tabellen gespeichert werden sollen.

Ich habe Datenbank-Anwendungen oft so entworfen: Papier nehmen, Dialoge skizzieren, an einer Pinnwand nebeneinander hängen, "Fäden" mit Nadeln und Gummiband markieren oder mit Filzstift malen, Anwender befragen, Skizzen verändern, neue hinzufügen, überflüssige entfernen... Meistens ergaben sich so neue Erkenntnisse.

Sorry - ist schon wieder ein langer Text geworden. Aber als Frührentner habe ich viel Zeit und schreibe lieber ausführlich...

Grüße,

crystal

Wer Fehler in meinen Antworten findet, darf sie behalten, muss sie aber kommentieren. ;-)
Dies ist keineswegs arrogant gemeint, sondern soll nur unterstreichen, dass meine Antworten - natürlich - nicht immer fehlerfrei sind und sein können.
Devise: bitte immer erst selbst probieren!

maddhin

Hallo Crystal,

als Nicht-Frührentner ;D  sehe ich Deinen Beitrag leider erst jetzt.

Dein Beitrag ist extrem hilfreich. Du sprichst einige sehr wichtige und gute Punkte an, an die ich nicht gedacht habe. Und: Du beantwortest schon einige Fragen, an die ich noch gar nicht gedacht hatte! Im Moment wollte ich eigentlich nur eine Firma-Produkt-Kontakt-DB um "Daten zu erfassen", aber Du hast vollkommen recht, dass es Sinn macht, hier noch eine Projekt- bzw. Projektmanagementebene einzubauen. Auch wenn es sich nicht um Projekte im engeren Sinne handelt. Aber dies ist eigentlich genau was ich mit der DB will!

Ich habe jetzt mal meine aktuellen Excel-Daten importiert (nur Firmendaten und den Teil der "allgemeinen" Produktdaten) und bastle während der Arbeit mit den Daten an dem Firmen- und Produktdatenformular um besser zu verstehen was wo hinmuss, damit das alles effizient wird.

Kontaktdaten mit Aktivitätsverfolgung, etc. und auch das "Produkt-Unterformular" mit zusätzlichen Daten bei bestimmten Produktkategorien habe ich noch nicht implementiert - das möchte ich aber so schnell wie möglich machen, damit ich soweit alle Daten im System habe und zumindest rudimentär mit der Datenbank live arbeiten kann.

Du hast mir viel zum Nachdenken gegeben. Ich werde wohl ein paar Tage sinnieren müssen, um das wann wie wo definieren zu können. Daher auch die Arbeit an den Daten, da dann schnell klar wird, was benötigt wird. Aus Entwickler-Sicht sicherlich nicht ideal, aber aus Selbstständiger-Sicht effizient LOL.

Nochmals: herzlichen Dank für Deine Ausführungen, ich werde diese Stück für Stück durcharbeiten - und dann sicherlich mit noch mehr Fragen/Kommentaren zurückkommen! LOL

Schönes Wochenende!