Ich baue einen Online-Shop, um Produkte wie "Green Extra-large, T-Shirts" zu verkaufen. Das heißt, das gleiche Hemd kann viele Größen / Farben haben, verschiedene Kombinationen können ausverkauft sein, unterschiedliche Kombinationen können unterschiedliche Preise haben, usw.
Meine Frage ist, wie ich diese Produkte in meiner Rails-Anwendung modellieren sollte (oder wirklich, wie man es in jeder Anwendung macht).
Mein derzeitiges Denken ist:
%Vor%So wird jedes Produkt eine oder mehrere Eigenschaften (z. B. "Farbe", "Größe" usw.) haben, und jede Eigenschaft wird dann eine oder mehrere Varianten haben (z. B. "Rot", "Blau" usw.).
Das Problem mit dieser Methode ist wo kann ich Preis und Inventar speichern? Das heißt, der Preis und das Inventar eines bestimmten Produkts werden durch die Varianten bestimmt, die seine Eigenschaften haben. (Grün ist möglicherweise teurer als Rot, große sind möglicherweise vergriffen, usw.).
Ein Gedanke, den ich hatte, war, den Produkten einen "base_price" zu geben und sie von Varianten modifizieren zu lassen, aber das erscheint übermäßig komplex (und könnte nicht funktionieren).
Ich habe zwei Lösungen für dieses Dilemma gesehen. Die erste besteht darin, zu versuchen, Merkmale zu verwenden, um untergeordnete Produkte für das "Hauptprodukt" zu definieren. Die Herausforderung hier ist, dass neben Ihren Gedanken für weit, in den meisten Fällen wird das Produkt mit neuen Herstellern entwickeln, die neue Aspekte auf den Tisch bringen. Zum Beispiel kann ein Hersteller ein billigeres Produkt herstellen, aber eine andere Anwendungsmethode für das Logo oder die Naht haben, die signifikant genug sein kann, um sie zu verfolgen.
Ich denke, dass das Tragen einer nicht signifikanten Produktnummer für jedes Produkt und das anschließende Anbringen der Eigenschaften als Attribute am besten funktioniert. Es ist leicht zu suchen und erweiterbar. Wenn eine Gruppe von Produkten stark verwandt ist, funktioniert eine Produktgruppe, mit der die einzelnen Produkte verknüpft sind, gut.
In Tabellen:
%Vor%Die Vorteile hier sind, dass Sie leicht nach bestimmten Attributen abfragen können, Attribute sind "flexibel", da mehr hinzugefügt werden kann (und alte angepasst wurden: wenn Sie mit "Rot" begonnen haben, aber dann ein anderes "Rot" zur Farbe hinzugefügt haben) Pool, können Sie sie in "Maroon" und "Bright Red" ändern.
Sie können den Preis und das Inventar auf der Detailproduktebene steuern (obwohl mehr Tabellen erforderlich sein können, um Sourcing -Kosten zu berücksichtigen).
Dies alles setzt voraus, dass Ihre Merkmale allgemein geteilt werden. Wenn dies nicht der Fall ist, kann Ihr charakteristischer Subtable-Ansatz funktionieren, indem Sie eine Join-Tabelle zwischen Merkmalen und Produktdetailtabellen erstellen und diese nach Bedarf auffüllen. Dies erfordert mehr Geschäftslogik, um sicherzustellen, dass jede Produktkategorie alle Merkmale erhält. Im letzteren Fall würde ich "Prototyp" -Produkte in der Basisprodukttabelle (mit Qty und Kosten von 0) verwenden, von denen ich die Merkmale klonen und dann anpassen würde, wenn jedes neue Produkt eingegeben wird. Wie Sie Wenn eine neue Variante angezeigt wird, ist eine Funktion "Dieses Produkt klonen" sinnvoll, mit der Sie einfach die Unterschiede des Basisprodukts anpassen können.
Schließlich wird das Inventar und die Preisgestaltung auf der UI-Ebene verwaltet. In der Lage zu sein, Abfragen für verwandte Produkte (Produktgruppen) zu generieren und alle Preise für verwandte Produkte zu verwalten, wird einen großen Beitrag dazu leisten, diese Lebensfähigkeit zu schaffen.
Tags und Links language-agnostic ruby-on-rails e-commerce modeling