Ich frage mich, warum sowohl im Core als auch in vielen Plugins mit riesigen SQL-Queries gearbeitet wird, anstatt mehrere (viele?) kleine, aber dafür schnelle Queries zu verwenden. Das zieht Shops gerne runter, wenn der Traffic etwas höher ist.
Und nein, Caching ist keine Lösung, sondern nur Symptom-Verdeckung. Wenn die Caches zufällig genau dann expiren, wenn der Traffic hoch ist, kann es passieren, dass die Laufzeiten sehr hoch werden, Requests sich auftürmen etc, mit den allseits bekannten Folgen.
Also die Frage, vielleicht lesen ja Shopware-Coredeveloper mit, warum ist das so?
Weil große queries nicht immer pauschal langsamer sind, sondern weil sie optimiert oft sogar schneller und schlichtweg sinnvoller sind? Gib doch gerne mal ein paar konkrete Beispiele.
Da gibt’s so viele, hier ist einer. Leider nicht ganz.
SELECT
product_configurator_setting.id as product_configurator_setting.id,
?
FROM
product_configurator_setting
LEFT JOIN property_group_option product_configurator_setting.option ON product_configurator_setting.property_group_option_id = product_configurator_setting.option.id
LEFT JOIN media product_configurator_setting.media ON product_configurator_setting.media_id = product_configurator_setting.media.id
LEFT JOIN (
SELECT
product_configurator_setting.option.translation.property_group_option_id,
product_configurator_setting.option.translation.name as product_configurator_setting.option.translation.name,
product_configurator_setting.option.translation.position as product_configurator_setting.option.translation.position,
product_configurator_setting.option.translation.custom_fields as product_configurator_setting.option.translation.customFields,
product_configurator_setting.option.translation.created_at as product_configurator_setting.option.translation.createdAt,
product_configurator_setting.option.translation.updated_at as product_configurator_setting.option.translation.updatedAt,
product_configurator_setting.option.translation.property_group_option_id as product_configurator_setting.option.translation.propertyGroupOptionId,
product_configurator_setting.option.translation.language_id as product_configurator_setting.option.translation.languageId,
product_configurator_setting.option.translation.fallback_1.name as product_configurator_setting.option.translation.fallback_1.name,
product_configurator_setting.option.translation.fallback_1.position as product_configurator_setting.option.translation.fallback_1.position,
product_configurator_setting.option.translation.fallback_1.custom_fields as product_configurator_setting.option.translation.fallback_1.customFields,
product_configurator_setting.option.translation.fallback_1.created_at as product_configurator_setting.option.translation.fallback_1.createdAt,
product_configurator_setting.option.translation.fallback_1.updated_a...
Und was genau sollte daran jetzt langsam oder schlecht sein? Sieht mir nach einer automatisch generierten query des DAL aus. Solange hier keine m:n Beziehungen aufgelöst werden, sehe ich hier keine großen Probleme.
Ist ja noch human, da gabs schon wesentlich längere. Aber wenn man bestimmte Abfragen mit einem Query erreichen kann, anstelle von 20, dann ist das durchaus besser mit langen Query.
wenn man bestimmte Abfragen mit einem Query erreichen kann, anstelle von 20, dann ist das durchaus besser mit langen Query.Blockquote
Da ist in dieser Absolutheit nicht richtig. Wenn die lange Query nicht optimierbar ist, weil zu komplex, um passende Indexe anzulegen, kann es insgesamt viel ressourcenschonender und schneller sein, wenn man zumindest einen Teil des Queries in mehrere kleine, extrem schnelle Queries auslagert. Klar muss man dann Dinge im Code tun. aber trotzdem kann es insgesamt deutlich besser sein,
Selbstverständlich stört mich nicht die Länge an sich. Aber wenn ich Queries aus dem Core sehe, die trotz guter Hardware 2-3 Sekunden laufen, dann stört mich das schon. Dich nicht?
Das kannst du machen. Ich mache das durchaus auch bei Shops mit spezifischen Anforderungen.
Aber dann nutze ich kein DAL, sondern schreibe die Queries als SQL-Anweisung. Dadurch wird die Abfrage zwar schneller, aber an diesem Punkt hört es dann auch auf mit Erweiterbarkeit, externe Plugins „sorglos“ zu installieren oder aktualisieren.
Es ist immer ein Tradeoff zwischen Flexibilität und Optimierung.
Genauso könnte man zahlreiche Queries komplett streichen, wenn man weiß, dass man diese nicht benötigt. Deswegen ist Shopware Open Source, damit jeder individuell auf seine Anforderungen die Software anpassen kann.
Ja, ich dekoriere oder wenn nicht anders möglich erweitere/überschreibe Klassen. Im Shopware Core werden häufiger explizite SQL-Anweisungen verwendet, wenn DAL dies nicht bietet oder zu komplex ist.
Aber das ist gewiss keine Lösung für Shops, die auf Kompatibilität und regelmäßige Updates setzen.
Gleiche Diskussion hatten wir schon einmal hier im Forum und da kam der Vorschlag von @marco.steinhaeuser wegen des Repository. Entsprechender User hat es damals wegen Haftungsgründen, Aktualisierung, etc. abgelehnt.
Du kannst aber gerne solch ein Repository anlegen. Aber wie gesagt… dann muss es zuverlässig und regelmäßig gepflegt werden, von der Funktionalität nicht vom der CE abweichen und auch allen Sicherheitskriterien standhalten. Liest sich für mich eher wie ein Fulltime Job als ein freiwilliges Projekt nebenher.
