Fragen zur Datenbank

Shopware 5 Programmierung
1

Hallo zusammen,

 

Ich hab da mal ein paar Fragen zu den key id’s in den Datenbanktabellen:

Es geht um die Datentypen und Längen der Id’s.

  • Kann in s_media die ID < 0 sein? Wenn ja, warum?
  • Warum ist die media_id in s_articles_img 10± und nicht 11+ wie in s_media?
  • Warum ist die articleId in s_articles_informations 11± und nicht 11+ wie in s_articles?
  • Warum ist die articleDetailsID und articleID in s_articles_prices 11± und nicht 11+ wie in s_articles bzw. 11+ wie in s_articles_details

Das Selbe in translations mit articleID
oder
s_article_configurator_dependencies (configurator_set_id) und s_article_configurator_sets (id)

* ± vorzeichenbehaftet
* + vorzeichenlos

 

Und ich bin da noch nicht mal die ganze Datenbank durchgegangen.

Aufgefallen ist mir das Ganze, da ich für den Artikelimport/Update ein direktes (auf EF6 basierendes) Interface programmiere. (REST-API ist dafür einfach zu langsam)

Für eine Klärung bzw. auch Anpassung wäre ich sehr dankbar.

 

MfG

Algorithman

 

2

Hallo,

also erstmal zu s_media: Nein, die ID kann nicht kleiner als 0, weil auto_increment.

Der Rest von dem Vorzeichenbehfateten -und losen Zeug wird wohl darin liegen, dass es heute kaum jemanden mehr interessiert. Hatte selten jemanden gesehen, der darauf heutzutage noch Wert legt, außer vor mehr als drei Jahren mal in der CakePHP Dokumentation.

Habe ich das so richtig verstanden, Du willst mit C# mit dem Entity Framework 6 in die Shopware Datenbank Artikel Daten pumpen?

Eine Anpassung wäre wahrscheinlich mit einer Migration möglich, aber das soll uns mal @shopware‍ sagen. Wobei man ja IDs nie ändern sollte, mit solch einer Migration könnte man sich die Datenbank kaputt machen.

 

Edit: Was wahrscheinlich noch viel wichtiger ist: Die Datenbank war vor Doctrine da. Hatte schon öfters den Fall, dass man die Datenbank nicht anhand des Doctrine Schemas erstellen kann, weil Schlüssel etc. fehlen.

Edit 2: Wenn Dir die API zu langsam ist, dann probiers doch mal mit PHP 7, sofern nicht schon installiert. PHP 7 braucht nur halb so lange wie PHP 5 für dieselbe Aufgabe. Angaben laut iX und gemessen anhand von großen CMS Systemen. Falls Dir das immer noch zu langsam ist, dann kannst Du auch PHP mittels HipHop kompilieren. Wäre auch mal interessant zu erfahren, ob das mit Shopware geht.

 

MFG

derwunner

3

Habe ich das so richtig verstanden, Du willst mit C# mit dem Entity Framework 6 in die Shopware Datenbank Artikel Daten pumpen?

 

Ja, funktioniert prächtig, wenn man den ausgelegten ‚Fallstricken‘ aus dem Weg geht (Feld articleId in s_article_configurator_option_relations z.B. ist eine referenz zu einem s_articles_detail, nicht zu s_articles). Den Bildimport mach ich aber immer noch über den Cron von ImportExport Advanced, ist einfacher damit. Wir haben bei den Artikeln einen zu großen Wechsel, da muß alles direkt von der Warenwirtschaft exportierbar sein, ohne zusätzliche Handgriffe.

Edit: Was wahrscheinlich noch viel wichtiger ist: Die Datenbank war vor Doctrine da. Hatte schon öfters den Fall, dass man die Datenbank nicht anhand des Doctrine Schemas erstellen kann, weil Schlüssel etc. fehlen.

Ja, das mit den fehlenden foreigns hab ich auch schon bemerkt.

Die Api ist aber nicht nur zu langsam, auch kann ich nicht alles importieren. (Download-Dateien und Artikelbilder möchte ich gerne VOR den Artikeln importieren, damit das ganze ein bischen asynchron laufen kann).

Vielen Dank auch noch für den Tip mit PHP7, hab nicht gewusst, daß die so zugelegt haben bei der Geschwindigkeit. Werd ich mal in nem Debian Stretch über’s Wochenende ausprobieren.

 

MfG

 

Algorithman

 

4

Das was Du suchst, oder besser gesagt, was Du versuchst selber zu programmieren, macht Pickware bereits. Kostet allerdings einiges. Im Verhältnis zum Monatslohn einen Programmierers relativiert sich das ganze aber wieder.

5

Naja, wir sind ja gewachsen (osc -> oxid -> shopware), da ist die Artikelstruktur/Aufbau der Varianten schon ein bischen speziell.

  1. Warenwirtschaft und Online-Shop sind bei uns grundsätzlich getrennt, auf dem Online-Shop haben Daten von Distributoren und von Käufern, die hier in unserem Ladenlokal einkaufen, nichts zu suchen. Datenschutz geht da einfach vor. Da konvertier ich lieber :slight_smile: