Struktur: Produktkategorien erweitern

[maddhin]

Hallo,

ich habe leider festgestellt, dass ich bei meiner DB-Planung 2 Fehler gemacht habe:
1. ich habe nur eine Unterkategorie eingebaut, will nun aber noch eine Unterkategorie
2. will bei der Gelegenheit meine DB erweitern, damit ein Produkt auch mehreren Kategorien zugewiesen werden kann

Hier ist meine aktuelle Struktur. Die erste Kategorie (ID_Cat1_Biz) ist Firmen(- und Projekt)kategorie und auch Oberkategorie für die Produkte. ID_Cat2_Product ist die (einzige) Produktkategorie, die ich jetzt erweitern möchte um eine Unterkategorie.
Sie dürfen in diesem Board keine Dateianhänge sehen.

Ich plane dies jetzt in diese Struktur zu ändern:

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

Nun ein paar Fragen:
1. ist diese Struktur soweit richtig?

2. Ich will (und kann) nicht unbedingt jedem Produkt eine Cat3-Kategorie vergeben. Um Dinge möglichst unkompliziert zu lassen, ist eigentlich Cat2 die Hauptkategorie der Produkte und Cat3 möchte ich nur in Fällen nehmen, wenn ich Produkte nochmal unterteilen will/muss. Meine Struktur ist jetzt dann aber sehr abhängig von Cat3. Oder? Seht Ihr hier Probleme mit solchen Daten zu arbeiten, wo "Cat3 ist null" eher die Regel als die Ausnahme ist? So wie ich das jetzt konstruiert habe, hat das Produkt ja keine Cat2/1, solange keine Cat3 definiert ist. Das geht so eigentlich nicht.

3. Gibt es eine Möglichkeit die Produktkategorien flexibel zu gestalten? Es wird mir jetzt viel Arbeit machen, die Produktkategorien umzustellen, ich würde jetzt eigentlich gerne ein System implementieren, was ggf. dann auch eine 4. Kategorie erlaubt. D.h. dass Kategorien "beliebig" erweiterbar sind.
Ich habe bei meinen Versuchen das selbst rauszufinden gesehen, dass Produktkategorien über nur eine Tabelle definiert werden und sich auf sich selbst beziehen. Ich habe hierzu aber keine Erklärung gefunden, wie man das macht bzw. wie die auf-sich-selbst-beziehen-Geschichte funktioniert. Dies wäre dann wohl der bessere Weg.

[maddhin]

Geht sowas?

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

Dann könnte man immer Cat2 definieren und bei Bedarf Cat3 - und man spart sich eine Tabelle...

[Beaker s.a.]

Hallo Martin,
Zunächst halte ich mal die 1:n-Beziehung zwischen Company und
Product für zu kurz gedacht. Diese Beziehung würde ich immer
über eine n:m-Tabelle einrichten.
Das mit den Kategorien und den Unterkategorien habe ich vor
langer Zeit mal mit anliegendem Modell realisiert.
Dabei bekommt ein Product eine feste "Catagory" zugeteilt. Die
Unterkategorien (Productgroups) werden wiederum per n:m-Tabelle
mit den Products verbunden. Über diese kannst du dann den Products
auch Gruppen unabhängig von der Kategorie zuordnen.
Welche Companies welche Kategorien/Gruppen liefern ergibt sich
über die n:m "CompaniesToProducts".
gruss ekkehard

[maddhin]

Hallo Ekkehard,

interessant.

Im Grunde ist das die gleiche Logik, die ich ich im Moment benutze, auch wenn anders implementiert, da ich
1. die oberste Kategorie (Cat1_Biz) benutze, um was bei Dir "category" ist zu definieren.
2. ich im Moment Produkten nur eine Unterkategorie (nicht mehrere "Gruppen" wie bei Dir) zuweisen kann.

Die Definition einer category ist ein interessanter Ansatz, weil ich auch Firmen nach dieser category grob einordne (Cat1_Biz). Das wird später ggf. mal ein Filter um bei Projekten nur Firmen/Produkte bestimmter Kategorien anzuzeigen. "Projekt" wäre dann quasi die Überkategorie für category - hatte aber noch keine Zeit mich mit der Projektebene auseinanderzusetzen. Das muss ich später überbauen...

Die Gruppen bei Dir sind bei mir quasi Cat2. Was ich aber möchte, wäre noch eine weitere Ebene darunter. Da weiß ich jetzt nicht genau, wie ich dies intelligent einbauen kann.

Die andere Frage ist, wie man in meinem Fall mit category am besten umgeht. Ich vergebe einer Firma eine oder mehrere categories (Cat1_Biz). D.h. diese Eigenschaft kann man nicht einfach auf die Produkte vererben (weil nicht eindeutig). Ein Produkt allerdings hat eigentlich immer nur eine category und dann eigentlich auch immer nur eine Gruppe / CAT2 aber ggf. mehrere CAT3 (Element in Gruppe). [wobei ich dem DB-Design nach Produkten schon mehrere categories/CAT2/CAT3 zuweisen können möchte]
D.h. hier kann es dazukommen, dass ich einer Firma eine category 1 zugeordnet habe und dann für die Firma ein Produkt der category 2 anlege. D.h. die Daten sind je nach dem wo man sich die category holt, inkonsistent, wenn man nicht manuell noch die category bei der Firma updatet.

Eine Lösung wäre, wie bei Dir dargestellt, nur den Produkten categories zu vergeben und damit indirekt auch den Firmen. Dies ist allerdings in meinem Fall nicht gut, weil ich bei Firmen nicht unbedingt immer Produkte habe.

Eine andere Lösung wäre Firmen eine andere, eigene Kategorie zu geben. Dies erscheint aber kompliziert und ineffizient...

Alles nicht so einfach LOL

[Beaker s.a.]

Hallo Martin,

D.h. hier kann es dazukommen, dass ich einer Firma eine category 1 zugeordnet habe und dann für die Firma ein Produkt der category 2 anlege. D.h. die Daten sind je nach dem wo man sich die category holt, inkonsistent, wenn man nicht manuell noch die category bei der Firma updatet.

Deshalb wird in meinem Vorschlag ja auch der Firma keine "Category"
zugeteilt; - sondern ergibt sich aus der Zuordnung "Companies <> Products".
Leider kenne ich natürlich deine abzubildende Realität nicht, so dass ich
nichts weiter dazu sagen kann.
Wir brauchten damals keine Zuordnung von Waren- bzw. Artikelgruppen zu den
Lieferanten, - da wusste jeder, der damit zu tun hatte, wer was liefert. Es
gab aber auch nur etwa ein Dutzend Hauptlieferanten und ein bis zwei weitere
Dtz. Für uns war eher interessant eine Übersicht über baugleiche bzw. einfach
ähnliche Artikel zu haben, um bei Lieferschwierigkeiten darauf ausweichen zu
können (abgebildet als n:m mit Selfjoin auf den Artikelstamm).

Produkten schon mehrere categories/CAT2/CAT3 zuweisen können möchte

Dazu müsstest eine n:m zwischen Products und Categories einrichten (siehe
Anlage). Ich habe da jetzt an diese n:m die "Productgroups" angehängt. Ob
das so brauchbar ist kann ich allerdings nicht entscheiden (Grund s.o.).
Vielleicht hat jemand von den Profis Lust etwas dazu zu sagen.

gruss ekkehard

[crystal]

Hallo maddhin,

ich glaube, viele Fragen (und Antworten) sind hier einfach noch zu theoretisch. Sicher ist es richtig und möglich, ein bestimmtes Vorhaben so oder so zu lösen, mir fehlt hier aber der konkrete Bezug, es fehlen konkrete Beispiele.

Die Abbildung von Daten-Modellen und -Beziehungen bringt m. E. eben nur theoretisch Nutzen. Man kann beurteilen, ob ein Daten-Modell eine gedachte Wirklichkeit ausreichend gut abbildet. Entscheidend ist hier, dass sich meine gedachte Wirklichkeit von deiner unterscheidet. Allgemeine Erklärungen wie "Kunde 1 hat Kategorie 2 und Produkte teilweise Kategorie 4" sind eher etwas verwirrend und verleiten dazu, recht komplexe Daten-Modelle zu entwerfen und zu empfehlen, die dann eher nach dem Motto "mit Kanonen auf Spatzen geschossen" ausufern.

Ich persönlich würde es begrüßen, wenn du ein paar wenige konkrete(re) Beispiele nennen würdest. Nicht alles MUSS in des DB-Entwicklung nach den strikten Regeln der Normalisierung realisiert werden, wenn z. B. bei 1000 Produkten nur wenige sehr spezielle Eigenschaften haben, ist es m. E. durchaus statthaft, dies in einem Klartext-Feld zu vermerken, selbst wenn es dadurch streng genommen Redundanzen gibt; aber warum soll ich z. B. bei 995 der 1000 Produkte eine oder gar mehrere 1:n- oder n:m-Beziehung bemühen, die nur für die restlichen 5 Produkte wirklich wichtig wären (und nicht z. B. durch ein simples Klartext-Feld abgedeckt werden könnten).

Ich könnte mir auch vorstellen, gewisse Besonderheiten schlicht in einer "Besonderheiten-Tabelle" zu halten und diese dann im Produkt (oder anderswo) zu referenzieren. Eine solche Tabelle könnte helfen, die "5 von 1000" Produkte zu kennzeichnen.

Es stellt sich immer die Frage: wie soll mit den Daten umgegangen werden, welche Kriterien sollten "im Normalfall" unmittelbar abrufbar sein, welche Eigenschaften könnten z. B. in spezialisierten Abfrage-Dialogen ("erweiterte Suche") hinterlegt werden. Macht es Sinn, z. B. IMMER ein Feld "Farbe" zur Suche anzubieten oder kann z. B. auch nach "'Bemerkung' enthält 'ockergelb'" gesucht werden.

Nehmen wir als Beispiel eine Briefmarken-Sammlung. Klar wäre es hier wichtig, nach "geschnitten" oder "gezähnt" suchen zu können, so dass dies in eine entspr. Tabelle "Zahnung" ausgelagert werden sollte. Es gibt aber auch Briefmarken, die z. B. 3-seitig geschnitten und nur 1-seitig (oben/unten/links/rechts) gezähnt sind. Wie passt das dann in die o. g. Tabelle? Der DB-Theoretiker würde solche Zahnungsarten in die Tabelle auslagern. Aber schon entsteht das nächste Problem: es existieren Briefmarken, die auch noch unterschiedliche Zahnungen aufweisen (8 oder 10 oder 12 Zähne pro Zentimeter) oder für die zum Schneiden keine gerade, sondern eine gezackte Schere benutzt wurde... Wie löst das der allseits bekannte "Michel-Katalog"? Ganz einfach: die Varianten stehen im Text. Sollte ich den "Michel-Katalog" in eine Datenbank abbilden sollen, würde ich auch so vorgehen - nur die wichtigsten Unterscheidungs-Merkmale in separate Tabellen auslagern und "den Rest" in Textfeldern unterbringen. Solche Textfelder könnten ja auch noch kategorisiert werden, z. B. Zahnung, Stempel-Form, Gummierung, Überdruck-Farbe etc. pp. Und ich könnte trotzdem die eine von 1000 Briefmarken finden, in deren Eigenschaften-Kategorie "Zahnung" und dem zugehörigen Text "3-seitig geschnitten" steht. Will ich irgendwann eine neue Kategorie einführen, brauche ich kein Daten-Modell zu verändern, sondern nur die neue Kategorie in die Tabelle eintragen. An der Oberfläche kann ich dem Benutzer einfache Hilfen anbieten, um Daten zu finden (z. B. Kombobox "Kategorie", Anzeige bereits vorhandener Klartexte).

Aber wie passt das nun zu den Daten, mit denen du dich beschäftigst? Ich weiß es nicht. Und daher ist es sehr schwierig, dir konkret das eine oder andere zu empfehlen.

Du kannst m. E. durchaus mit einer allgemeinen "Kategorie-Text-Tabelle" beginnen und so jedem Produkt auch mehrere Kategorien zuordnen. Wenn sich dann im laufenden Betrieb herausstellt, dass gewisse Kombinationen "ausreichend häufig" benutzt werden, kannst du sie immer noch in separate Tabellen auslagern (Erweiterung des Daten-Modells).

Ich würde nicht schon zu Beginn eines Projektes versuchen, "alle möglichen und erdenklichen Eventualitäten" in immer weiter vernetzte Daten-Modelle zu zwängen, sondern eher pragmatisch vorgehen und Eigenschaften durchaus auch redundant speichern. Der andere Weg - erst ein möglichst exaktes Daten-Modell entwerfen - ist nach meiner Erfahrung oft zum Scheitern verurteilt, weil man sich allzu leicht verzettelt und zu häufig an die seltensten Ausnahmen denkt; eine 100-prozentige Abdeckung wird so auch eher nie erreicht...

Wann willst du was suchen können und was willst du mit den "Treffern" anstellen?

Willst du nach Firmen suchen, die "dies oder das" herstellen/vertreiben oder im PLZ-Bereich 28* ansässig sind? Soll dann z. B. der PLZ-Bereich erweitert werden können, wenn die Suche keine Treffer ergab?

Willst du nach Produkten suchen, die "ockergelb" sind - egal von welcher Firma hergestellt/vertrieben - und innerhalb von 5 Werktagen geliefert werden können? Könnte auch "gelb" oder "gelblich" oder "Farbe nach Wunsch" sinnvoll sein?

Das sind sehr unterschiedliche Fragestellungen, die man nicht versuchen sollte, in EINEM Schritt zu lösen. Hier wäre es besser, jedenfalls zwei Buttons anzubieten: "Suche nach Firma" und "Suche nach Produkt".

Ich glaube, du denkst noch immer zu stark an Kunden-Stammdaten und Produkt-Datenblätter, die in Ordnern abgelegt sind und oft handschriftliche Ergänzungen tragen. Solche Datenbestände in eine streng relationale Datenbank - mit dem Anspruch, ALLES abzubilden - zu übertragen, scheitert, zumindest nach meiner Erfahrung, es sei denn, man geht diverse Kompromisse ein. Eine relationale Datenbank kann nicht alles leisten - eine objektorientierte vielleicht schon eher, aber dafür gibt es kaum einfache Möglichkeiten. Eine Video-Datenbank kann mit Hilfe komplizierter Verfahren der Bild- und Bild-Sequenz-Analytik Videos finden, in denen Bäume zu sehen sind. Einfacher wäre es, dem Video das Klartext-Attribut "Bäume" zu vergeben, denn die automatische Analyse könnte "Algen" oder "Kristalle" als "Bäume" interpretiert haben.

Sorry - schon wieder so eine lange Antwort...

Gruß,
crystal

[maddhin]

@Beaker s.a. : Lieben Dank, das ist sehr hilfreich (weitere Ausführungen unten)

@crystal : Danke, ich schätze solche Texte. Ich sehe aber auch, dass ich nicht gut genug kommuniziere. Viele wenn nicht die meisten der Dinge, die Du ansprichst (nur Sachen, die benötigt werden implementieren; Nicht auf Spezialfälle konzentrieren;...) versuche ich eigentlich schon so zu handhaben.

Im Grunde geht es konkret ja nur darum eine weitere, optionale Unterkategorie zu meiner Struktur hinzuzufügen und die Möglichkeit zu schaffen einem Produkt mehrere Kategorien zuzuweisen.

Use case: Ich habe für ein Projekt viele Hersteller, die ich zunächst in Kategorien einteile (Cat1_Biz). Zum Beispiel für ein Projekt "Fruchtsaft-Fabrik": Hersteller von Fruchtsaft-Fabrik-Equipment und "Hersteller" von Früchten. Die Hersteller von Fruchtsaft-Fabrik-Equipment sind in Cat2_Product unterteilt in Saftpressen, Füllautomaten, Verpackungsmaschinen,... wobei die Hersteller von Früchten in Cat2_Produkt unterteilt sind in Äpfel, Orange, Birnen,...

Ich möchte nun hier Saftpressen, Füllautomaten, Äpfel, etc. noch weiter unterteilen können, weil dies bei einigen Kategorien sehr sinnvoll ist. Bei anderen ist dies aber nicht nötig. Wobei Cat2 in einigen Fällen nicht notwendig ist.

Die Kategorien benötige ich
1. um Firmen generell zu sortieren (u.a. auch zur Projektzuweisung auf Basis von i.d.R. mehreren Cat1_Biz Kategorien) und mir alle Equipment- oder Früchte-Hersteller anzeigen zu lassen.
2. um nach bestimmen Produkten bzw. genauer: Produktkategorien suchen zu können. Z.B. möchte ich wissen, wer Äpfel liefern kann, dann aber auch wer "Golden Delicious" hat oder eine Saftpresse mit extra feiner Reibe (gibt's das?).
Beide Suchen habe ich so schon von Anfang an implementiert.

Was nicht geht, ist nur den Produkten Kategorien zu vergeben, da ich bei sehr vielen Firmen keine Produkte zuordne bzw. zuordnen kann - bzw. schlicht keine Produkte habe. Das sind dann Firmen, wie z.B. ein Ingenieurbüro, eine Anwaltskanzlei, Händler, etc. oder auch z.B. Behörden (z.B. Gesundheitsministerium des jeweiligen (Bundes)Landes), die dann zwar einer Kategorie zugeordnet sind, aber eben kein klassisches/physisches Produkt haben. Oder eben einfach Firmen, wo im Moment noch keine Produkte eingepflegt sind, etc.

D.h. im Normalfall gibt es 2 Firmenkategorie-Ebenen (Projekt - noch zu implementieren - und Cat1Biz) und 2 Produktkategorie-Ebenen (Cat2_Produkt und die neue Cat3). Bei Firmen-Typen, die eben keine physischen Produkte haben, möchte ich die Kategorien nutzen um beispielsweise Gesundheitsbehörden in (Bundes)Ländern zu gruppieren, etc.

D.h. ich definiere eine Firma im wesentlichen über 2 Eigenschaften: 1. Firmentyp (Hersteller, Händler, Behörde,...) und 2. Cat1_Biz = Das Geschäft der Firma. Darunter gibt es dann weitere Abstufungen und im Fall von Produkten sind dies dann eben Produktkategorien. Im Moment erscheint mir diese Kategorisierung praktisch und effizient.

Ich hoffe, dies macht es etwas klarer, was ich tue(n will)

Dank & Gruß
Martin

[Beaker s.a.]

Hallo Martin,

Ich möchte nun hier Saftpressen, Füllautomaten, Äpfel, etc. noch weiter unterteilen können, weil dies bei einigen Kategorien sehr sinnvoll ist. Bei anderen ist dies aber nicht nötig. Wobei Cat2 in einigen Fällen nicht notwendig ist.

Was hindert dich daran an die "ProductsGroups" eine weitere Tabelle mit
Untergruppen dranzuhängen?

die dann zwar einer Kategorie zugeordnet sind, aber eben kein klassisches/physisches Produkt haben.

Na ja, eine Dienstleistung kann man ja irgendwie auch als Produkt ansehen.

Oder eben einfach Firmen, wo im Moment noch keine Produkte eingepflegt sind, etc.

Das ist natürlich ein Problem bei meinem Vorschlag. Lösung wäre evtl. eine
Standard-Kategorie ("noch nicht zugeordnet") einzurichten für solche Fälle.

D.h. ich definiere eine Firma im wesentlichen über 2 Eigenschaften: 1. Firmentyp (Hersteller, Händler, Behörde,...)

Hättest du es nicht selbst geschrieben, wäre diese Typisierung auch von mir
noch vorgeschlagen worden.

gruss ekkehard

[maddhin]

Was hindert dich daran an die "ProductsGroups" eine weitere Tabelle mit
Untergruppen dranzuhängen?

Eigentlich nichts, aber im Moment habe ich in Deiner Struktur noch nicht verstanden, wie ich am besten mit der Kategorie umgehe. Firmen über den Umweg Produkt Kategorien zuzuweisen halte ich in meinem Szenario für falsch. Dann müsste ich immer jeder Firma ein Dummy-Produkt zuweisen. Das mache ich im Moment bei Firmen, wo ich noch keine Produktdaten habe, damit diese Firmen bzw. Produkte in der Suche auftauchen. Aber einem Gesundheitsministerium ein Dummy-Produkt zuzuweisen ist mir zu "unlogisch"
Insbesondere weil ich in der Regel mit Firmen arbeite, die i.w.S. Dienstleistungen anbieten, die im Sinne dieser Datenbank keine Produkte darstellen. Daher auch meine hierarchische Struktur mit den an die Firmen geknüpften Kategorien (zumindest auf Ebene 1 Cat1_biz).

Ich hänge nochmal meinen Vorschlag von Beitrag 2 hier an. Hier habe ich
1. Deinen Rat befolgt und Corp/Produkt eine m:n Beziehung gemacht und
2. eine Cat3 rangehängt.

M.E. ist die Cat3 in dieser Struktur dann optional. Ich habe hier die Cat2/3 m:n Hilfstabelle mit der Cat2/Produkt Hilfstabelle kombiniert. Ob das so geht, weiß ich nicht. Aber aus meiner Newbie-Sicht ist das elegant... LOL
Sie dürfen in diesem Board keine Dateianhänge sehen.

D.h. ich definiere eine Firma im wesentlichen über 2 Eigenschaften: 1. Firmentyp (Hersteller, Händler, Behörde,...)

Hättest du es nicht selbst geschrieben, wäre diese Typisierung auch von mir
noch vorgeschlagen worden.

hehe

[crystal]

Hallo Martin (oder maddhin - was dir lieber ist),

so langsam wird es (mir) etwas klarer, was du willst.

Gehe ich recht in der Annahme, dass...
* es bei deiner Anwendung eigentlich um eine Projekt-Planung und -Verwaltung geht und
* Firmen- sowie Produkt-Daten eher als "Datenbasis" herangezogen werden sollen?

Dann würde ich etwa folgendes vorschlagen:
1. Ein neues Projekt wird angelegt und allgemein beschrieben, z. B. auch mit Verweisen auf externe Dokumente etc.
2. Dem Projekt werden "Stationen" oder "Bearbeitungs-(Zeit-)Punkte" 1:n zugeordnet , etwa
2.1 Projekt angelegt am von etc.
2.2 Erst-Recherche: welche Firmen kommen in Frage oder müssen kontaktiert werden?
2.2.1 Wurde die Firma als Projekt-relevant ausgewählt J/N?
2.2.2 Wer hat wann wie mit wem Kontakt aufgenommen?
2.2.2.1 War der Kontakt hilfreich/erfolgreich/ohne Ergebnis...
2.2.2.2 Ist der Kontakt weiterhin wichtig?
2.2.2.3 Ist die betr. Firma für das Projekt weiterhin wichtig?
2.2.2.4 Soll die Firma insgesamt bewertet werden?
2.3 Erst-Recherche: welche Produkte kommen in Frage?
(ähnlich 2.2.1 ff)

Mit anderen Worten: es geht wohl eher um die Fortschreibung eines Projekt-Verlaufs sowie um dessen laufende Beurteilung und Erfassung von Aktivitäten, Zuordnung von Mitarbeitern/Aufgaben usw. usf.
Einzelne Recherchen (s. 2.2 und 2.3) können kein, ein oder mehrere Ergebnisse liefern, die jeweils weiter verfolgt/bearbeitet/beurteilt werden sollen/müssen.
Einzelne Aktivitäten/Aufgaben beeinflussen einen Projekt-Gesamtstatus, der zeitlich fortgeschrieben wird (z. B.
Status am
1.7.: angelegt
2.7.: Basis-Recherche gemacht
2.7.: Basis-Recherche beurteilt
2.7.: Aufgaben verteilt
...
7.7.: Sichtung erster Ergebnisse
7.7.: Firmen ausgeschlossen/bestätigt
7.7.: Produkte/Hersteller gefunden
7.7.: Projekt weiter verfolgen J/N

Wenn dem so - oder ähnlich - ist, ist es m. E. nicht so extrem wichtig, z. B. bei Punkt 2.2 (Erstrecherche Firmen) 100%ig exakt alle in Frage kommenden Firmen zu finden, da diese Firmen in einem zusätzlichen Schritt noch mit "relevant", "irrelevant" etc. im Zusammenhang mit dem konkreten Projekt beurteilt werden können/müssen/sollen. Beispiel: du findest - neben anderen - eine Firma, die Saftpressen herstellt. Aufgabe: nachfragen, ob die auch extrafeine Filter anbietet - das muss nicht unbedingt schon VORHER bekannt sein (kann sich ja auch ändern).

Das ist ein - glaube ich - entscheidender Hinweis: eine Firma, die auch "extrafeine Saftpressen-Filter" anbietet, kann dieses Angebot ja beliebig ändern, erweitern, löschen... Es wäre m. E. also im Rahmen eines neuen Projektes immer ratsam, konkret nachzufragen. Ist es also wichtig/richtig, bei den Daten dieser Firma zu hinterlegen, dass sie solche "extrafeinen Saftpressenfilter" anbietet? Oder würde es ausreichen zu hinterlegen "bietet auch Filter an" und erst im konkreten Projekt nachzufragen?

Der Versuch, Firmen und Produkte möglichst umfassend und genau zu attributieren, scheitert an der Dynamik. Eine Firma kann ihr Angebot von jetzt auf nun erweitern/einschränken, außerdem kann sie schließen oder sich plötzlich einem völlig anderen Geschäftsgebiet widmen. Wichtig ist doch nur, ob eine Firma für ein aktuelles Projekt in Frage kommt - und das kann m. E. nicht durch noch so gut gepflegte Firmendaten entschieden werden, sondern eher nur durch konkrete Nachfrage. Was nutzt es mir, eine Firma als möglichen Lieferanten/Hersteller "extrafeiner Saftpressen-Filter" im Datenbestand gefunden zu haben, wenn einfach nur "vergessen" wurde, dies bei der betreffenden Firma rechtzeitig herauszunehmen?

Andere Informationen könnten hier vielleicht wichtiger sein: "Sehr gute Zusammenarbeit bei Projekt XYZ", "Firma kann auch andere Produkte auf Nachfrage liefern", "Firma kooperiert mit Firma ABC zur Lieferung spezieller Filter" usw. Solche Attribute können kaum in Tabelle ausgelagert werden...

Du gehst bei deinen Überlegungen davon aus, Firmen, Produkte etc. möglichst genau und umfassend zu beschreiben, um die relevanten "Kandidaten" möglichst effizient finden zu können. Ich würde hier eher vorschlagen, die "Kandidaten" mit einer gewissen "Streubreite" oder Ungenauigkeit zu finden und danach zu entscheiden, wer/was wichtig ist (natürlich durch eine Beurteilung durch einen Menschen). Vielleicht wäre es ja auch einmal wichtig zu erfahren, dass eine bestimmte Firma in der Vergangenheit für konkrete Projekte "ausgesiebt" wurde, obwohl sie eigentlich "extrafeine Saftpressenfilter" herstellt. Warum/weshalb/wieso wurde diese Firma "ausgesiebt", warum/weshalb/wieso wurde eine andere Firma gewählt?

Ich gehe also eher von der anderen Seite an das Problem heran: was soll wann/wie/von wem mit den z. B. Firmendaten gemacht werden? Wer pflegt Änderungen/Beurteilungen/neue Ansprechpartner?

Ein neues Projekt benötigt m. E. zunächst nur "ungefähre" Angaben zu In-Frage-Kommenden Firmen und Produkten. Das kann sich ja während der Projekt-Laufzeit auch dramatisch ändern. Wozu also Firmen/Produkte mit einem (doch nie erreichbaren) 100%igen Wirklichkeits-Anspruch im Vorfeld attributieren? Ich tendiere hier eher zu "Fuzzi-Logik": warum nicht für eine geplante Saft-Fabrik eine Molkerei kontaktieren, denn die nutzt doch auch Verpackungs-Straßen und kann vielleicht gute Tipps geben... Zeige mir bitte, wie du das mit Cat_Biz1 etc. definieren willst.

Du siehst: deine ursprünglichen Fragen zur Attributierung von Firmen/Produkten erscheint in anderem Licht, wenn du dich fragst, was mit solchen Attributen wann und wie angefangen werden soll. Es ist m. E. nicht entscheidend, anhand "irgendwann hinterlegter, möglicherweise ungenauer oder schlecht gepflegter" Daten genau die eine Firma für ein neues Projekt zu finden, die "extrafeine Saftpressenfilter" anbietet, sondern eher, welche Firmen hierfür infrage kommen könnten und bei welchen man nachfragen sollte - für dieses EINE Projekt (und nicht für das andere ähnliche, dass in einem anderen Land realisiert werden soll).

Bis dann,
crystal

[Beaker s.a.]

Hallo Martin,

Dann müsste ich immer jeder Firma ein Dummy-Produkt zuweisen

,
Nein, nur eine Dummy-Kategorie - hatte ich doch geschrieben.
Ansonsten bin ich aber erstmal raus. Das wird mir zu umfangreich.
Vielleicht kommst du ja mit crystal auf richtigen Weg.
gruss ekkehard

[maddhin]

Gehe ich recht in der Annahme, dass...
* es bei deiner Anwendung eigentlich um eine Projekt-Planung und -Verwaltung geht und
* Firmen- sowie Produkt-Daten eher als "Datenbasis" herangezogen werden sollen?

Treffer und versenkt!

Zumindest was das konkrete aktuelle Projekt angeht. Andere Projekte sind weniger produktorientiert, sondern da geht es darum die richtigen Partner zu finden bzw. eine Datenbasis für die Arbeit mit Partnern/Firmen zu haben - aber lassen wird dies mal außen vor.

Im Grunde läuft es genau so ab, wie Du dargestellt hast, aber ohne einen festen Rahmen. In der Realität ist die Suche nach passenden Firmen nie fertig und, klar, die Firmendaten ändern sich permanent - dies ist ja im Grunde der Nutzen der DB, da man dort relativ einfach neue Infos einbringen kann und sich so das Bild der Firma bzw. Produktes wie bei einem Puzzle langsam zusammensetzt.

Im Moment mache ich es so, dass Firmen ein Firmen- und ein Produkt-Questionnaire (als .xlsx) bekommen, welches dann importiert wird und als Stammdaten-Spender und erstes Screening fungiert. Danach kommt: Nachfragen, Nachfragen, Nachfragen. Hier werden dann die Infos jeweils beim Produkt oder Firma gesammelt. Dokumente kommen mit Firmenname in Ordner auf den Server (ich habe hier schon einen Button gemacht, der einen Ordner automatisch erstellt, aber ist noch nicht in Betrieb).

Grundsätzlich funktioniert das eigentlich recht gut. Ich habe Formulare jetzt soweit, dass ich schnell Firmen und Produkte finde und zwischen beiden wechseln kann.

Der gesamte Projekt-Teil - inkl. Tracking der Kontakte und sogar Kontakte per se, habe ich noch nicht implementiert bzw. aus Zeitgründen nicht implementieren können. Hier fehlt noch Einiges. Wobei: sehr eng würde ich das Projektmanagement nicht dokumentieren wollen. Die Projekte sind sehr dynamisch und am Ende sind Meilensteine dann mehr oder weniger sinnlos oder in der DB schwer abzubilden, weil ein Teil des Projekts "fertig" ist und ein anderer Teil gerade wieder von vorne anfangen muss, weil sich neue Anforderungen ergeben haben.

Aber, gerade Felder wie "relevant", "wurde abgelehnt wegen" etc sind eine super Idee. Im Moment habe ich Kontake in einem Notiz-Feld und "Tracking" Daten entweder im Firmen- oder Produktnotizfeld LOL

Spezifische Daten werden in den entsprechenden Produkteigenschaftenfeldern abgelegt (in Anlehnung an das Questionnaire), die jeweils quasi eine Frage/Eigenschaft repräsentieren. z.B. ein "Hat feine Reibe?"-Feld wo man dann reinschreiben kann "nein, aber gegen Aufpreis möglich" usw. Diese Spezialeigenschaften habe ich in einer extra Tabelle ausgelagert und beim Produkt nur die üblichen Stammdaten wie Product-Nr., Name, etc. gelassen.

Es ist also genau so, wie Du sagst: die DB ist erstmal "Sammelbecken" (Deine Molkerei!) für potentielle Firmen. Das ist oft praktisch so, dass nur ein Firmenname mit Dummy-Produkt (nur Product Id und Cat2, damit man später noch was, was man von der Firma will) in die DB kommt und später die Firma angesprochen und abgearbeitet wird. Um genaue Datenpflege geht es nicht, sondern - insbesondere in diesem Projekt - darum systematisch mit Firmen zu arbeiten und Produkte/Partner zu identifizieren. Aktuell habe ich etwa 130 Firmen und ~250 Produkte in der DB - mit Excel bin ich verzweifelt haha Die DB in ihrer Unvollkommenheit ist aber schon ein Segen.

Den Ganzen einen ordentlichen Projektmanagement-Kopf zu geben wäre natürlich super und ist recht weit oben auf meiner To-Do-Liste. Im Moment arbeite ich eigentlich nur konkrete Probleme ab - wie die Sache mit der fehlenden 3. Kategorie ab.

Im Moment nutze ich diese Kategorien (sowie den Firmentyp) als primäre Filter / "Organisationseinheiten". Im Idealfall stimmt die Kategorie 100% genau mit dem Produkt bzw. Firma überein. Für diesen Fall habe ich quasi Cat3 vorgesehen, weil hier ein spezifisches Produkt definiert werden kann. Cat2 bedeutet quasi "hat diesen Produkt-Typ" und Cat1 bedeutet "gehört zu diesen Produkttypen oder Themenfeld" (z.B. Equipment für die Saftfabrik). D.h. wenn man durch diese Kategorien bei Firmen bzw. Produkten wandert, hat man schon einen guten Überblick wieviele wo sind und wer was macht.

Ist das optimal? Vielleicht nicht, aber im Sinne von Workflow and Organisation praktikabel, logisch und recht effizient - was für mich das Wichtigste überhaupt ist. Im Moment fällt mir eigentlich auch keine bessere (ähnlich simple) Methode ein, das zu managen - zumindest solange bis ich Zeit habe das Projektmanagement aufzubauen und das Ganze ggf. neu aufzuziehen

Gruß
Martin

[maddhin]

Ansonsten bin ich aber erstmal raus. Das wird mir zu umfangreich.

Lieben Dank für die Hilfe!

[crystal]

Hallo Martin,

Beaker s.a. hat den weisen Entschluss gefasst, sich aus diesem Thread zu verabschieden.
Eigentlich möchte ich das auch, weil
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.

Ich werde meine bescheidenen Kommentare und Fragen aber weiterhin zum Besten geben und zur Überprüfung/Diskussion stellen, sofern dies gewünscht ist. Ansonsten kann ich Beaker nur bestätigen: "Das wird mir zu umfangreich."

Liebe Grüße,
crystal

[Beaker s.a.]

Hallo Martin,
Um deine evtl. entstandene Enttäuschung über unseren Ausstieg
etwas zu mildern, hier noch ein paar Gründe für mich.
Ich bin kein Profi, auch wenn die Anzeige des Skills da etwas
anderes vermuten lässt. Und ehrlich gesagt fehlt es mir an
Abstraktionsvermögen, - ich könnte so ein grosses DM nur aus
eigener Praxis ableiten. Und dann möchte ich natürlich auch
niemanden auf falsche Wege führen. Obwohl die echten Profis
sich mit Kritik (noch) bedeckt halten.
gruss ekkehard