SQL Befehl für Preisupdate der Kundengruppen

[noRiddle (revilonetz)]

Die Werte erst zu löschen halte ich für schlecht weil dann die price_id, welche ja  ein AUTO_INCREMENT hat, immer höher geht. Auch müssen alle INDEXe neu geschrieben werden nach einem DELETE und INSERT.
Wo ist das Problem mit dem simplen UPDATE mittels JOIN, wie ich es erklärt habe ?

Meine Aussage

[...]
Wenn man auf products_id, quantity einen unique Index setzen würde könnte man sogar immer ein INSERT machen, mit
ON DUPLICATE KEY UPDATE.
[...]

Ist übrigens nicht richtig. Ein

Code: SQL  [Auswählen]

INSERT () VALUES () ON DUPLICATE KEY UPDATE...

kann man auch ohne weitere UNIQUE INDEXe machen, denn price_id hat ja einen PRIMARY KEY.
Z.B.:

Code: SQL  [Auswählen]

INSERT INTO personal_offers_by_customers_status_1 (products_id, quantity, personal_offer)
VALUES ((SELECT products_id FROM products WHERE products_model = '9072537'), 1 , 1.15) ON DUPLICATE KEY UPDATE products_id = VALUES(products_id), quantity = VALUES(quantity), personal_offer = VALUES(personal_offer);

Mittels der Syntax die oneQ geliefert hat könnte man so sogar alle nötigen Rows mit einer Query updaten.
Ich würde das INSERT O D K U allerdings nicht empfehlen, denn meines Wissens nach ist es langsamer als ein UPDATE mittels JOIN.

Es gäbe auch noch REPLACE INTO, was ich jedoch nicht empfehlen würde, denn es löscht erst den Eintrag um ihn dann neu zu schreiben, was 1., wie eingangs erwähnt, das AUTO_INCREMENT der price_id  immer höher werden lässt und 2. das DBMS zwingt jedesmal die INDEXe neu zu erstellen.

Die Entscheidung welchen Weg du nimmst würde ich davon abhängig machen wieviele Artikel es betrifft und wie oft du das machen mußt.

Hier nochmals meine Empfehlung, damit du sie nicht suchen mußt:

Code: SQL  [Auswählen]

UPDATE personal_offers_by_customers_status_X pobcs
  JOIN products p
    ON p.products_id = pobcs.products_id
   SET personal_offer = 1.23
 WHERE p.products_model = 'DerBesteArtikel007'
   AND pobcs.quantity = 1;

Gruß,
noRiddle

*NACHTRAG*
Bei sehr vielen betroffenen Rows (Artikeln) bei einem Preis-Update kann es das Ganze ein wenig schneller machen wenn du den INDEX auf products_model  UNIQUE machst (was er eigentlich ohnehin sein sollte).

[Q]

UPDATE war auch erst meine Überlegung, aber er will ja auch von 3 auf 2 Einträge runter. Weiß nicht, ob DELETE mit OFFSET funktioniert oder deckt das das DUPLICATE ON ab?

[Q]

Ok. Andere Idee mit der Reduzierung, wenn das immer das selbe Prinzip ist, also von 3 auf 2 Einträge und der neue 2. Eintrag < alter 3. Eintrag.

1. DELETE auf den Eintrag der > Maxwert ist
2. UPDATE auf Eintrag qty = 1
3. UPDATE auf Eintrag qty > 1

[Schreinermeister]

Hallo
noRiddle, BenQ

UPDATE war auch erst meine Überlegung, aber er will ja auch von 3 auf 2 Einträge runter. Weiß nicht, ob DELETE mit OFFSET funktioniert oder deckt das das DUPLICATE ON ab?

das war auch meine Überlegung. Von Seiten der Preiskalkulation ist ja nicht bekannt wie viele Einträge in der DB zu diesem Artikel vorhanden sind. Es gibt kein festes Schema. Die Anzahl der Einträge kann sich verringern, gleich bleiben, erhöhen oder komplett aus der personal_offers_by_customers_status_1 herausfallen.
Daher meine Überlegung mit dem Löschen und neu Eintragen der Werte.

Es würde auch immer nur einen Artikel betreffen.

Gruß Chris

[noRiddle (revilonetz)]

BenQ ???, bist du jetzt Taiwanese, oneQ  ?

[...]
Es gibt kein festes Schema. Die Anzahl der Einträge kann sich verringern, gleich bleiben, erhöhen oder komplett aus der personal_offers_by_customers_status_1 herausfallen.
[...]

Achso, hattest du das bereits erwähnt und es ist mir entgangen ?
In diesem Fall mußt du jedenfalls wirklich erst alle Einträge löschen und dann die neuen einfügen.

Wenn du sehr viele Artikel hast und das oft machen mußt solltest du irgendwann mal die AUTO_INCREMENT neu vergeben/sortieren, auch wenn es wohl einige Zeit dauern wird bis du den maximalen Wert von 2.147.483.647 für ein INT-Feld erreichen wirst.

Gruß,
Oli (aka noRiddle)

[Q]

BenQ ???, bist du jetzt Taiwanese, oneQ  ?

Hab den auch gefeiert 

Es würde auch immer nur einen Artikel betreffen.

Wenn das immer nur einen Artikel betrifft, lohnt dann der Aufwand? Das ist doch dann einfacher über das Backend.

[Schreinermeister]

Hallo noRiddle,
Hallo oneQ,
Hallo BenQ (falls es den irgendwo geben sollte, sorry) 

Durch eure Unterstützung hab ichs nun geschafft den SQL-Befehl für das Preisupdate in der Tabellenkalkulation zusammenzubasteln.
Hat sich aufwendiger gezeigt als ich dachte, da an alle möglichen Update-Variante gedacht werden muss.

Nochmals Danke für die Hilfestellungen.
Gruß Chris

[noRiddle (revilonetz)]

Da würde die Community bestimmt gerne deine Lösung sehen.
Nicht deine Excel-Formeln sondern beispielhaft die MySQL-Befehle.

Gruß,
noRiddle

[Schreinermeister]

Hi,

hier meine, für mich passende, Lösung zum Preisupdate einzelner Artikel.

bei einem Artikel welcher keine Staffelpreise haben soll wird folgender SQL-Code zusammengebastelt.
z.B. Art. Nr. 69934

Code: SQL  [Auswählen]

UPDATE products
SET products_price = 10.9538
WHERE products_model = "69934";

DELETE t1
FROM personal_offers_by_customers_status_1 AS t1
JOIN products AS t2
ON t2.products_id = t1.products_id
WHERE t2.products_model = "69934";
 

Bei einem Artikel mit Staffelpreisen sieht es aktuell so aus
z.B. Art. Nr. 69846 und mit drei Staffelungen

Code: SQL  [Auswählen]

UPDATE products SET products_price = 2.6281
WHERE products_model = "69846";

DELETE t1
FROM personal_offers_by_customers_status_1 AS t1
JOIN products AS t2
ON t2.products_id = t1.products_id
WHERE t2.products_model = "69846";

INSERT INTO personal_offers_by_customers_status_1 (products_id, quantity, personal_offer)
VALUES
((SELECT products_id FROM products WHERE products_model = '69846'),1,2.6281),
((SELECT products_id FROM products WHERE products_model = '69846'),5,2.2214),
((SELECT products_id FROM products WHERE products_model = '69846'),10,2.0114);
 

je nach Anzahl der Staffelungen wird der Befehl beim INSERT etsprechend erweitert.

Gruß Chris

[Schreinermeister]

Hallo zusammen,

bin da auf ein weiteres Problem gestoßen.

Wenn der Artikel Attribute hat wird durch den SQL-Code keine products_id gefunden, da products_modell in der products ja keinen Eintag hat, in diesem Fall müsste die produkts_id  aus der products_attributes in Verbindung mir der attributes_modell ausgelesen werden.
Kann solch ein Fall mit dem SQL-Code abgefangen werden?

Gruß Chris

[noRiddle (revilonetz)]

Was meinst du denn mit "abfangen" ?
Wenn du vorher bereits weißt, daß ein Artikel Attribute hat dann mußt du dein JOIN und dein Sub-SELECT einfach auf die Tabelle products_attributs  machen. Das wäre doch kein Problem, oder ?
Wenn du's nicht vorher weißt sehe ich keine Möglichkeit außer durch ein PHP-Skript.

Wen du die Befehle per Hand in der DB absetzt kannst du natürlich erstmal eine SELECT-Query auf die Tabelle products  machen und wenn da die Artikelnummer nicht gefunden wird auf die products_attributes.

Ich würde ja empfehlen das mittels Skript zu machen.
Z.B. eine CSV mit den Werten erstellen und sie von einem Skript in die DB vearbeiten lassen.

Gruß,
noRiddle

[Q]

Vermutlich nicht überall möglich und auch aus dem Kopf gerade etwa schwierig, aber theoretisch könnte man auch eine eigene Funktion in mySQL basteln, die erst die eine Tabelle prüft und wenn die NULL oder '' liefert, die zweite Tabelle prüft und die Product-id zurück gibt?