RoflCopter Geschrieben 21. November 2013 Teilen Geschrieben 21. November 2013 Hallo zusammen, aus aktuellem Anlass erbitte ich euren Rat, um nicht im Nachgang strategische Fehlentscheidung bezüglich der Datenbankstruktur zu treffen, beziehungsweise im Nachgang korrigieren zu müssen. Mein jetziger AG arbeitet primär mit CSV Dateien und Excel Dateien. Dies soll sich im Zuge einer anstehenden Kooperation ändern. Die unzähligen Dateien sollen einer MySQL DB weichen (u.a. aus Kostengründen). Bei der Datenbankstruktur stellt sich nun primär die grundlegende Frage wie wir die Informationen zu den diversen "Herstellern", "Produkten" und "Produktgruppen" ablegen. Ich habe hierzu mehrere Ansätze - bin mir allerdings vollends nicht sicher welche Lösung die bessere ist. Eventuell habt ihr noch einen besseren Vorschlag? Anbei meine Ansätze und allgemeine Daten: ca. 240 Hersteller ca. 40 Produktgruppen Die Produktgruppen sind je Hersteller identisch, die Anzahl der zu versorgenden Produkgruppen richtet sich nach dem Vertrag. Pro Produktgruppe und Hersteller 1-x mögliche Artikel. In Summe gibt es ca. 260 mögliche Eigenschaften für die bis zu 40 Produktgruppen - je Produktgruppe sind es schlußendlich jedoch nur bis zu 30 Eigenschaften. Je Hersteller 1-x Verträge möglich. Es gibt Hersteller die a) einzeln auftreten und Produktgruppen regeln und Hersteller die einzeln und in einem Verbund auftreten und dort die gleichen /und/oder verschiedene Produktgruppen regeln. Ansatz a) Alles in eine große Tabelle "werfen" und anhand der Vertrags_ID, Hersteller_ID und der Artikel_ID differenzieren. Problem hierbei: Redundanzen, zusätzlich sind diverse Eigenschaften an den Hersteller z.b. Gewährleistungszeiträume oder Versorgungszeiträume gebunden. Hieße ich hätte oftmals unnötige oder unbenutze Felder & Spalten. Ansatz Für jeden Hersteller eine Tabelle erstellen und dort alle Produktgruppen und Artikel hinterlegen. Problem hierbei: Häufig leere/unbenutzte Felder - da Produktgruppenabhängig nicht alle Felder benötigt werden. Ansatz c) Für jeden Hersteller und dessen Produktgruppen eigene Tabellen anlegen. Problem hierbei: ca. 8600 mögliche - zu erstellende Tabellen Wir kommunizieren dies bezüglich bereits mit einem Dienstleister und dem Kooperationspartner - jedoch stehen weiterhin diese o.g. Varianten im Raum und es geht zur Zeit nicht vorran. Für jeglichen Hinweis oder Ratschlag bin ich sehr dankbar. Viele Grüße roflcopter Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
carstenj Geschrieben 21. November 2013 Teilen Geschrieben 21. November 2013 (bearbeitet) Hi, Hieße ich hätte oftmals unnötige oder unbenutze Felder & Spalten. ja und? Dafür gibt es ja NULL-Werte. Ich denke C ist Quatsch. Am einfachsten ist A, wobei du mit einer Tabelle nicht hinkommen wirst, sofern du Normalisierung berücksichtigst . Du machst eine Tabelle mit den Artikeln, die ein Feld Bezeichnung, Hersteller, Warengruppe und Eigenschaften oder so ähnlich enthalten. Du hast dann entsprechende Tabellen wie Hersteller und Warengruppe, und referenzierst dann eben entsprechend. Im Endeffekt hast du dann 3-5 Tabellen (müsste man dann im Detail entscheiden) die du pflegen müsstest. Alles in eine Tabelle quetschen ist nicht sinnvoll, weil du genau dann natürlich wirklich redudante Datenhaltung hättest. B halte ich auch für unsinnig, dann hättest du 240 Tabellen, was meiner Meinung nach auch zu unübersichtlich ist. Bearbeitet 21. November 2013 von carstenj Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pr0gg3r Geschrieben 21. November 2013 Teilen Geschrieben 21. November 2013 AAAAAA.............. Für was benutzt man denn relationale Datenbanken... Dauernd diese Frage... Und bitte keinen Quatsch mit identischen Tabellen veranstalten... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Der Kleine Geschrieben 22. November 2013 Teilen Geschrieben 22. November 2013 Ansatz a und alles was redundand ist, auslagern in eine eigene Tabelle und diese referenzieren. B und C sind weniger professionell (alleine aufgrund redundanter Datenstrukturen entsprechend der verschiedenen Dateninformationen). Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.