[mysql] somma su 2 tabelle

[yusizu]

Salve, avrei bisogno di una mano nella modifica di una query che mi sommi le quantità presenti in 2 tabelle:

SELECT A.*, A.Qty-SUM(B.qty) AS qty_tot  FROM A INNER JOIN
B. ON A.IDItem WHERE B.id_articolo=A.IDItem  AND B.mov='fix' 
GROUP BY A.IDItem  HAVING qty_tot>0

dove la tabella A contiene tutti i record degli articoli con una quantità iniziale mentre la tabella B solo gli articoli eventualmente movimentati (id_articolo=IDItem)

Il problema è che così facendo estraggo "solo" i record presenti nella tabella B mentre io dovrei estrarre cmq tutti i record presenti nella tabella A (se poi IDItem = id_articolo allora sommo le quantità (B) altrimenti avrò la quantità iniziale di A)


Grazie

[optime]

forse basta usare LEFT JOIN invece che INNER JOIN

[in the web]

Sì ma oltre a quello che dice optime c'è qualcosa di strano: se usi GROUP BY, non dovresti selezionare i campi non raggruppati. Il motivo è chiaro: se 10 record vengono raggruppati in uno solo, da dove dovrebbe leggere i dati che non sono presenti nella group by?
Infatti io consiglio a tutti di usare (tra le altre cose) il flag 'ONLY_FULL_GROUP_BY' di sql_mode.

[yusizu]

@optime con Left Join non va
@in the web non saprei come utilizzare il "flag 'ONLY_FULL_GROUP_BY'"

spero possiate aiutarmi, grazie

[in the web]

Ma prima devi capire concettualmente quello che ti ho scritto. La tua query è sbagliata da un punto di vista logico. Ripeto: se usi GROUP BY, puoi selezionare solo colonne aggregate (tipo MAX(nome_colonna)) o le righe che sono nominate nella GROUP BY. Se non capisci il motivo, vuol dire che non hai capito il funzionamento di group by, e in questo caso ti consiglio di studiarti un libro sulla teoria relazionale o almeno la documentazione di MySQL.

Purtroppo MySQL ti lascia libero di farlo, per default. Ovviamente questo non significa che si sia inventato una nuova operazione matematica che prima non esisteva, significa solo che ti dà un risultato a casaccio.
Ci sono molti altri casi in cui MySQL ti dà ragione come si dà ragione a un fesso, o al massimo di dà un warning, e poi fa quello che gli pare. Per esempio se definisci un campo come CHAR(1) e ci inserisci 'AAAAAAAAAAAAAAAAAAAAAAAAAAAA', lui ti dà solo un warning, e inserisce 'A'.
Credo che i default di MySQL 5.6 siano leggermente più rigidi (oltre a essersi finalmente accorti che normalmente un server non è un intel 386 con 64kb di ram... scusa la polemica) ma non abbastanza.

Per evitare queste situazioni idiote, io consiglio di mettere nel my.cnf:

sql_mode="ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_IN_DA TE,NO_ZERO_DATE,NO_AUTO_CREATE_USER,NO_ENGINE_SUBS TITUTION,ONLY_FULL_GROUP_BY,STRICT_ALL_TABLES,STRI CT_TRANS_TABLES"
innodb_strict_mode=ON

e nell'init file:
SET @@global.sql_warnings=1;

[yusizu]

Grazie lo stesso, ho risolto semplicemente aggiungendo un campo con la quantità aggiornata sulla tabella degli articoli...il resto lo fa il php,

P.S. nel post chiedevo una mano a "modificare" quella query non chiedevo se era corretta...lo sapevo da me che non lo era, ad ogni modo farò tesoro dei tuoi preziosi consigli

[in the web]

Non credo che il problema che hai descritto c'entrasse con il group by, ma se non l'hai corretto dubito che ti dia i risultati giusti...

[yusizu]

Ti rispondo ma senza polemica giuro:
ho scritto che ho risolto tagliando la testa la toro, ovvero inserendo la quantità aggiornata direttamente sulla tabella degli articoli per cui evitando di relazionare le 2 tabelle, il risultato è giusto e non potrebbe essere diversamente!

Non credo che il problema che hai descritto c'entrasse con il group by

ho per caso detto questo?? io avrei voluto semplicemente, con il vs prezioso aiuto, modificare quella query visto che non restituiva i risultati sperati

P.S. se si evitassero polemiche o consigli del tipo leggiti il manuale a fronte di un problema specifico, senza neppure conoscere le competenze di una persona, sarebbe cosa gradita, del resto nessuno è obbligato a rispondere ai post