conShop

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer »

also, die sachlage ist zwar nicht sehr kompliziert, aber schwierig zu erklären. ich versuche es mal.

wir haben z.b. die option farbe und innerhalb dieser option die möglichen werte rot, blau und grün mit folgenden werten für singleKey:

rot = 2^0 = 1
blau = 2^1 = 2
grün = 2^2 = 4

dann haben wir neben den farben noch verschieden grössen. z.b. small, medium, large und xlarge. deren schlüssel müssen anders sein, als die der farben. der schlüssel jedes optionswertes eines produktes muss eindeutig sein. wir haben in der folge z.b. folgende werte für die grössen:

small = 2^10 = 1024
medium = 2^11 = 2048
large = 2^12 = 4096
xlarge 0 2^13 = 8192

weitere optionen und optionswerte sind denkbar. für die erläuterung des zugrunde liegenden prinzipts sind diese allerdings ohne belang. es läuft dann immer genau gleich.

die summe zweier (oder mehrerer) dieser schlüssel ist immer so eindeutig, wie ein einzelner schlüssel. um also einer kombination von optionen einen schlüssel zuzuordnen, nimmt man einfach deren summe. also wie folgt:

rot und small = 1 + 1024 = 1025

oder large und grün = 4096 + 4 = 4100

oder xlarge und blau = 8192 + 2 = 8194

damit es richtig spannend wird fügen wir noch gleich eine weitere option hinzu. sagen wir z.b. den schnitt.

eng = 2^15 = 32768
normal = 2^16 = 65536
weit = 2^17 = 131072

die kombination blau, large und eng hätte also folgenden schlüssel: 2 (blau) + 4096 (large) + 32768 (eng) = 36866. es gibt keine andere kombination von optionen, die nach diesem prinzip den gleichen schlüssel ergeben würde.

soweit so gut. allerdings wollen wir bei einer kombination nicht nur eindeutigkeit, sondern auch reversibilität. wir möchten also anhand des schlüssels herausfinden können, aus welchen optionen eine kombination besteht. auch das ist ohne weiteres möglich, wie folgendes beispiel zeigt:

wir haben den schlüssel (36866) und setzen diesen in eine binäre zahl um. dann erhalten wir: 100100000000010 wenn wir uns nun die positionen der einzelnen einsen anschauen, dann stellen wir fest, dass deren position in abhängigkeit zu den optionen steht. wir haben einsen an den positionen 2, 12 und 15. ein kurze rechnung ergibt nun den schlüssel der einzelnen positionen. also 2^2 = 4 = blau, 2^12 = 4096 = large und 2^15 = 32768 = eng.

der schlüssel 36866 sagt uns also, dass es sich um ein shirt in blau, der grösse large und des schnittes eng handelt.

voraussetzung für dieses prinzip ist einfach, dass die schlüssel der optionen für jedes produkt eindeutig sind.

ach ja, fast hätte ich es vergessen, selbstverständlich bringt mysql für diese rechnungen die nötigen funktionen mit. sonst wäre es etwas umständlich. aber das lässt sich alles in ganz normalen queries lösen. also keine rechnungen ausserhalb des rdbms.

alles klar? :lol:
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
Dodger77
Beiträge: 3626
Registriert: Di 12. Okt 2004, 20:00
Wohnort: Voerde (Niederrhein)
Kontaktdaten:

Beitrag von Dodger77 »

kummer hat geschrieben:also, die sachlage ist zwar nicht sehr kompliziert, aber schwierig zu erklären. ich versuche es mal.

... ein Haufen verständlicher Erklärung ...

alles klar? :lol:
Schicke Sache!
HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB »

Schöne Erklärung. Danke.
ch habe die optionen bewusst nicht zentral gesteuert. der grund ist einfach. jemand hat cds oder dvds ohne optionen, dann t-shirts mit optionen grösse und farbe und schnitt und dann nochmals ein produkt mit irgendwelchen anderen optionen. die wahl ist bewusst so erfolgt. wenn ich z.b. eine option nur genau bei einem produkt habe (und sonst nie), müsste ich es zentral einpflegen und dann bei den anderen wieder angeben, dass es eben nicht verfügbar sei. und z.b. die farbe. die wäre dann nicht bei jedem kleidungsstück gleich. da halte ich die redundante speicherung für sinnvoll.
Nee, da kommen wir nicht zusammen. Wenn ich 10 T-Shirts (z.B. mit unterschiedlichen Motiven) habe oder Spanplatten unterschiedlicher Fertigungstechnik, die ich als einzelne Produkte anpreisen möchte, möchte ich nicht nxmxz-Kombinationen jedesmal neu anlegen müssen.

Wenn eine Option oder ein Optionswert für ein Produkt nicht verfügbar ist, wähle ich ihn einfach nicht für das Produkt aus.

Code: Alles auswählen

Master-Datensätze:
Größe:       XL, L, M, S
Farbe:       rot, blau, grün
Art:           DVD, CD

Auswahl, welche Optionen für welches Produkt zur Verfügung stehen sollen:
                  Größe  Farbe  Art
Produkt 1:   x         x        
Produkt 2:                        x

Auswahl, welche Optionswerte für welches Produkt zur Verfügung stehen sollen:
Größe:        XL     L     M     S
Produkt 1:   x       x            x

Farbe:        rot      blau     grün
Produkt 1:            x          x

Art:            DVD   CD
Produkt 2:  x        x

Angabe des Lagerbestands und des Preises pro Kombination:
Daten:
Farbe: blau
Größe:       XL         L          S
Produkt 1:  10/5€    2/10€   3/4€

Daten:
Art:           DVD       CD
Produkt 2:  25/1€     10/5€

Daraus ergibt sich übrigens, dass man die X-Dimension auswählen können muss (die anderen werden übrgeordnete Auswahl wie z.B. bei Daten: die Farbe). Mehr als 2 Dimensionen kann der Mensch halt (noch) nicht... :wink:

Sollte sich der Name einer Option oder die Beschriftung eines Wertes ändern, ändere ich es an einer Stelle und nicht für alle meine Artikel, da werde ich ja wahnsinnig (rot -> dunkelrot). Damit muss ich es auch nur einmal übersetzen...

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer »

HerrB hat geschrieben:Sollte sich der Name einer Option oder die Beschriftung eines Wertes ändern, ändere ich es an einer Stelle und nicht für alle meine Artikel, da werde ich ja wahnsinnig (rot -> dunkelrot). Damit muss ich es auch nur einmal übersetzen...
da gibt es halt schon mehr als eine sicht der dinge. zum einen musst du durchaus nicht hundert mal rot in dunkelrot ändern. und zwar unabhängig davon, ob es zentral ist oder nicht. in beiden fällen reicht dazu ein query.

aber was ist denn, wenn du diese änderung eben nicht in jedem fall machen willst, sondern nur bei ausgewählten shirts, die eine bestimmte bedingung erfüllen? dann musst du eben bei einer zentralen regelung zuerst rot in dunkelrot ändern (und du kannst das eben nicht nur für einen teil machen, bei der anderen lösung durchaus - und notabene immer noch mit einem einzelnen query). dann musst du eine zweite farbe oder option anlegen und diese dann den produkte zuordnen. und jetzt kommts: eben bei jedem produkt wieder und wieder.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB »

da gibt es halt schon mehr als eine sicht der dinge. zum einen musst du durchaus nicht hundert mal rot in dunkelrot ändern. und zwar unabhängig davon, ob es zentral ist oder nicht. in beiden fällen reicht dazu ein query.
Das ist so nicht ganz richtig. Denn in meinem Vorschlag (Master-Datensätze) ändere ich es im normalen Konfigurationsfenster (in dem ich auch die Optionen anlege) und die Änderung gilt automatisch überall.

Bei Deinem Konzept muss eine "benenne alle Felder um"-Funktion integriert werden - das klingt nach zusätzlichem Aufwand? Ist es auch.
dann musst du eine zweite farbe oder option anlegen und diese dann den produkte zuordnen. und jetzt kommts: eben bei jedem produkt wieder und wieder.
Yep, ich lege eine zusätzliche Farbe an und klicke 25 Checkboxen an (vielleicht gibt es da sogar eine "alle" Checkbox...) und fertig. Auch hier nutze ich die ohnehin vorhandenen Funktionen.

Aber wenn Du nicht willst, lass' es.

Dazu ist mir noch was eingefallen:
also zum preis wird auch die währung erfasst, in der die angabe erfolgt ist. bei der ausgabe wird die währung der preisangabe, der preis selber sowie die zielwährung berücksichtigt.
Das ist so IMHO noch nicht berücksichtigt, es sei denn, crossparity enthält den Faktor zu einem irgendwie definierten Standard. Beispiel: Produkt ist in Euro angegeben, Zielwährung ist Schweizer Franken - wie bzw. womit wird nun gerechnet? Deswegen der Vorschlag, eine Basis-Währung festlegen zu können ... (das würde den Standard definieren).

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer »

ich probiere das erd mal entsprechend anzupassen.

bezüglich der standardwährung: die ist einfach deshalb nicht nötig, weil kreuzparitäten eine standardwährung nicht benötigen. das heisst, diejenige währung, die eine kreuzparität von 1.0 aufweist, wäre dann im prinzip - wenn du so willst - die standardwährung. allerdings gibt es möglicherweise keine solche, wenn die daten aus einer externen quelle bezogen werden. die 'standardwährung' wäre dann eine, die es in wirklichkeit vielleicht nicht gibt und von der man annimmt, sie hätte einen wert von eins.

in der praxis ist das alles nicht so relevant. wenn der shop z.b. in deutschland beheimatet ist und alles in euro gerechnet wird, hätte euro eben eine 1.0 und alle übrigen währungen einen wert grösser oder kleiner null. letztlich kommt das einer standardwährung sehr ähnlich. im erd muss man diese allerdings nicht speziell angeben, da die rechnung in jedem fall gleich aussehen wird.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
php0815
Beiträge: 373
Registriert: Mi 26. Okt 2005, 12:12
Wohnort: Schwarzwald
Kontaktdaten:

Beitrag von php0815 »

Es ist schön das hier zu lesen das ihr auch gedanken über die Artikelnummer macht.
Habt ihr mal das cao-wawi programm angeschaut.
Da ist auch nicht so fiel drinn arbeitet mit osCommerce zusammen.
Ich meine Jeder sollte seine Artikelnummer machen wie er will.
Was ist drinn:
Kurztext, Kasse, Langtext, Info, Spezial

Suchbegriffe:
Suchbegriff, Artikel-Nr., Barcode/EA, ArtikelTyp

Zuweisungen:
Warengruppe, Herkunftsland, Lager-Ort, Hersteller, Hersteller-Art-Nr.

Einheiten/Konten:
Mengeneinheit, Rabattgruppe, Mwst, Dimension, Vertreter-Provision, Aufw.-Konto, Erlös-Konto, Inv.-Wert, Länge, Größe, VPE

Menge/Preis:
Mind.-Bestand, Bestand, Bestellbestand, Einkaufspreis, Listenpreis, Faktor, Brutto

Alles muß ja nicht dabei sein aber das ist die auflistung von CAO-Faktura
Eine angabe im Backend von-bis Artikelnummer was angezeigt werden soll.

Und die sache währe doch in Ordnung meine ich.
In der Ruhe liegt die Kraft den wer suchet der findet
Wer Rechtschreibfehler findet kann sie behalten, Codefehler können gemeldet werden.
HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB »

das heisst, diejenige währung, die eine kreuzparität von 1.0 aufweist,
Ok, das erklärts, dieses Detail hatte ich nicht verstanden.

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer »

erd-version vom 12.12.05

Bild

das erd ist noch nicht definitiv. aber jetzt ist die zuordnung von endlos vielen optionen zu jedem produkt möglich. und diese werden zentral verwaltet. die abfrage gestaltet sich jetzt jedoch eher schwierig; aber das ist lösbar.

ich wäre froh, wenn sich jemand findet, der ganze mal anschaut.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
llaron
Beiträge: 133
Registriert: Mi 14. Jul 2004, 12:54
Kontaktdaten:

Beitrag von llaron »

das sieht ja alles schon sehr gut aus – gibts denn schon ne version von dem shop..bzw. wann gibts die voraussichtlich? hätte gerade ein projekt, wo ich das nutzen könnte :-)

merci + grüße,
Nico
kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer »

wie du leicht fest stellen kannst, sind wir erst beim erd. alles andere kannst du dir vielleicht ausmalen.

einen zeitrahmen möchte ich noch nicht angeben. weil gemeldet haben sich zwar schon einige. aber sobald es konkret wird, melden sich dann in der regel nicht mehr so viele.

auf die frage, wer sich z.b. der produktklasse annehmen würde, hat sich bis dato niemand gemeldet.

by the way: wer wäre bereit, sich der produktklasse anzunehmen. und auch für den warenkorb (respektive dessen klasse) brauchen wir auch noch jemanden.

gruss,
andreas
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer »

wie sollte sich das eigentlich mit den preisen verhalten? sollte der preis bei einer optionskombination dazugezählt werden oder sollte dort ein preis angegeben werden, der direkt verwendet wird?
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB »

Da hätte ich keine Preferenzen, öhm ...

eigentlich war ich der Meinung, dass da noch was fehlte; ich habe jetzt drei Varianten geschrieben und schließlich ist mir aufgefallen, dass dabei das rauskommt, was Du oben beschrieben hast. Suuuuuuuper.

Folgende Vorschläge hätte ich noch:
- Ich würde in conShopOptionCombination noch fk_option Integer NN (PFK) ergänzen, das ist nachher praktischer und beschleunigt die Abfragen

- Ich würde nachher eine Standard-Option mit Standard-Optionswert definieren (pk_option = 0 mit pk_optionvalue = 0). Jedes Produkt sollte dann über diese Kombination verfügen - das würde es ermöglichen, ohne weiteres den Basispreis in conShopStock zu speichern und ermöglicht es auch, grundsätzlich einen Join mit der conShopOptionCombination-Tabelle durchzuführen (denn es ist ja zu jedem Produkt ein Eintrag vorhanden) - sonst müsste man erst prüfen, ob Optionen definiert wurden und dann entsprechend abfragen. Der Basispreis und Basislagerbestand wäre dann sto_price, sto_amount where pk_stock = fk_stock and fk_optionvalue = 0.

Ich finde es als Entwickler ganz praktisch, wenn ich für einen Wert (hier: Preis) immer nur in eine Tabelle gucken muss (deswegen auch der Vorschlag, price nach conShopStock zu verlagern).

Dabei würde es nach wie vor gehen, für eine Kombination den Endpreis oder einen Aufpreis zu definieren...

- Einführung der Tabelle conShopProductOptionValues:
fk_product Integer NN (PFK)
fk_option Integer NN (PFK)
fk_optionvalue NN (FK)

Das ermöglicht es, die verfügbaren Optionswerte pro Produkt zu begrenzen (ist für die Werte das äquivalent zu conShopProductOptions). Ich kann also z.B. festlegen, dass für die Tischplatte grundsätzlich schwarz und buche auf Lager sein könnten, für T-Shirts (gleiche Option "Farbe") aber kein buche, dafür aber blau und rot. Das macht es später bei der Definition der möglichen Kombinationen (Stocks) leichter bzw. schneller, da nur die gewählten Optionswerte überhaupt in Frage kommen.

Ansonsten: unglaublich, aber wir haben es, yeah, super Arbeit. :D

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB »

Ich habe nochmal nachgedacht: Ich denke, Aufpreis ist später einfacher. Gute Argumente habe ich keine (zumal man mit Optionspreis - Basispreis den Aufpreis jederzeit ausrechnen könnte), aber vielleicht macht es uns das irgendwann mal einfacher... (und da ich beides in conShopStock abbilden würde, machts aus meiner Sicht kaum einen Unterschied im Aufwand :wink: ).

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer »

HerrB hat geschrieben:Folgende Vorschläge hätte ich noch:
- Ich würde in conShopOptionCombination noch fk_option Integer NN (PFK) ergänzen, das ist nachher praktischer und beschleunigt die Abfragen
das bringt uns allerdings abhängigkeiten ins erd. ich kann die fk_option schon integrieren, allerdings können dann aktualisierungsanomalien auftreten. ich überlege mir das nochmals; aber tendenziell würde ich davon absehen. aber wie gesagt: ich schaue es mir nochmals an.
HerrB hat geschrieben:- Einführung der Tabelle conShopProductOptionValues:
fk_product Integer NN (PFK)
fk_option Integer NN (PFK)
fk_optionvalue NN (FK)
verstehe ich das richtig? für ein produkt wird also nicht nur definiert, welche optionen zur verfügung stehen sollen, sondern gleichzeitig auch, welche optionswerte innerhalb einer option auswählbar sind?

ich habe nämlich folgendes vor gehabt: für ein produkt werden die verfügbaren optionen angegeben. für jede denkbare kombination müsste ja der lagerbestand angegeben werden. ein positiver wert bedeutet, dass das produkt zurzeit an lager ist. 0 bedeutet, dass zurzeit das produkt nicht an lager ist. ein wert von NULL bedeutet, dass die gewählte optionskombination nicht verfügbar ist (also gar nicht gewählt werden kann). will man einen optionswert ganz ausschliessen, bleiben in der folge alle kombinationsmöglichkeiten dieser option leer.

ich werde mir das nochmals durch den kopf gehen lassen und publiziere dann nochmals ein erd.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
Antworten