Zunächst möchte ich klarstellen, dass ich keinen Code anfordere. Ich möchte nur keine allgemeinen Ideen / Anleitungen / Meinungen darüber haben, wie ich das, was ich fragen werde, umsetzen kann.

Ich beginne mit dem Aufbau eines Online-E-Commerce-Systems (Yii2 + MongoDB, also PHP + NoSQL), und es gibt zwei Voraussetzungen, bei denen ich mir nicht ganz sicher bin, wie ich sie implementieren soll, ohne sowohl in meinem Code als auch in meinem Code ein großes Durcheinander zu verursachen die Datenbank

Beide Requisiten hängen zusammen, daher erkläre ich sie beide als eine.

Wie bei jedem anderen ernsthaften E-Commerce würde es Kategorien geben. Und wie bei jedem anderen seriösen E-Commerce wird auch bei jedem Produkttags oderoptions. Lassen Sie mich etwas näher erläutern, was ich als @ bezeichntags/options.

Dies sind die verfügbaren Optionen, die ein Benutzer beim Kauf eines Produkts auswählen kann, z. B. die Farbe oder die Größe, das Material usw.

Kategorie

Es gäbe mehreregeneral Kategorien sowie andere Unterkategorien. Zum Beispiel,Electronics könnte eine allgemeine Kategorie sein und Unterkategorien wärenComputers undSmart TVs. Dann,Motherboards undRAM könnte eine Unterkategorie von @ seComputers.

Dies könnte leicht in einer Datenbank gespeichert werden, aber hier ist das Problem:

Jedes Produkt sollte angezeigt werden, wenn eine der Kategorien, zu denen es gehört, oder die oberen Kategorien aufgelistet werden. Das bedeutet, dass, wenn ich (als Endbenutzer) alle Elemente in @ durchsuchComputers Kategorie, ich sollte @ sehNVIDIA GTX670 das zur Unterkategorie @ gehöGraphic cards der KategorieComputers.

Ich könnte jedes Produkt folgendermaßen speichern:

{
    _id: asdasfwetrw34tw34t245y45y,
    name: "NVIDIA GTX670",
    price: 99.50,
    ...
    ...
    categories: [
        "Electronics", //<-- just the ID of that group
        "Computers", //<-- just the ID of that group
        "Graphic cards" //<-- just the ID of that group
    ]
}

Aber

Ich bin mir nicht sicher, wie schnell eine Abfrage zum Abrufen aller Elemente einer bestimmten Kategorie (und natürlich der Elemente aller Unterkategorien) sein würde. Ich bin mir nicht sicher, welche anderen Nachteile diese Methode haben würde. Sie können daher jederzeit ein alternatives Schema zum Speichern dieser Daten empfehlen.

2. Tags / Optionen

Das ist, wo die wirklichen Kopfschmerzen sind.

Jede Option kann zu 0 oder mehr Kategorien und Unterkategorien gehören. Die KategorieWoman fashion könnte die Optionen habensize undcolor, aber die KategorieSunglasses (Unterkategorie vonWoman fashion) könnte nur @ habcolor oder sogar eine andere Reihe von Optionen, die sich von @ vollständig unterscheidWoman fashion.

Außerdem die Werte in jeder Option red, green, blue in demcolor -Option) könnte in zufälligen Kategorien erscheinen. SoWoman fashion hätte Farben wieStrawberry Red undTangerine, währendCars hätteCarbon undBlack metallic.

Auch gibt es verschiedene Arten von Optionen:

öllig statisch (li, kesize, das könnte nur @ seS oderM, aber niemals beides. In jedem Fall kann der Administrator kein @ schreibeBenutzerdefinier Größe, wieKind of small; Er könnte einfach auswählen, was bereits in der Datenbank vorhanden isStatic, das sich kombinieren lässt (wiecolors, das könnte @ sered odergreen oder eine Kombination von Farben, die der Administrator auswählt. Freie Eingabe (wiedimensions oderweight, das wären idealerweise Eingabefelder und Dropdown-Werte, mit denen verknüpft werden soll. Zum Beispiel[10] | (mg||kg|tons) oder[20] (cm|m|km|miles)).

Ich könnte jede Option wie folgt speichern:

{
    option: "Color",
    type: "Static with combinations"
    values: [
        {
            value: "Red",
            categories: [
                "Sunglasses"
            ]
        },
        {
            value: "Green",
            categories: [
                "Sunglasses",
                "T-Shirts"
            ]
        },
        {
            value: "Black metallic",
            categories: [
                "Cars"
            ]
        }
    ],
    categories: [
        "Woman fashion", //<-- only the ID of this group
        "Cars" //<-- only the ID of this group
    ]
}

Aber ich mache mir Sorgen darüber, wie groß eine einzelne Option werden könnte, wenn es 30 Kategorien gibt und jeder Wert der Option so festgelegt ist, dass er in zufälligen Kategorien angezeigt wird.
Auch ich sehe es einfach nicht sauber genug, aber vielleicht bin das nur ich.

Ich freue mich auf jeden Fall, wie im vorherigen Punkt, etwas vorschlagen zu können. Ich freue mich über jedes Feedback, das Sie mir geben können.