Datenbankaufbau - Produkt-Kategorie-unterschidliche Eigenschaften

  • Hi,

    ich bin eben am Aufbau einer neuen Datenbank und stehe vor dem Problem, einer bestimmten Kategorie von Produkten nur eine bestimmte Möglichkeit der Eingaben zu dessen Eigenschaften zu geben.
    Anders gesagt, ich habe eine Tabelle für Produkte (Produktname, Artikelnummer, ...) und ordne dieser Produkte einer entsprechenden Kategorie zu (Kategoriename1, Kategoriename2, Kategoriename3, ...). Je nach Kagegorie soll es möglich sein, weitere Eigenschaften des Produktes ein zu tragen. Geht man also im unteren Beispiel (vereinfacht dargestellt) davon aus, dass es sich bei Kategoriename1 um ein Möbelstück handelt, und sich Kategoriename2 auf Glühbirnen bzw. Kategoriename3 sich beispielsweise auf Lebensmittel bezieht, so haben diese jeweils unterschiedliche Eigenschaften. Es soll also vorab bei Auswahl der Kategorie nur möglich sein, diese Eigenschaften in die Tabelle der entsprechenden Kategorie (Kategoriename1,2,3,...) ein zu tragen, wobei diese Eigenschaften eben auch dem entsprechenden Produkt zugewiesen werden.

    Da ich noch nicht all zu lange mit Datenbanken arbeite, kann mir hier jemand einen Tipp geben, wie sich dies am elegantesten realisieren lässt.

  • So macht man das nicht. Du musst die Daten http://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29
    Du nimmst dir 4 Tabellen nach folgendem Muster(Beispiel)

    Code
    Produkt                    Feldtyp
    ID                         integer, Primary key
    Artikel_Nr                 interer oder Char
    Name                       Char(255)
    Listenpreis_VK             number
    Kategorie_ID               integer 
    Eigenschaft_zu_Produkt     integer
    Restposten                 Boolean(Ja/Nein)
    Publiziert                 DateTime
    etc.
    Code
    Kategorie          Feldtyp
    ID                 integer, Primary key
    Name               Char(60)
    Beschreibung       Char(1000)
    Code
    Eigenschaften      Feldtyp
    ID                 integer, Primary key
    Name               Char(60)
    Kategorie_ID       integer
    Code
    Eigenschaft_zu_Produkt     Feldtyp
    ID                         integer, Primary Key
    Produkt_ID                 integer 
    Eigenschaften_ID           integer
    Wert                       VarChar(30)


    So kannst jedem Produkt eine Kategorie zuweisen und beliebig viele Eigenschaften.

    Auf Spalten die du absuchst mit Begriffen setzt du noch zusätzlich einen Index.

    Wahrscheinlich noch nicht perfekt, aber es soll dir auch nur zeigen wie man Tabellenstrukturen aufbaut.

    Einmal editiert, zuletzt von explanator (25. November 2013 um 16:12)

  • Bin hier doch noch auf ein weiteres Problem gestoßen.
    Da die Werte im Feldtyp Eigenschaft_zu_Produkt unterschiedlichen Datentypen (Char, integer, Boolean, ...) haben kann/sollte, müsste man dies Problem auch noch separat angehen. Hier fehlt mir aber jeglicher Lösungsansatz. Eventuell über ein Feld "Einheit" im Feldtyp Eigenschaften? Wobei, wie würde sich dass dann im Feldtyp Eigenschaft_zu_Produkt umsetzen lassen?
    Ich hoffe, dass diese Fragen nicht schoon zu banal sind ;)

  • Bin hier doch noch auf ein weiteres Problem gestoßen.
    Da die Werte im Feldtyp Eigenschaft_zu_Produkt unterschiedlichen Datentypen (Char, integer, Boolean, ...) haben kann/sollte, müsste man dies Problem auch noch separat angehen. Hier fehlt mir aber jeglicher Lösungsansatz.


    Du sollst ja auch noch was zu tun haben.

    Zitat


    Eventuell über ein Feld "Einheit" im Feldtyp Eigenschaften?


    Ja - das ginge.

    Zitat


    Wobei, wie würde sich dass dann im Feldtyp Eigenschaft_zu_Produkt umsetzen lassen?
    Ich hoffe, dass diese Fragen nicht schoon zu banal sind ;)


    Leider ja - sehr banal. Sind Grundlagen, bevor man sich mit Datenbanken überhaupt beschäftigt.

    Wenn du 480 Gramm Bananen aus Ecuador hast. Dann hast Du 2 Eigenschaften
    Gewicht
    Ursprungsland
    und 2 Einheiten
    Kg
    und NULL

    NULL deshalb weil Ursprungsland keine Einheit braucht.
    Du kannst auch ruhig die Eigenschaften, die eigentlich Zahlen enthalten als Char oder Varchar ablegen. Das macht alles nicht viel aus, lässt sich halt nur nicht so einfach damit rechnen, weil man dann casten müsste, aber mit Eigenschaften wie du sie genannt hast rechnet man ja sowieso nicht, innerhalb der DB.

    Wie viele Produkte hast du überhaupt, wie viele Kategorien usw. Das muss man alles vorher mit berücksichtigen.
    Was unterliegt häufigen Änderungen, was muss welche Tabellen-Engine(Memory, Archiv etc) bekommen. Welche Datenbank eignet sich überhaupt für meine Aufgabe.
    Kann ich das evtl auch SQLite3 umsetzen.
    Fragen über Fragen, die du dir vorab stellen solltest und auch beantworten können musst.

    Einmal editiert, zuletzt von explanator (25. November 2013 um 22:35)

  • danke für die ehrliche Antwort. Dachte eigentlich, dass ich mich schon durchaus ins Thema DB eingelesen habe, aber scheinbar war das doch noch zu wenig.
    Das obige Bsp. entsprich nicht ganz dem, was schlussendlich unter Kategorien geschehen soll. Ich habe momentan in etwa über 5000 verschiedene Artikel (elektronische Ware), die in etwa 6 Hauptkategorien und darunter wieder in etwa 3-10 Unterkategorien eingeteilt werden müssen. Also ne Menge Arbeit :). Die Einheiten sollen hier schon passen, da ich auch einiges zur weiteren Verarbeitung/Berechnung/Sortierung benöige. Normalisierung 1-3 war mir hier auch schon bekannt, aber die Umsetzung fällt mir hier noch etwas schwer, bzw. stell ich mir wohl die falschen Fragen. Wobei ich scheinbar, um auf den Anfang zurück zu kommen, den Wald vor lauter Bäume nicht mehr gesehen habe :).
    Es gibt natürlich auch einige zeitliche Einheiten, betreffend Memory und Archiv (falls du das meinst). Da hab ich auch noch einiges zu tüfteln. Momentan versuche ich mich in Access und SQL bzw. verknüpfe das auch mit PHP/MYSQL, aber da gibt es überall noch ne Menge zu lernen und lesen. Wobei ich Access momentan eher als erste Annäherungsstufe zu diesem Thema sehe.

    Danke nochmals für deine Hilfe!

  • 5000 Artikel sind für eine Datenbank natürlich ein Witz. Wenn du jeden Artikel mit 2000 Zeichen komplett beschreibst, dann wären das insgesamt 10 Megabyte. Ein Wert den man bequem im Speicher vorhalten kann.

  • So gesehen hast du natürlich recht. Dachte da eher an die Eingabe der Daten, die auch noch auf Richtigkeit usw geprüft werden müssen. Da haben sich über die letzten Jahre doch einige Fehler in den Grunddaten eingeschlichen :D

    Einmal editiert, zuletzt von snash00 (26. November 2013 um 08:16)