Benötige Hilfe bei SQL-Befehl

[ludibubi]

Hallo zusammen und alles Gute für 2025

Im Office-Forum hatte man mir den Tip gegeben, hier mal nachzufragen

Es ist mal wieder Sale-Zeit und jetzt müssen bei vielen Artikel zu einer festgesetzten Zeit die VK-Preise geändert werden. Man kann in unserem Shopprogram (Oxid) vorgeben, wann der Preis auf welchen Wert geändert wird.
Allerdings ist das sehr mühselig, jeden Artikel einzeln aufzurufen und zu ändern.

Meine Idee: alle aktiven Artikel einer Kategorie (z.B. Pullover) nach Excel exportieren, in die entsprechenden Felder die Werte (Preis und Änderungsdatum) eingeben (kann man ja kopieren) und dann die Sachen wieder in die Datenbank importieren.

Ich habe Zugriff über phpmyadmin und mir die Tabelle oxarticles mal angeschaut.
Alle aktiven Artikel haben in der Spalte "OXACTIVE" eine 1.
Artikelbezeichnungen (z.B. Pullover) befinden sich in der Spalte "OXTITLE"

Wie müsste der SQL-Befehl lauten, dass ein Exceltauglicher Export (z.B. als ods-Datei) mit den Kriterien OXACTVE=1 und OXTITLE=Pullover erfolgt?

Wenn ich die Tabelle dann in Excel habe, kann ich in den Spalten "OXUPDATEPRICE" und "OXUPDATEPRICETIME" die erforderlichen Werte eintragen und würde dann über die phpmyadmin-Importfunktion die Tabelle wieder einlesen

Würde das so funktionieren?

Danke im voraus!

 

[akretschmer]

warum nicht gleicht ein UPDATE mit den Bedingungen im WHERE?

Wäre zu einfach, gell?

 

[ukulele]

Meine Idee: alle aktiven Artikel einer Kategorie (z.B. Pullover) nach Excel exportieren, in die entsprechenden Felder die Werte (Preis und Änderungsdatum) eingeben (kann man ja kopieren) und dann die Sachen wieder in die Datenbank importieren.

Theoretisch möglich. Allerdings:

1) Die meisten Anwendungen, dazu würde ich jetzt auch mal ein PHP Shop-System zählen, reagieren empfindlich auf Eingriffe in die Datenbasis von "Außerhalb" - also nicht durch sie selbst. Die Eingriffe müssten also wirklich genau dem Datenmodel entsprechen, es darf nirgendwo zu Inkonsistenzen kommen. Dazu muss man das Datenmodell genau kennen, sonst steht irgendwo an anderer Stelle noch der alte Preis und dein System macht sonderbare Dinge.

Es gibt kein allgemein gültiges System, jede Anwendung kann ihre eigene Suppe kochen. So wird z.B. Referenzielle Integrität häufig gar nicht von der Datenbank erzwungen weil die tollen Entwickler sich gedacht haben, da schreibt außer mir sowieso keiner rein und ich bin eh der geilste. Also definitiv ein Backup machen, Restore muss möglich sein, sorgfältig vorher alles anschauen und mit wenigen Daten testen.

2) Beim "Änderungsdatum" stellt sich direkt die Frage, steht das in der selben Tabelle "oxarticles"? Für mich gehört das da in einem sauber normalisierten Modell nicht hin, was, wenn es mehrere Updates zu mehreren Zeitpunkten geben soll? Also definitiv genau anschauen, ob das wirklich nur dort der eine Wert ist.

3) Alles in allem ist das einfach kein schöner Workflow. Was heute vielleicht funktioniert kann beim nächsten Update der Anwendung oder bei der nächsten Änderung der Daten schon nicht mehr funktionieren.

4) Excel kann dir deine exportierten Daten unaufgefordert zerschießen. Z.B. versucht Excel beim Öffnen, Werte zu interpretieren und beim Speichern schreibt es dann das da rein, von dem es glaubt, das es das sein soll. So werden aus Zahlen dann auch mal Datumswerte a la "2. Mär" oder Exponentialfunktionen, und dann knallt es wenn du das der Datenbank "gibst".

Ich habe Zugriff über phpmyadmin und mir die Tabelle oxarticles mal angeschaut.
Alle aktiven Artikel haben in der Spalte "OXACTIVE" eine 1.
Artikelbezeichnungen (z.B. Pullover) befinden sich in der Spalte "OXTITLE"

Wie müsste der SQL-Befehl lauten, dass ein Exceltauglicher Export (z.B. als ods-Datei) mit den Kriterien OXACTVE=1 und OXTITLE=Pullover erfolgt?

Nun zunächst einemal

SELECT * FROM oxarticles WHERE OXACTVE=1 AND OXTITLE='Pullover'

Wie das Ergebnis in eine Datei, noch dazu in ein spezifisches Format kommt, ist Sache deines Clients phpmyadmin. Ich würde annehmen, der macht nur CSV aber keine Ahnung. Für den Import gilt das selbe, du musst über den Client die Daten erstmal wieder einlesen. Am besten, in eine leere, neue Tabelle um dann die bestehende Tabelleper UPDATE und JOIN mit deinem Import anzupassen. Du solltest zu keinem Zeitpunkt die Daten aus der alten Tabelle löschen und / oder neue Datensätze anlegen, du musst ein sauberes UPDATE ausführen.

Wenn ich die Tabelle dann in Excel habe, kann ich in den Spalten "OXUPDATEPRICE" und "OXUPDATEPRICETIME" die erforderlichen Werte eintragen und würde dann über die phpmyadmin-Importfunktion die Tabelle wieder einlesen

Wie gesagt, kommt auf phpmyadmin an. Ich würde annehmen, "einlesen" bedeutet, komplette Datensätze schreiben. Daher bitte erst in eine neue, leere Import-Tabelle.

Würde das so funktionieren?

Ja. Wird nur eventuell scheiße.

Sollte die Anpassung der Preise einem Muster folgen, also z.B. alle Artikel -x %, dann solltest du in jedem Fall ein UPDATE gegen die Tabelle machen. Natürlich auch hier mit der selben Sorgfalt, aber eben ohne Export / Import. Beispiel:

UPDATE oxarticles SET OXUPDATEPRICE=OXPRICE*0.9, OXUPDATEPRICETIME=Termin WHERE OXACTVE=1 AND OXTITLE='Pullover'

(natürlich Vorsicht: Ich habe absolut keine Kenntnis von deiner Datenstruktur)

 

[dabadepdu]

Würde das so funktionieren?

Versuch es vielleicht mal im oxid forum

Deutsches Forum

In diesem Forum trifft sich die deutschsprachige Community und diskutiert alle Themen rund um OXID.

forum.oxid-esales.com