CONTENIDO Forum

Aixtraweb hat geschrieben:was ist denn mit Farbangaben, Größen, Ausstattungsmerkmalen wie: 5 MB, 15MB, bzw. Versionen WIN, MAC, Linux, bzw. Boxprodukt, Download-Version oder anderen Artikelmerkmalen?

Soweit ich das sehe, drehen sich alle Tabellen im unteren Bereich "conShopOption..." darum.

Ich hätte da noch eine Anforderung. So eine Lagerverwaltung ist ja im Prinzip vorgesehen (articlenumber ist Anzahl?).

Was ganz toll wäre, wäre wenn auch abhängige Kombination erfasst werden könnten (ich weiss, hat jetzt keiner verstanden und wenn, wird es da langsam schwierig).

Beispiel:
T-Shirt, weiß, XL, runder Kragen

T-Shirt ist dabei der Artikel (den ich auch so haben möchte), das andere sind die schon erwähnten Optionen. Leider entspricht die Kombination aus allem dem eigentlichen Artikel (nicht nur T-Shirt an sich)... und es wäre total toll, wenn das gleich von Anfang an berücksichtigt werden könnte. Daran krankt nämlich xtCommerce (und osCommerce kann es gar nicht).

Was ist damit gemeint? Nun, mein Wunsch wäre, dass ich a) für die individuelle Kombination aus Artikel, Option 1, Option 2, Option 3 (z.B. T-Shirt, weiß, XL, runder Kragen) einen Bestand erfassen (der bei Abverkäufen reduziert wird) und b) dafür einen Preis festlegen kann.

Bei xt und osCommerce könnte ich die Anforderung so lösen: Ich definiere für jede Kombination einen Artikel (was natürlich quark ist, da ich dann 250 Artikel habe).

In xtCommerce kann man einen Artikel festlegen (T-Shirt) und davon relativ unabhängig Optionen. Allerdings kann man nur für die Werte einer Option Lagerbestand und (Auf-)preis festlegen. D.h. ich könnte sagen, dass das T-Shirt in rot 3 mal und in blau 4 mal auf Lager ist. Möchte ich meine Anforderung erfüllen (die ich bei Klamotten IMHO irgendwie immer habe), muss ich die Option "rot, XL, runder Kragen", "rot, L, runder Kragen", "rot, M, runder Kragen" usw. als Werte dieser einen Option "Eigenschaften" definieren.

Das mit dem "Aufpreis" durch Optionen ist übrigens ein nettes Feature, da man damit Dinge kombinieren kann.

IMHO ist das furchtbar schwer in der DB abzubilden (und so aus dem Stehgreif habe ich keinen Vorschlag), aber wenn man gleich am Anfang daran denkt... büüüüütte.

Ich mach' auch später mit...

Gruß
HerrB

OFFTOPIC

HerrB hat geschrieben:T-Shirt ist dabei der Artikel (den ich auch so haben möchte), das andere sind die schon erwähnten Optionen. Leider entspricht die Kombination aus allem dem eigentlichen Artikel (nicht nur T-Shirt an sich)... und es wäre total toll, wenn das gleich von Anfang an berücksichtigt werden könnte. Daran krankt nämlich xtCommerce (und osCommerce kann es gar nicht).

sorry muss ich wieder sprechen kann oscommerce mit verschiedensten contributionen, deine variante wird durch die 'artikelgroesse' contribution gelöst. das ganze wäre ja sonst schwachsinning denn für eine warenwirtschaft sind ja wie du beschreibst

T-Shirt, weiß, XL, runder Kragen
T-Shirt, weiß, L, runder Kragen

zwei eindeutige artikelnummern

und genau so löse ich das auch, meine externe warenwritschaft bedient den shop und aussehen könnte es beispielsweise so:
http://targetpanic.funjumping.de/shop/p ... ucts_id=27

sorry muss ich wieder sprechen

Mach ruhig... Leider nein, es ist nicht das Gleiche.

Was Du schilderst, ist das, was bei xtCommerce out-of-the-box verfügbar ist und bei osCommerce via Contribution nachrüstbar ist (das war das Beispiel).

Leider deckt es nicht den Bedarf ab, da man damit nur eine Eigenschaft berücksichtigen kann - hier die Größe (oder zumindest bei xtCommerce, was auch immer man definiert).

Ein T-Shirt bleibt zunächst ein T-Shirt (einer bestimmten Art, das mit dem Kragen ist da schon ein schlechtes Beispiel).

Mit der Lösung in xyCommerce kann ich es nicht so abbilden, dass ich 23 blaue T-Shirts in XL habe (zu 35,00 €), 12 blaue T-Shirts in L (23,00 €), 7 rote T-Shirts in XL und 2 gelbe in L (zu je 10,00 €) und der Nutzer aus den Optionen "Größe" und "Farbe" wählen kann.

Farbe Größe Anzahl Preis
blau XL 23 35,00
blau L 12 23,00
rot XL 7 10,00
gelb L 2 10,00

Zur Lösung in xyCommerce muss ich als Eigenschaft "blau, XL", "blau, L", "rot, XL", "gelb, L" definieren. Jede beliebige Eigenschaft (z.B. mit/ohne Aufdruck) würde das verschlimmern. Da wählt dann der Nutzer aus einer Liste á la "blau, XL, druck", "blau, L, ohne", "rot, XL, druck", "gelb, L, ohne" usw. - wenn Du jetzt den Faden verloren hast, mir und dem Nutzer geht es genau so; raus kommt nämlich eine gruselige Liste in einer Combo-Box.

Deswegen die Bitte, das am Anfang zu berücksichtigen - das geht nämlich nur, wenn man bei der DB-Struktur das gleich mit macht (und zwar für beliebige Dimensionen). Das später anzuflanschen, führt nur zu einer Lösung á la xyCommerce (zwei Dimensionen).

Gruß
HerrB

P.S.: Kannst ja mal bei Deinem Link (wenn es Dein Shop ist) die zusätzliche Option "mit/ohne SupportPack" bei gleichzeitiger Wahlmöglichkeit unterschiedlicher "Größen" abzubilden...

auch dafür gibt es eine elegante lösung:

https://www.sportspirit.de/product_info ... ts_id=2657

die auswahlen in der dropwonbox werden dann jeweils als eigener artikel geführt

das ganze ist ein 'derivat' der artikelgrössen contrib

Zum einen kann ich nicht nachvollziehen, ob die jeweilige Kombination auch andere Preise und Berücksichtigung der Lagerbestände (und bei Bestellung reduzieren derselben in Abhängigkeit von den gewählten Optionen) zur Folge hat (ein anderer Winkel ändert z.B. am Preis nix).

Zum anderen können es beide xyCommerce von Hause aus nicht und das war meine Aussage. Mein Antrag war, es von Hause aus zu berücksichtigen.

Lustigerweise basiert diese Lösung auf JavaScript, was grundsätzlich ok ist. Als nettes Goody wird aber auch ein baseprice mitübertragen - wann kriege ich den denn?

Gruß
HerrB

wie bereits in meinem ersten topic bemerkt war meine bemerkung

OFFTOPIC

das es auch mit deinen bedingungen funktioniert hat der autor mal im cao-faktuar board als 'statement' geposted.

wie gesagt ein hangestricktes javascipt contruct basierend auf der artikelgrössen contrib.

das goodie kannst du dir beim webmaster direkt abholen

im übrigen finde ich diene anmerkung dazu mehr als nur berechtig, da jede gesunde wawi eben eine eigen atikelnummer benötigt.

@HerrB

hast du denn auch eine vorstellung, wie sich das im erd unterbringen liesse?

wenn ich alles soweit richtig verstehe, müsste ich eine tabelle integrieren, die eine nicht näher spezifizierte anzahl fremdschlüssel enthält. denn immerhin weiss ich ja dann immer noch nicht, wieviele optionen ein artikel haben wird. bei einer einzelnen option würde ich einen schlüssel benötigen, für zwei optionen bereits zwei schlüssel und so weiter...

das einzige, was ich mir auf die schnelle vorstellen kann, ist die verwendung nicht atomisierter schlüssel (sprich 0. normalform). und das ist ja im allgemeinen in einem erd nicht gewünscht. genau genommen ist es der anti-christ für ein erd.

und nenbenbei bemerkt: du willst ja nicht - wie du gesagt hast - 250 artikel pflegen müssen. aber beim lagerbestand wirst du auf genau die besagt anzahl (wieviel das auch immer ist) kommen. oder sehe ich das falsch?

ich mache mir mal ein paar überlegungen. vielleicht fällt mir ja noch was schlaues ein.

PS: die optionstabellen, um auf eine gestellt frage zurück zu kommen, sind genau dafür da, artikeloptionen anzugeben. artikelspezifikationen können dann im artikel untergebracht werden (= contenido-artikel).

Habe ich etwas verpasst?

Ich lese hier auf einmal von einer Warenwirtschaft?

und nenbenbei bemerkt: du willst ja nicht - wie du gesagt hast - 250 artikel pflegen müssen. aber beim lagerbestand wirst du auf genau die besagt anzahl (wieviel das auch immer ist) kommen. oder sehe ich das falsch?

Technisch ja, für den Menschen stelle ich mir eine Matrix vor... wie eine Pivot-Tabelle in Excel.

Ich wähle T-Shirt
Ich wähle n Option
Ich wähle Farbe für X und Größe für Y

Ich denke mal drüber nach...

Ich lese hier auf einmal von einer Warenwirtschaft?

Na ja, es wäre schon schön, wenn man einen Lagerbestand erfassen kann und bei einer Bestellung dieser reduziert wird ...

Gruß
HerrB

kummer hat geschrieben:(sprich 0. normalform). und das ist ja im allgemeinen in einem erd nicht gewünscht. genau genommen ist es der anti-christ für ein erd.

GANZ genau genommen ist ein ERD immer in der 3. Normalform.

Halchteranerin hat geschrieben:GANZ genau genommen ist ein ERD immer in der 3. Normalform.

durchaus nicht. ein erd zeigt lediglich die bestehende struktur an. und die kann ohne weiteres von der 0. normalform (keine atomisierung) bis zur 5. normalform (vollständige elimination denkbarer anomalien) reichen. dritte normalform ist angestrebter mindest-standard. sobald man aber zum beispiel serialisierte daten in einem feld hat, hat man eben nicht atomisierte daten in der datenbank. und das ist dann mitnichten 3. normalform.

anyway, hast du einen vorschlag, wie man das von HerrB angestrebte ziel erreichen könnte, ohne für jede denkbare kombination einen artikel anlegen zu müssen?

kummer hat geschrieben:durchaus nicht. ein erd zeigt lediglich die bestehende struktur an.

Wenn man den DB-Entwurf richtig durchfuehrt, faengt man mit dem ERD an, und das, was am Ende als Relationen herauskommt, ist in der 3. Normalform. Wenn man das Pferd von hinten aufzaeumt, erst Tabellen anlegt und dann auf Biegen und Brechen ein ERD erzeugen will, kann durchaus sein, dass das rauskommt, was du sagtest.

kummer hat geschrieben:anyway, hast du einen vorschlag, wie man das von HerrB angestrebte ziel erreichen könnte, ohne für jede denkbare kombination einen artikel anlegen zu müssen?

So spontan nicht, dazu muesste ich mir das Modell genauer anschauen, und sooo viel Zeit habe ich leider nicht.
Aber wenn ich mir deinen Loesungsansatz anschaue

müsste ich eine tabelle integrieren, die eine nicht näher spezifizierte anzahl fremdschlüssel enthält. denn immerhin weiss ich ja dann immer noch nicht, wieviele optionen ein artikel haben wird. bei einer einzelnen option würde ich einen schlüssel benötigen, für zwei optionen bereits zwei schlüssel und so weiter...

wuerde ich als einfachste Loesung vorschlagen, dass man sich auf z.B. maximal 5 Optionen einigt. Damit schleppt man aber unnoetig Ballast mit, wenn nur ein Teil der Optionen oder gar keine belegt ist. Das waere also nur eine Kruecke.

die diskussion ist zwar ein bisschen off topic. aber: wenn du z.b. eine postleitzahl und einen ort in einer tabelle hast, ohne diese in eine separate tabelle auszulagern und zu verknüpfen, hast du bereits nicht mehr dritte normalform (es besteht eine abhängigkeit zwischen postleitzahl und ort). allerdings wird - notabene aus gutem grund - genau solches gemacht (= denormalisierung), um die performance zu verbessern. das führt dazu, dann ein erd häufig nicht vollständig in der dritten normalform vorliegt.

aber ich denke nicht, dass sinnvoll ist, diese diskussion an dieser stelle erschöpfend vorzunehmen...

diese Diskussion hier wirkt sich negativ auf meine Motivation aus, beim conShop mitzumachen... will sagen: ich glaub, datt is mir hier zu hoch..