Suche Shopsoftware, wer hat Erfahrung?

Hi,
bin neu hier und auf der Suche nach einer geeigneten Shopware.
Wenn jemand mir einen guten Tipps geben könnte, wäre ich wirklich dankbar (Flasche Champus )
Ich lese soviel unterschiedliches, dass mir schon ganz kirre ist.
Max. Ausgabe für einen wirklich alles inkl Shop ca. 1000,-. Weniger wäre natürlich auch nicht schlecht.
Ich denke lieber vorher was ausgeben, als hinterher einer Krücke noch etliches hinterher zu werfen. Mal abgesehen vom Ärger .
In der Endphase sollten es mehr als 200.000 Artikel sein. Wenn es geht sollte ein sogenanntes ArtikelFeld (Aufpreis) für eine Gruppe, das täglich aktualisiert werden muss, wegen Veränderung des Marktpreises, anhand des Gewichtes, den Preis des Artikels bestimmen. Unabhängig aber vom Eigenpreis des Artikels. Preis wird bestimmt durch Grundpreis + Gewicht x Aufpreis. Falls es dieses Feld in einem guten Shop nicht geben sollte, könnte ich diese Artikelgruppe natürlich auch auf Preisanfrage stellen. Das wäre auch kein Problem. Händler und Endkundenpreis ist muss. Wichtig ist für mich die Performance wobei ich einen eigenen Server ins Auge fasse. Auch die Importfunktion und Exportfunktion z.B. über Access wäre klasse. Besser wäre natürlich eine interne automatische Abwicklung nach Felddefinition. Würde gerne Wawi von Lexware einsetzen.
Nun zu den Shops: Hoffentlich fühlt sich bei meiner Ausführung niemand auf den Schlips (oder Kleidchen) getreten . Ist nur meine eigene Betrachtungsweise, man möge mir verzeihen.

Habe mal Veyton installiert (momentan etwas langsam, liegt aber vielleicht auch an meinem mometanen Webspace.
JTL muss ich noch test (hat keinen Aufpreis für Artikel) und muss von der bestehenden Software halt übertragen werden)
ShoptoDate sieht klasse aus, vorallem das Design gefällt mir (nicht diese 3Spalten Aufteilung)habe aber gelesen, dass der ab 20 Bestellungen nix mehr wäre . Außerdem muss wie bei JTL übertragen werden.
Gamblo muss ich noch testen
FWP Shop sieht mega geil aus, ob´s alle Funktionen hat ?
epages zu teuer
Mietshop finde ich zu blockierend
Oxid Shop mal sehen
Mangento zu unausgereift für den hiesigen Markt denke ich
PHPPepper sagt mir nicht zu
genauso wenig wie Bigware.

So und jetzt weiß ich nicht mehr weiter.......
vielleicht aber ihr ?

Herzlichen Dank im voraus
Gabriele

...ob sich da jemand rantraut, 200.000 Artikel ist für die gängigen Systeme viel zu viel, da müsstest Du mit einem wirklich großen Server anfangen.

Möglicherweise wenn Du verschiedene Features (beispielsweise URL Rewriting) ausschaltest was aber eine Katastrophe der suchmaschinentechnischen Natur wäre.
Unser größter Shop liegt zur Zeit bei 330.000 Produkten, allerdings ist das Shopsystem darunter auch hochoptimiert. Allerdings bieten wir auch ausschließlich als Mietshop an!

Magento solltest Du gleich vergessen, da bräuchtest Du wohl mehr als einen Server um solche Größenordnungen verarbeiten zu können.

Ein preisveränderndes Tool anhand des Gewichts ist mir bislang noch nicht untergekommen, schätze mal da müsste man nachprogrammieren.
200.000 Datensätze solchermaßen täglich zu aktualisieren dürfte auch eine nette Aufgabe sein.

Access anzubinden ist ungewöhnlich, ginge bestenfalls per ODBC, webbasierte Systeme an eine lokale Datenbank anzubinden ist auch so eine Sache. Möglicherweise über einen Wrapper, aber der Abgleich funktioniert auch nur wenn die Access Datenbankstruktur perfekt geeignet wäre. Was (Achtung, Erfahrungswert) unwahrscheinlich ist da Du nicht wissen kannst was alles im Shop vorhanden sein muss.
Wie sieht es denn mit Alternativformaten (CSV oder XML) aus?

Ich fürchte ohne Mietshop wirst Du Dein Budget noch einmal überdenken müssen. Grundsätzlich würde ich eine Beratung anempfehlen, nur über Forumeinträge und ein bisschen Vertriebsstoff kann man bei so einem Projekt nicht zu einer tragfähigen Entscheidung kommen.

Btw. um was für eine Produktpalette handelt es sich denn?

dehansen hat geschrieben:Ich fürchte ohne Mietshop wirst Du Dein Budget noch einmal überdenken müssen. Grundsätzlich würde ich eine Beratung anempfehlen, nur über Forumeinträge und ein bisschen Vertriebsstoff kann man bei so einem Projekt nicht zu einer tragfähigen Entscheidung kommen

Das Budget sollte in jedem Fall noch einmal nach oben korrigiert werden.
Bei (mindestens) 200.000 Datensätzen brauchst Du in jedem Fall einen eigenen Server oder aber das System, für welches Du Dich entscheidest müsste im Nachgang so optimiert weden, dass es wirtschaftlich keinen Sinn mehr macht (insbesondere wenn man auch die Updatefähigkeit im Auge behalten muss).

Auch ich empfehle Dir vorab eine ausführliche Beratung, wenn nicht sogar ein bezahltes Workshop bei Dir vor Ort. Alles andere wäre Kinderkram und rausgeschmissenes Geld.

Das sind quantitative Größenordnungen die von vornherein zum Scheitern verurteilt sind, wenn man keinen Profi dazu nimmt. Man steckt Geld und Arbeit rein, es kommt nichts zurück und ist immer noch nicht fertig. Nachher ist das ganze um ein Vielfaches so teuer, als wenn man es am Anfang vernünftig gemacht hätte...

(Ach ja, willkommen im Forum )

shameless selfplug:

https://www.lopsta.com/2008/10/09/die-l ... hopsysteme

ich denke auch dein budget solltest du nochmal überdenken.
du brauchst auf jedenf all ein grundsolides verwaltungskonzept für deine 200K artikel.
ich würe mir da auch nen profi zur seite holen der das ganze konzipiert.

Vielleicht ist Satchmo was als Basis:

https://www.satchmoproject.com/

Ist ein Django Projekt und basiert somit auf Python. An Performance kaum zu überbieten und durch das Django Framework lässt es sich extrem schnell und damit kostengünstig entwickeln.

bara.munchies hat geschrieben:Vielleicht ist Satchmo was als Basis:

https://www.satchmoproject.com/

Ist ein Django Projekt und basiert somit auf Python. An Performance kaum zu überbieten und durch das Django Framework lässt es sich extrem schnell und damit kostengünstig entwickeln.

Geiles Teil! Kannte ich noch nicht, danke!

Ist aber sehr auf den amerikanischen Markt zugeschnitten wenn Du mich fragst, im Bereich Payment und Logistik in Europa schwierig zu handeln da die ein paar der wichtigsten Dienste fehlen.
Python ist nice, aber die Performance hängt weniger an der verwendeten Programmiersprache als an der Datenbank die bei 200k Produkten natürlich ordentlich gestresst wird.
Da benötigt man schon optimierte Strukturen die bei den wenigsten Standardsystemen vorhanden sind (Erfahrungen aus der Entwicklung des eigenen osC Forks).

Der Punkt ist das diese Strukturen nur sehr selten (gibt nicht viele die 200.000 Produkte online stellen) gebraucht werden und daher kaum in reguläre Entwicklungen kommen. Zudem verfügen nicht allzu viele Programmierer über die entprechenden Kenntnisse, was aufgrund der geringen Notwendigkeit im Normalbetrieb verständlich ist.

Wie auch immer, offenbar wird das die Beratung der Schlüsselpunkt ist.
Ich denke den gemeinsamen Nenner haben wir hier, nicht?

Wo wir Dich (Lopsta) gerade mal dabei haben, wann kommen denn die im Korrekturthread geposteten Korrekturen online?

dehansen hat geschrieben:Ist aber sehr auf den amerikanischen Markt zugeschnitten wenn Du mich fragst, im Bereich Payment und Logistik in Europa schwierig zu handeln da die ein paar der wichtigsten Dienste fehlen.

Das ist ein Framework, das erleichtert dem Programmierer die Arbeit. Ich spreche hier von einem einem speziell auf die Wünsche des OP programmierten Webshop. Inklusive Payment und was sonst noch alles. Ich hab die Tage wieder was mit xt:commerce machen müssen. Durch den Mangel eines echten Modulsystems in xt:commerce muss man eigentlich potentiellen Nutzern von diesem System abraten. Die "Hack the Core" Philosophie lassen mir echt die Nackenhaare aufstehen. Das selbe gilt leider für 95% der am Markt verfügbaren Systeme.

Um es klarzustellen, ich beite keine Arbeiten mit Django an, bin aber von dem was ich bisher kennengelernt habe schwer beeindruckt. Mit einem fähigen Coder können Projekte extrem schnell umgesetzt werden. Das existierende Ecommerce Framework beschleunigt das noch zusätzlich.

dehansen hat geschrieben: Python ist nice, aber die Performance hängt weniger an der verwendeten Programmiersprache als an der Datenbank die bei 200k Produkten natürlich ordentlich gestresst wird.

Das sehe ich anders. Die Performance hängt davon ab, wie die Datenbank gehandelt wird. Davon ab erläubt Django auch den Umgang mit PostgreSQL, was nochmal einen Performance Boost bringen kann. Plus einem ordentlichen Caching System.

dehansen hat geschrieben: Wo wir Dich (Lopsta) gerade mal dabei haben, wann kommen denn die im Korrekturthread geposteten Korrekturen online?

Wenn ich Zeit dafür finde. Dafür hab ich ja den Korrekturthread, da können Änderungen direkt eingtragen werden.

Womit sich die Frage stellt ob Gabriele einen Dienstleister findet der Ihr auf dem Framework einen Shop zurechtmachen kann. Da dürfte die Auswahl gerade recht eng werden denn Python ist nicht so verbreitet wie eben PHP. Was im Übrigen das Budget automatisch anheben und die Abhängigkeit vom Dienstleister vergrößern dürfte.

Sauber durchgeführte Hacks finde ich eigentlich nicht so schlimm. Zugegeben, wir haben auch den Vorteil unser System zentral zu pflegen und somit zu wissen was wann wo gemacht wurde, trotzdem, ich bin immer wieder erstaunt was man alles aus osC rauskitzeln kann wenn man weiß wie. Dazu gehört natürlich eine Menge Wissen um die Hintergründe und Realisierungsmöglichkeiten und nicht nur ein PHP/MySQL/xtC Kurs für Anfänger. Wir überführen die Hacks dann nach und nach in eine neue geordnete Struktur ersetzt zwar nicht gleich die Neuprogrammierung aber die wäre vom Aufwand her kaum zu stemmen.

Die Programmiersprache ist eigentlich fast komplett unwichtig, die Logik ist nicht allzu aufwändig und Berechnungen selten so kompliziert (es sei denn man hat die Dinge falsch aufgebaut, habe ich auch schon gesehen) das ernsthafte Performancezugewinne erreicht werden könnten. Die Datenbank ist und bleibt der Flaschenhals vor allem wenn man eine ordentliche Anzahl an Datensätzen hat. Was die Geschwindigkeitsvergleiche zwischen Postgres und MySQL anbelangt, ich sehe eigentlich eher Vorteile für MySQL. Wie auch immer, final sind Optimierungen an Datenbankstrukturen in Systemen wie Shops sehr viel effizienter als Codeoptimierungen da die meisten Lasten in die Datenbanken gelegt werden. Welche Schnittstelle für den Zugriff benutzt wird ist eigentlich fast egal (Hochlastsysteme mal ausgenommen), die Latenzzeiten mögen variieren, das sind jedoch wahrlich kleine Werte.

Btw., der oben erwähnte 330.000 Produkte Shop läuft performant zusammen mit ein paar anderen (kleineren) Shops auf einem gar nicht mal so groß dimensionierten Server. Und das auf einem System das ursprünglich mal ein osC war inkl. vernünftigem URL Rewriting jeder Menge Zusatzfunktionen und ohne aufwendiges Caching. Es geht also wenn man nur die richtigen Schrauben dreht.

Dazu muss noch gesagt werden das die aktuelle Hardwareentwicklung natürlich ganz neue Möglichkeiten zulässt, Mehrkernprozessoren und größere Speicher sind vor allem für Datenbanken eine wirklich feine Sache. Allerdings nur über Hardware zu skalieren wird auf Dauer auch eine teure Angelegenheit.

Eigentlich sind wir aber vom Thema abgekommen was sollte Sie denn nun ernsthaft in Betracht ziehen?

Ich muss Dir bei den Hacks auf heftigste widersprechen.
Hier mal ein Beispiel aus Drupal Ubercart, wie dort Module gehandhabt werden. Wer schonmal bei osc/xtc Erweiterungen nach Anleitung "eingehackt" hat wird schnell den Unterschied merken.

Ich möchte zum Beispiel ein neues Set von User Permisison anlegen für eine neue Funktion. Ich erstelle einfach eine Datei modulname.module mit fogendem Inhalt und lade es in das Modul Verzeichnis hoch. Noch eine Infodatei mit 3 Zeilen Code hinzu und fertig.
Das Modul lässt sich nun per Admin ein und aus schalten, die User Permissions sind in der Admin GUI aufzufinden, werden in der Datenbank gespeichert und stehen Shopweit zum Beispiel für Template Modifikationen zu Verfügung. Selbstverständlich nur ein kleines Beispiel. Aber man sieht das Konzept. Kommt ein Update, so führe ich das Update aus ohne dass Module betroffen sind.

"Hack the Core" hingegen hat das große Problem, dass ich Änderungen im selben Quelltext durchführen muss, der bei einem Update eventuell verändert wird. Kommt noch der Punkt dazu, dass sich diese Hacks eventuell noch gegenseitig beeinflussen. Bei Hooks and Filters ist das fast ausgeschlossen.

Ich kenne derzeit nur wenige Shopsysteme die dieses Konzept verfolgen.
Drupal Ubercart
Drupal Ecommerce
Magento
Veyton
Oxid Esales

Übrigens gibt bei Oxid im Developer Tutorial auch eine schöne Erklärung, warum das Core Hacking Prinzip nicht viel taugt:

A simple approach would be to directly change the function file where you need it. You could do this easily and it would work. The disadvantage is that you would change the shop's code itself. Every time you install an update, you would have to re-do all your customizations. You would have to double check line by line that your customizations were still working with the new release. This is very time-consuming and error-prone.

Back to Topic:

Da das Budget des OP scheinbar sehr begrenzt ist würde ich empfehlen mal die Oxid Community Edition genauer zu betrachten. Das ist der Open Source Ableger des bekannten Oxid Systems, mit allen für Deutschland nötigen rechtlichen Vorschriften. Die erwähnten Extra Funktionen müsste man dann erstellen lassen. Die Performance kann man ja mal auf einem Testserver ausprobieren bei 200K Artikeln.

Wie gesagt, bei einer zentralen Pflege ist das kein wirkliches Problem, wenn dagegen jeder an der Software herumbasteln kann schon.
Vom Konzept her hast Du daher natürlich recht, allerdings verlässt sich der Magento (oder was eben auch immer) Entwickler darauf das im System alles perfekt läuft und alle benötigten Hooks zur Verfügung stehen. Am Core wird somit von der Community tatsächlich kaum noch gearbeitet, was die Möglichkeiten dann doch irgendwann einschränkt.

Mir persönlich ist es wichtig Software die, wir wissen es alle, niemals perfekt sein kann auf meine Bedürfnisse anpassen zu können. Das betrifft überraschend oft (zugegeben, es war mal ein osC, der Unterschied zu Magento und Co ist da gewaltig, trotzdem, auch die Varien Jungs machen Ihre Fehler wie beispielsweise Performancemessungen ja gezeigt haben) auch Corefunktionen.

Daher meine klare Unterscheidung zwischen Usern die selbst am System bauen, da ist osC & Derivate für eine richtige Distribution eine nicht wirklich geeignete Angelegenheit und Systemen die zentral von jemandem der weiß was er tut gepflegt werden und der den STand für alle einstellt.

Für den Benutzer des Systems ist das alles ziemlich egal, wir bieten ein Mietshopsystem an, der Benutzer möchte das alles funktioniert, wie interessiert Ihn nicht.

Oxid könnte man in einer Testinstallation probieren.
Ich denke ein Hinweis auf die Folgekosten bei Benutzung der Oxid eFire Plattform wäre noch angemessen. Ist zwar nicht direkt im eigentlichen Budget drin sollte aber bedacht werden, was nützt eine Budgetberechnung für ein kostenloses System wenn es erst im laufenden Betrieb vergleichsweise hohe Kosten aufwirft.

Btw., ein netter Beitrag für Deine Liste, wieviele Produkte verträgt ein System auf einer bestimmten Hardware. Wobei die Daten kaum zu beschaffen sein dürften.

Naja, gegen die Zeit die du selbst in den Shop stecken wirst sind 1000 schon fast verschindend gering. Nimm also das System, welches dir am ehesten zusagt!