Multichannel eCommerce kommt uns in letzter Zeit ziemlich häufig unter. Dabei sitzt ein Cloud-ERP, plentymarkets beispielsweise, auf dem Warenwirtschaftssystem unseres Kunden auf und verteilt Produkte, Bestände und Preise in Vertriebsplattform wie Amazon, ebay, Zalando, Rakuten und auch den eigenen Onlineshop.
Wir hatten aktuell die Anforderung, dass unser Kunde eine EAN in der Warenwirtschaft bepflegt hatte und diese auch im WooCommerce-Shop als GTIN hinterlegt war. Damit konnte der Multi-Channel-Service-Anbieter, in diesem Fall cloudstock, wenig anfangen. Deren Software ist darauf ausgelegt Bestand und Preis der Artikel über die WooCommerce-Artikelnummer (SKU) abzugleichen.
Unser Kunde hatte nun die Wahl entweder alle EANs vom Azubi in das richtige Feld schreiben zu lassen, eine Umprogrammierung des Abgleichsverfahrens von cloudstock zu finanzieren oder SQL-Superhelden wie uns um Hilfe zu bitten. Da wir ausschliesslich mit Spitzenkunden arbeiten war die Entscheidung schnell gefallen:
Nachbesprechung
Bei WordPress ist eigentlich alles ein Beitrag (post) da es ursprünglich als Blogging-CMS gedacht war. Seiten sind eigentlich auch nur Beiträge ohne Taxonomie, also ohne Kategorien und Schlagworte. WooCommerce Produkte wiederum sind spezielle Beiträge (Custom Post Types) mit zusätzlich Preis und Bestand. Alle Post Types, Native und Custom, werden in der Tabelle wp_post in die Datenbank gespeichert. Zusätzliche Angaben zu den Beiträgen, SKU und GTIN der Produkte in diesem Fall, werden in die Tabelle wp_postmeta gespeichert. Dort finden wir also sowohl die GTIN von Germanized als _ts_gtin und die WooCommerce-native Artikelnummer als _sku.
Um nun den Wert von _ts_gtin zu _sku zu schreiben, machen wir einen sogenannten Selfjoin anhand der Beitrags-ID (post_id) da sich sowohl Quelle als auch Ziel in der selben Tabelle befinden. Wir wollen diese Operation nur bei Produkten ausführen und beschränkung uns daher auf Einträge die Überhaupt ein _sku haben.
Bei solch heiklen Operationen, die die komplette Datenbank zerstören könnten, ist es ausserordentlich wichtig den Prozess in einer Sandbox zu entwickeln und zu testen. Und bevor das Verfahrend dann im Produktiv-System appliziert wird ist sicherzustellen, dass der Zustand vor dem Ausführen des SQL-Statements wiederherstellbar ist. Unter Umständen durch
- Anschalten Wartungsmodus
- Sichern betroffener Tabellen
- Ausführen des Statements
- Ergebnis wie erwartet?
- Wiederherstellen der betroffenen Tabellen falls nicht
- Abschalten Wartungsmodus
Derartige Workflows sind absolut erforderlich bei Systemen die sich permanent verändern. Bei umsatzstarken Onlineshops bei denen kontinuierlich Bestellungen eingehen beispielsweise.
Das funktioniert übrigens nicht nur bei WooCommerce. Viele Plugins, und sogar WordPress selbst, speichern Informationen zum Beitrag häufig in den Metadaten. Und wer Manipulation auf Datenbankebene im Griff hat kann Aufgaben oft in Minuten erledigen die sonst Tage dauern und somit viel Geld kosten würden.
Wir hoffen wir konnten Dir SQL in Verbindung mit WordPress-Metadaten ein wenig näher bringen. Vielleicht ist dieser Beitrag ja der erster Schritt auf Deinem persönlichen Weg zum Datenbankmagier.
