Datenbank Import - artikel.csv größer 30MB

[Druckfehler]

Hallo zusammen,

ich versuche mich zum testen gerade an der Aufgabe, eine Datenbank mit 480 Kategorien und einen Stammdatensatz von rund 190.000 Artikeldaten zu initialisieren. Ich muss den Ursprungsdatensatz vom reinen Textformat sowieso umkrempeln, also Zeilenweise einlesen, umkonvertieren in ein CSV. Nun braucht der Import der CSV Datenbank pro 5 Datensätze ca. eine Sekunde. (Anfangs etwas schneller) *schnarch* ;o)

Ich kann suchen nach was ich will, ich finde zu dem Thema nirgends etwas. Daher hier die Frage: Gibt es nicht irgendwo eine Anleitung, Script, Idee, damit man das gleich ins SQL-Format bringen kann und sich dem Umweg über CSV spart, um es auf der Konsole in die Datenbank zu schreiben? Leider habe ich für Prestashop keine Beschreibung gefunden, die die Bezüge der Tabellen innerhalb der Datenbank einigermaßen, zumindest für mich sinnig, offenbart, so dass man hätte etwas eigenes konstruieren können.

Im Moment habe ich Version 1.7.6.3 im Einsatz. Wäre nett wenn ich zumindest ersten Input diesbezüglich bekommen könnte.

Danke

[wmunich]

Eieieiei da hast Du aber etwas vor Dir .... ich glaube nicht das Du da etwas brauchbares findest aber wenn gib mir bitte Bescheid!

ich würde den import einfach splitten denn die CSV in ein SQL Format zu bringen ist bei PS übelst komplex 🤣

Sorry ich weiß kein hilfreicher Tipp aber deine Lösung würde mich interessieren!

[Druckfehler]

Einfacher gesagt als getan. CSVs splitten, den Versuch habe ich heute Vormittag begonnen. Die ersten 65.000 Datensätze sind angelegt. Die zweiten 65.000 hat er nach nach der Überprüfung akzeptiert, beim übertragen in die Datenbank jedoch nach 6.000 Datensätzen mit unbekanntem Fehler abgebrochen. Schaun wir mal. Wird spaßig. ;o)

 

Für den Fall dass ich mal eine Lösung parat haben sollte, es wird hier ganz sicher eine Information geben. ;o)

Danke für die Hilfe.

[wmunich]

Naja eine Hilfe war ich Dir ja nicht wirklich aber ich dachte mir schon das Du in solche Probleme läufst. Würde hier auf max. 10-20k splitten, wenn überhaupt!

Wenigstens bist Du noch guter Dinge 😀 Drück Dir die Daumen!

[rictools]

Es gibt auf jeden Fall Module für den Import größerer Datenmengen, die TimeOuts durch Splitten vermeiden.

[Druckfehler]

6 minutes ago, rictools said:

Es gibt auf jeden Fall Module für den Import größerer Datenmengen, die TimeOuts durch Splitten vermeiden.

Na ich importiere inzwischen recht erfolgreich die Datensätze per SQL Datei. War ne Stunde Arbeit etwa, herauszufinden was Prestahop will und was nicht. ;o)

(Lösung gibt es etwas später, da fehlt noch etwas Dokumentation)

[Druckfehler]

Eine "kleine" Lösung, wie man den ganzen Import per CSV mehr oder minder "umgehen" könnte. Es ist nur(!!) ein entsprechend verarbeiteter Datenbankdump, kein Script, nichts vollzähliges. Die Doku ist im sql File. Ein bearbeiten der einzelnen Artikel im Adminbereich ist aber immer noch notwendig. Ich weiß nicht wie kleinteilig ich am Ende werden will. Es sollte aber möglich sein das ganze so weit zu treiben, dass man eine Datenbank ganz einfach konvertieren könnte und sofort, ohne Nacharbeiten, loslegen könnte.

 

Artikel-anlegen.sql

[SliderFlash]

Große Datenmengen sind für MySQL Dumper ist kein Problem

[Druckfehler]

13 minutes ago, SliderFlash said:

Große Datenmengen sind für MySQL Dumper ist kein Problem

Auch für einen Import von ca. 30mb großen CSV Dateien _IN_ die Prestashop Datenbank? Ich will kein Backup machen und auch keinen Restore. Ich will eine neue Datenbank anlegen mit 190.000 Artikeldaten.

[SliderFlash]

ja für MySQL Dumper kein problem große Datenbanken einzuspielen

[Druckfehler]

4 minutes ago, SliderFlash said:

ja für MySQL Dumper kein problem große Datenbanken einzuspielen

Und woher kennt dieses Script den Datenbankaufbau von Prestashop, um die CSV Dateien entsprechend zu verarbeiten? Vodoo?!

[Whiley]

Am 20.2.2020 um 9:49 PM schrieb Druckfehler:

Leider habe ich für Prestashop keine Beschreibung gefunden, die die Bezüge der Tabellen innerhalb der Datenbank einigermaßen, zumindest für mich sinnig, offenbart, so dass man hätte etwas eigenes konstruieren können.

Für den 1.6er Shop gibt es eine eine grafische Darstellung der Datenbank-Abhängigkeiten:

http://doc.prestashop.com/display/PS16/Fundamentals+of+PrestaShop+Development

Mit der Workbench-Version läßt sich vernünftig arbeiten.

Die Unterschiede zur Datenbank der 1.7er Version sind minimal siehe Post von japutko in diesem thread:

Grüsse
Whiley

 

[Druckfehler]

7 hours ago, Whiley said:

Für den 1.6er Shop gibt es eine eine grafische Darstellung der Datenbank-Abhängigkeiten:

*autsch*

Danke, das hatte ich in der Tat auch schon gefunden. Übersichtlich geht leider anders. Aber sei es drum, inzwischen habe ich das System so weit auseinandergenommen, dass ich zumindest den Datenimport schon mal per SQL INSERT usw. nachvollziehen kann. Auch das "leeren" des Shops (Reset in einen Urzustand ohne Inhalte), funktioniert schon mal.

Ich weiß ja nicht ob das hier überhaupt jemanden interessiert, wie man die Datenbank einfacher füllen/bearbeiten kann. Sonst setzte ich ein "gelöst" vor das Topic und wusel hier allein weiter. ;o)

[Wuschel]

1 hour ago, Druckfehler said:

*autsch*

Danke, das hatte ich in der Tat auch schon gefunden. Übersichtlich geht leider anders.

👍😂

Berichte mal ruhig weiter. Das ist durchaus von Interesse.

[Whiley]

vor 4 Stunden schrieb Druckfehler:

Ich weiß ja nicht ob das hier überhaupt jemanden interessiert, wie man die Datenbank einfacher füllen/bearbeiten kann.

Solche Projekte sind ja hier im Forum leider mehr als rar geworden, von daher sind Themen wie dieses hier natürlich immer willkommen!

Mir ist noch nicht klar wie du prinzipiell vorgehst.

Ich vermute, du bereitest die einzelnen Datensätze lokal auf und übergibst sie mittels http request an den Server, dort wird ein php-script (http get protocol) aufgerufen, daß die Daten übernimmt und in die mysql-Datenbank ( in die von dir inzwischen als relevant angesehenen Tabellen) schreibt?

Soweit ist das Projekt ja noch überschaubar, kompliziert wird es bei der Zuordnung von Varianten. Interessant auch die Frage wie du es mit den Bildern handhabst, genial wäre ja der Transfer der bereits optimiert erstellten Vorschaubilder unterschiedlicher Grösse in die richtigen Bild-Ordner.

Auf jeden Fall drücke ich dir die Daumen und um es nochmal zu wiederholen, Infos hier im thread wären super!

Grüsse
Whiley

 

[Druckfehler]

8 minutes ago, Whiley said:

von daher sind Themen wie dieses hier natürlich immer willkommen!

Gut, Danke, dann werde ich das mal tun. ,o)

9 minutes ago, Whiley said:

Mir ist noch nicht klar wie du prinzipiell vorgehst.

Also derzeit bin ich dabei mir alle Datenbankabfragen zu Gemüte zu führen, um zu erkennen was da überhaupt passiert. Die Last auf den Datenbankserver ist schon enorm. Meines Erachtens nach könnte gut 1/3 davon eingespart werden. Aber eines nach dem anderen.

Ich will also zuerst mal wissen wie die Daten verteilt sind, welche Abhängigkeiten benötigt werden und in welcher Form. So hat sich für mich z.B. schon ergeben, weswegen die Kategorien in der Tabelle ps_category_group immer mit Kategorie-ID und dann Drei verschiedener Werte in jeweils einer Zeile angegeben werden. Das regelt die Zugriffsberechtigungen der einzelnen Kategorien (Gruppenberechtigung). Der Eintrag sieht dann bei jeder Kategorie so aus:

INSERT INTO `ps_category_group` (`id_category`, `id_group`) VALUES ('11', '1');
INSERT INTO `ps_category_group` (`id_category`, `id_group`) VALUES ('11', '2');
INSERT INTO `ps_category_group` (`id_category`, `id_group`) VALUES ('11', '3');

Ein serialize ( mixed $value ) : string wäre an der Stelle viel flexibler. Die ganze Abfrage während des neu Anlegens mit Hilfe "import_cat.csv" sieht im übrigen bei jedem neuen Eintrag so aus.

## Kategorie anlegen
INSERT INTO `ps_category_shop` (`id_category`, `id_shop`, `position`) VALUES (11, 1, 0) ON DUPLICATE KEY UPDATE `position` = 0;
## Zugriffsrechte auf Kat-ID

## zuerst alles löschen
DELETE FROM `ps_category_group` WHERE id_category = 11;

## dann jede einzelne Berechtigung neu anlegen
INSERT INTO `ps_category_group` (`id_category`, `id_group`) VALUES ('11', '1');
INSERT INTO `ps_category_group` (`id_category`, `id_group`) VALUES ('11', '2');
INSERT INTO `ps_category_group` (`id_category`, `id_group`) VALUES ('11', '3');

Also hier ist eigentlich sehr viel Optimierungsbedarf. Nur so tief wollte ich eigentlich nichts in das System hinein schnuppern. ;o)

26 minutes ago, Whiley said:

Ich vermute, du bereitest die einzelnen Datensätze lokal auf und übergibst sie mittels http request an den Server, dort wird ein php-script (http get protocol) aufgerufen, daß die Daten übernimmt und in die mysql-Datenbank ( in die von dir inzwischen als relevant angesehenen Tabellen) schreibt?

Ich mache es im Moment so, dass ich per PHP-Script eine Textdatei mit den entsprechenden Datenbank-Daten einlese. Mit preg_match_all splitte ich die Datensätze im Textfile auf und generiere mit file_put_contens eine sql Datei. Diese kann ich dann auf der Konsole direkt in die MySQL-Datenbank einfügen. Die Beschreibung des Ur-Datensatzes findest Du hier:

 

34 minutes ago, Whiley said:

Soweit ist das Projekt ja noch überschaubar, kompliziert wird es bei der Zuordnung von Varianten. Interessant auch die Frage wie du es mit den Bildern handhabst, genial wäre ja der Transfer der bereits optimiert erstellten Vorschaubilder unterschiedlicher Grösse in die richtigen Bild-Ordner.

Korrekt, die Datensätze mit Artikelstammdaten und Kategorien ist noch recht überschaubar. Alles andere ist - zumindest für mich - für den Moment gar nicht so wichtig, da nichts derartiges existiert. Jeder Artikel müsste sowieso einzeln freigegeben werden, nachdem er bearbeitet worden ist. Selbiges gilt dann auch für die Varianten usw. Es ist halt Fleißarbeit, die ich hier bewerkstelligen muss. Die Ur-Datenbank gibt halt nicht viel her.

Das mit den Bildern habe ich mir noch nicht so genau angesehen. Mir genügt erst mal nur das Wissen, dass die kompletten Pfade inklusive URL zu jedem Bild in der Produktdatenbank stehen. Solch Vorgehen ist für mich schon arg gewöhnungsbedürftig, weswegen mich diverse Probleme mit dem Shop nicht wundern. Wobei ich da schon einen Gedanken hätte wie man das lösen könnte.

Das zurücksetzen in den Ausgangszustand mache ich inzwischen schon nicht mehr mit dem PrestaShop-Cleaner. Der löscht nämlich nicht alles sondern lässt haufenweise Datenmüll in der Datenbank verblieben. Wer etwas herum testen möchte, damit geht es sauber per MySQLAdmin.

TRUNCATE TABLE `ps_mail`;
TRUNCATE TABLE `ps_log`;
TRUNCATE TABLE `ps_layered_price_index`;
TRUNCATE TABLE `ps_category`;
TRUNCATE TABLE `ps_category_group`;
TRUNCATE TABLE `ps_category_lang`;
TRUNCATE TABLE `ps_category_shop`;
TRUNCATE TABLE `ps_product`;
TRUNCATE TABLE `ps_product_shop`;
TRUNCATE TABLE `ps_product_lang`;
TRUNCATE TABLE `ps_stock_available`;
TRUNCATE TABLE `ps_stock_mvt`;
TRUNCATE TABLE `ps_manufacturer`;
TRUNCATE TABLE `ps_manufacturer_lang`;
TRUNCATE TABLE `ps_manufacturer_shop`;
INSERT INTO `ps_category_lang` (`id_category`, `id_shop`, `id_lang`, `name`, `description`, `link_rewrite`, `meta_title`, `meta_keywords`, `meta_description`) VALUES
(1, 1, 1, 'Stammverzeichnis', '', 'stammverzeichnis', '', '', ''),
(2, 1, 1, 'Startseite', '', 'startseite', '', '', '');
INSERT INTO `ps_category_shop` (`id_category`, `id_shop`, `position`) VALUES
(1, 1, 0),
(2, 1, 0);
INSERT INTO `ps_category_group` (`id_category`, `id_group`) VALUES
(2, 1),
(2, 2);
INSERT INTO `ps_category` (`id_category`, `id_parent`, `id_shop_default`, `level_depth`, `nleft`, `nright`, `active`, `date_add`, `date_upd`, `position`, `is_root_category`) VALUES
(1, 0, 1, 0, 1, 12, 1, '2020-02-21 00:00:00', '2020-02-21 00:00:00', 0, 0),
(2, 1, 1, 1, 2, 11, 1, '2020-02-21 00:00:00', '2020-02-21 00:00:00', 0, 1);

Wie gesagt, ich arbeite mich langsam vor, ohne mich dem PHP-Code des Systems überhaupt zu nähern. Noch bin ich aber nicht so ganz durch. ;o)

 

 

 

[Wuschel]

Schau dir doch mal dazu @musicmasters PHP-Skript zur zur Übertragung des kompletten Datenbestands in eine andere Prestashop-Version an. Da hättest du dann schon mal alle erforderlichen Abhängigkeiten, die berücksichtigt werden müssen. 

 

[Druckfehler]

vor 9 Stunden schrieb Wuschel:

Schau dir doch mal dazu @musicmasters PHP-Skript zur zur Übertragung des kompletten Datenbestands in eine andere Prestashop-Version an

Spannend. Danke. Das hilft tatsächlich etwas weiter.