INSERT en UPDATE combineren
- MERGE ... WHEN MATCHED ... WHEN NOT MATCHED ...?
- SELECT COUNT(*) voor een controle gevolgd door INSERT of UPDATE?
- DELETE gevolgd door enkel INSERT?
- try INSERT catch UPDATE met een exception?
Ik snap persoonlijk de behoefte niet.
Bij 99% van de gevallen heb je een primary index kolom, zeg maar even de kolom 'id'.
Is die nul dan INSERT plus $id = mysqli_insert_id; is die > nul dan UPDATE
Gewijzigd op 09/01/2015 17:31:39 door Frank Nietbelangrijk
MERGE is ook platform specifiek, Postgres heeft dat bv niet geïmplementeerd, die hebben daar weer schrijfbare CTE's voor.
Dat kan alleen niet altijd. Het gaat dan onder andere om de import van productfeeds.
Bestaat het product al, dan volgt de UPDATE van bijvoorbeeld de prijs en voorraad.
Bestaat het product nog niet, dan volgt de INSERT om het product toe te voegen.
De DELETE gevolgd door de INSERT, dank Ger, vond ik niet zo fraai vanwege het potentieel dataverlies en omdat bestaande data een nieuwe index krijgen, maar die moet het dan maar worden.
Gewijzigd op 09/01/2015 17:42:33 door Ward van der Put
Bij een productfeed kan je dit niet al niet doen, want dan bestaat de kans dat je een fk violation krijgt.
Wat ik doe is de data uit de feeds in tijdelijke tabellen pompen, en dan die tabellen en de officiële tabellen met elkaar synchroniseren.
En ja Frank die behoefte is er, dat is namelijk het verschil tussen 25000 query's vs 8 query's
Het is maar een gevoel dat bij me opkomt, ik heb geen ervaring met productfeeds.
Maar soms moet het toch automatisch, bijvoorbeeld wanneer je om de zoveel uur de actuele voorraadaantallen ophaalt.
Het bredere technische probleem is dat ik PDO gebruik om verschillende databaseplatforms te kunnen ondersteunen, maar ik *dus* ook geen queries wil schrijven die uitsluitend in MySQL werken. Liefst zie ik schone SQL die bij alle "main stream" databaseservers werkt, zodat je alleen de PDO-driver hoeft in te stellen.
Misschien moet ik er maar een extra methode voor schrijven die op basis van de PDO-driver de platform-specifieke implementatie gebruikt. Dat is, denk ik nu, dan nog het meest betrouwbare alternatief.
Een andere optie is om dat gedeelte naar een stored procedure te verplaatsen, dan leg je verschil daar waar het veroorzaakt wordt.