Neu JTL-Shop - MySQL entfernen und stattdessen direkt mit MSSQL arbeiten?

[Bizzi]

Ich habe ein leidiges Thema mit der Synchronisation; Background- Worker hin oder her, warum arbeitet der Shop mit einer separaten Datenbank?

Ich möchte gerne das ganze nun selbst in die Hand nehmen und auf Basis von PHP direkt ein OpenSource-Shop erstellen, der direkt mit der MSSQL von der WaWi arbeitet... Die Verbindung klappt auch ohne Probleme, leider sehe ich da bei den ganzen Tabellen und Spalten kaum eine Möglichkeit, in relativ kurzer Zeit etwas auf die Beine zu stellen - Daher eine konkrete Frage:

Gibt es eine Dokumentation der MSSQL Datenbank und deren Einträge?
Insbesondere hätte ich gerne eine vernünftige Übersicht der Relationen der Spalten/Tabellen...

Was mir auch aufgefallen ist, dass JTL wohl etwas "komisch" arbeitet - Das sieht man daran, dass man keine Standards einhält, Spaltennamen in deutsch nutzt und vor allem nicht die CamelCase einhält. Es gibt zum Beispiel die Spalte tArtikelAttribut und dann wiederrum tartikeldownload... Warum werden Dinge "mal so" und dann wieder "mal so" genutzt? Gibt es bei euch überhaupt ein "Standard"? Das gleiche Thema ist mir auch beim betrachten der Source des Shops aufgefallen, wo sich mir die Fußnägel hochrollen...

 

[elevennerds.de]

Hallo,

hier findest Du eine Dokumentation der Datenbank: https://wawi-db.jtl-software.de/

Viel Spaß beim Programmieren!

 

[gre000]

Ich habe ein leidiges Thema mit der Synchronisation; Background-Worker hin oder her, warum arbeitet der Shop mit einer separaten Datenbank?

Da gibt es einige Gründe!
Beispiele:
Performance die Datenbank ist einfach sehr viel kleiner!
Nochmal Performance einige Werte werden von der Wawi live berechnet das dauert für einen Shop einfach zulang
Alle die eine langsame Internetverbindung haben können mit der Wawi nicht mehr richtig arbeiten!

Des Weiteren musst du selbst dann noch einen Cronjob haben dir alle Bilder aus der DB in einen Ordner speichert und die Bilder in verschieden Größen verarbeitet!

Ich möchte gerne das ganze nun selbst in die Hand nehmen und auf Basis von PHP direkt ein OpenSource-Shop erstellen, der direkt mit der MSSQL von der WaWi arbeitet...

OK da hast du dir aber was vorgenommen
Was stört dich denn so am Abgleich?

Gibt es eine Dokumentation der MSSQL Datenbank und deren Einträge?
Insbesondere hätte ich gerne eine vernünftige Übersicht der Relationen der Spalten/Tabellen...

Ja hier: https://wawi-db.jtl-software.de/

Was mir auch aufgefallen ist, dass JTL wohl etwas "komisch" arbeitet - Das sieht man daran, dass man keine Standards einhält, Spaltennamen in deutsch nutzt und vor allem nicht die CamelCase einhält. Es gibt zum Beispiel die Spalte tArtikelAttribut und dann wiederrum tartikeldownload... Warum werden Dinge "mal so" und dann wieder "mal so" genutzt? Gibt es bei euch überhaupt ein "Standard"? Das gleiche Thema ist mir auch beim betrachten der Source des Shops aufgefallen, wo sich mir die Fußnägel hochrollen...

Ich vermute das es an der Refaktorisierung liegt alle überarbeiteten Tabellen sind in CamelCase alle alten noch nicht!

 

[elevennerds.de]

Sicherheitstechnisch ist das was du machen willst ein fataler Fehler. In der Shop-DB sind Kundendaten verschlüsselt, du willst nun einen selbstgebauten PHP-Shop direkt an eine Warenwirtschafts-DB (das Rückenmark einer Firma) hängen. In der WAWI-DB sind keine Daten verschlüsselt, ein Angreifer hätte es hier sehr viel leichter an ALLE(!) Daten zu kommen.

 

[Bizzi]

Performance die Datenbank ist einfach sehr viel kleiner!
Nochmal Performance einige Werte werden von der Wawi live berechnet das dauert für einen Shop einfach zulang
Alle die eine langsame Internetverbindung haben können mit der Wawi nicht mehr richtig arbeiten!

Dies ist aber kein Grund - Man kann die Queries/Statements doch performieren, notfalls gäbe es die Möglichkeit Cached tables zu verwenden und bei INSERT/UPDATE zu aktualisieren. Wir reden hier von wenigen Millisekunden.

Des Weiteren musst du selbst dann noch einen Cronjob haben dir alle Bilder aus der DB in einen Ordner speichert und die Bilder in verschieden Größen verarbeitet!

Dies ist das geringste Problem.

Was stört dich denn so am Abgleich?

Es ist einfach unproduktiv, dauernd Daten zu synchroniseren. Für ein Kleinunternehmen vielleicht irrelevant, aber wenn man vielleicht etwas größeres vor hat, aber nicht unbedingt das nötige Kleingeld um SAP oder ähnliches an zu schaffen, dann muss man das ganze vielleicht etwas anders handhaben..

Ich habe noch so einige Ideen, die ich sicherlich umsetzen werde, neben dem Webshop der direkt mit der Datenbank arbeitet, möchte ich auch noch extra Kommi-Software für Scanner/Smartphones machen. Ich will mir natürlich jetzt nicht unbedingt als erstes einen 2.000 € Scnanner kaufen, die im übrigen mit einer simplen telnet-Verbindung arbeiten (Wavelink zum Beispiel), da braucht man einfach nur einen passenden Telnet-Server schreiben, was unter node.js vielleicht sogar relativ schnell geht, gerade für kleine Unternehmen könnte da auch mal schnell ein Smartphone herhalten (entweder dann mit Scan von Barcodes via Kamera oder eben, wenn das Smartphone unterstützt Beispielsweise OTG und einem separaten Handscanner für 20-30 €).

Naja, mal sehen, was ich da so auf die Beine stelle

Vielen Dank, auf jeden Fall erst einmal für die Links.

 

[Bizzi]

In der WAWI-DB sind keine Daten verschlüsselt, ein Angreifer hätte es hier sehr viel leichter an ALLE(!) Daten zu kommen.

Selbst in der MySQL-Datenbank vom Shop sind Daten in Plaintext vorhanden - Siehe als Beispiel beim Kunden die E-Mail Adresse, der Ort, das Geburtsdatum... Mag zwar sein, dass die Adresse selbst mit Blowfish verschlüsselt wird, der Rest ist dennoch einsehbar. Und wenn ein ungebetener Gast (bei euch vielleicht als "Hacker" bekannt, was eigentlich eine Fehlinterpretation ist) auf dem Webshop-Server bereits zugriff hat, kann er auch an der Config des Shops. Dementsprechend sind auch die Daten kompromittiert. Der Clou an der Geschichte ist mindestens eine saubere Programmierung, die es erst nicht ermöglicht SQLI oder XSS durchzuführen, das zweite ist eine saubere Serveradministration (keine Standardports, kein Access from everywhere, Absichern der Dienste...).

Aber das ganze kann man auch nur von jemanden erwarten, der Professionell ist. Ein Otto-Normal-Nutzer (wie vielleicht ihr oder einige von euch), die nur die Software "nutzen" vielleicht auch etwas HTML scripten oder mit Copy & Paste Code in PHP herumfuchtelt, braucht man da keine Standpauke halten

Im übrigen ist es ein anderes Thema mit diesen "Direktdaten" im Vertrieb selbst zu arbeiten, sprich, extra Software dafür zu entwickeln die intern genutzt werden; Das hat weder etwas mit dem Webshop selbst zu tun, noch ist es relevant ob hier diverse Daten "verschlüsselt" werden.

 

[elevennerds.de]

Separation ist ein wichtiges Prinzip in der Softwarearchitektur. Du gibst dieses Prinzip - ohne Not - auf und behauptest, mit "sauberer Programmierung und Administration" die Sache im Griff zu haben. Ich kann Dir dabei nur viel Glück wünschen!

Und, hast Du Dir mal die Änderungen der DB-Struktur zwischen den Versionen angeschaut? Da wird sich in den kommenden Versionen noch viel ändern.

 

[gre000]

Es ist einfach unproduktiv, dauernd Daten zu synchroniseren. Für ein Kleinunternehmen vielleicht irrelevant, aber wenn man vielleicht etwas größeres vor hat, aber nicht unbedingt das nötige Kleingeld um SAP oder ähnliches an zu schaffen, dann muss man das ganze vielleicht etwas anders handhaben..

Naja das verstehe ich nicht der Abgleich passiert doch komplett im Hintergrund! Was heißt denn was größeres?
Bitte erkläre mir die Vorteile eines solchen Shops?

Und, hast Du Dir mal die Änderungen der DB-Struktur zwischen den Versionen angeschaut? Da wird sich in den kommenden Versionen noch viel ändern.

Stimmt ist aber eines der schwächeren Argumente gegen dieses Mammutprojekt sonst gäb es auch kein LS PoS oder Unicorn2

 

[Uwe Jaksties]

Aber das ganze kann man auch nur von jemanden erwarten, der Professionell ist. Ein Otto-Normal-Nutzer (wie vielleicht ihr oder einige von euch), die nur die Software "nutzen" vielleicht auch etwas HTML scripten oder mit Copy & Paste Code in PHP herumfuchtelt, braucht man da keine Standpauke halten

Da fällt mir irgendwie ein Sprichwort ein. "Hochmut kommt vor dem Fall."
Aber trotzdem viel Erfolg. Sollte ja bei der geballten Professionalität kein Problem darstellen.

 

[Marc Völker]

Zu den Änderungen, haben die Entwickler von LS Pos Unicorn oder auch Victor ne menge arbeit das abzubilden.
Grundsätzlich sehe ich hier verglöeiche mit SAP, sorry, aber SAP? Das besitzt nicht mal ein eigenes Shop System! Sondern kommuniziert wenn dann mit anderen.
Schnittstellen zwischen ERP -> Shop sind Normal. Zudem ein Shop ganz viele andere Informationen vorhalten muss, die brauch die ERP nicht und will sie nie wissen, und umgekehrt.

Also direkt ein Shop an die Wawi db zu koppeln halte ich auch für ein Riesen Fehler.
Gerade wie auch Uwe nochmal mit dem Satz Professionell und Otto-Normal-Nutzer schreibt, Professional ist, Systeme zu trennen, und über saubere Schnittstellen zu verbinden, und eben nicht alles in einem System zu sammeln.

Also der Gedanke / die Idee dahinter graust mir mega. Aber jedem das seine.

P.S. Php und Mssql, weis nicht, find das ist kein Tolles Dreamteam. MSSql ist halt doch auch was mehr als nur ein Datengrab wie eine MySql.

Und ich kenne soviele Entwickler, die mit PHP arbeiten müssen, C# aber kennen, und einfach lieber mit so Strukturierten Sprachen arbeiten würden, weil es einfacher ist wirklich sauberen Code zu erzeugen.

Ansonsten sind alle Punkte hier genannt, die Defintiv gegen so einen Shop sprechen! Der Entscheidenste ist auf jeden fall der direkte Zugriff! Dann setz dich doch lieber hin, und Programmier deinen eigenen Abgleich! Das ist eine bessere Idee.

 

[mschop]

Das Zusammenspiel zwischen PHP und MSSQL ist OK. Aber da endet meine Begeisterung für die Kombination auch schon.

1. Es gibt deutlich weniger Bibliotheken für MSSQL als für PostgreSQL oder MySQL/Maria
2. Es gibt den einen oder anderen Fallstrick bei der Arbeit mit einer MSSQL. Z.B. gibt es Probleme bei der Nutzung von DateTime-Objekten in SQL-Queries. So muss man das genutzte string Format in dem Query als auch in PHP explizit angeben, da sich die MSSQL hier nicht an gängige Standards hält und je nach Lokalisierungs-Einstellungen auf dem Server unterschiedliche Formate erwartet.

Ich würde aber auch grundsätzlich davon abraten, dieses Projekt anzugehen:

Ein Shop muss zuverlässig funktionieren. Das Datenbankschema verändert sich regelmäßig und JTL wird dich nicht darüber informieren, wenn sich irgendwo etwas ändert. Das heißt du wirst wahrscheinlich jede Version sehr umfangreich testen müssen. Du wirst unterschiedliche Wawi-Versionen berücksichtigen müssen. Das wäre unglaublich komplex und zeitaufwändig, dass sauber hinzubekommen. Diese ganzen Probleme hast du bei einer separaten Software nicht. Hier müssen beide Seiten nur dafür sorgen, dass der API-Contract eingehalten wird.
Ich halte deinen Plan daher für unrealistisch.

Zudem ist die Wawi-DB ein Monster, mit dem man sich nur ungern herum schlägt. Ich würde mich hier viel lieber auf den Connector verlassen und mein Wunsch-Shopssytem oder halt den JTL-Shop verwenden.

Ich würde dir eher empfehlen, die Probleme im Abgleich anzugehen. Ggf. gibt es für deine Probleme Lösungen, die nicht deine komplette Zeit für die nächsten 12 Monate verbrauchen wird.

Gruß
Martin

 

[mh1]

Ich möchte gerne das ganze nun selbst in die Hand nehmen und auf Basis von PHP direkt ein OpenSource- Shop erstellen, der direkt mit der MSSQL von der WaWi arbeitet...

wenn sich dann deine Onlinekunden direkt gegen den SQL-Server authentifizieren hast du natürlich ein sehr interessantes Lizenzierungsmodell geschaffen.

D.h. die Nutzer, die sich (vielleicht aus Kostengründen 🤔 ) für deinen Opensource Onlineshop entscheiden, werden dann erstmal - wenn sie nicht mit Express auskommen - mit vier- oder fünfstelligen Lizenzierungskosten konfrontiert?


EDIT:
Oha - fünf Jahre alter Thread.... 😁
da hätt ich wohl vorher besser mal aufs Datum gekuckt

 

[Karalanta]

EDIT:
Oha - fünf Jahre alter Thread.... 😁
da hätt ich wohl vorher besser mal aufs Datum gekuckt

Es wäre aber trotzdem sehr interessant was daraus geworden ist... ¯\_(ツ)_/¯