Rah merde, ça a validé avant que je ne puisse finir...

Donc...
Cette solution ne permet plus de faire des opérations SQL simple de comptage (avec un SELECT COUNT). Par contre, elle te permet de gérer des opérations que tu n'as peut-être pas encore étudées à ce jour (typiquement, avec cette solution, tu peux avoir des opérations de type ENTREE, SORTIE, mais aussi INVENTAIRE, où tu fais un point à une date donnée sur l'état de ton inventaire).

Autre façon d'imaginer les choses : tu sais que tu n'auras que des opérations de type ENTREE ou SORTIE, du coup tu vires la colonne "Opération", et ta quantité te dis s'il s'agit d'une E ou d'une S (avec le signe).

Enfin, dernière façon : ton script transforme chaque entrée multiple en un nombre équivalent d'entrées E ou S, chacun pour un seul élément. C'est très verbeux, pas forcément optimisé, mais si tu veux faire des opérations via des requêtes, un SELECT COUNT sera plus facile (cela dit, ce n'est pas une solution que je recommanderais ; à mes yeux la première est peut-être la plus compliquée en terme de traitements complémentaires, mais la plus souple si ton application en vient à s'élargir).

Sachant qu'en plus, dans le cas présent, je ne peux que te conseiller soit d'avoir un timestamp à la place de la date, soit une colonne supplémentaire d'auto-incrément (pour la table E/S). Tout simplement pour ne jamais avoir deux lignes strictement identiques (sinon, tu peux vite galérer pour les opérations de suppressions ou de mise à jour de données : il te manquera un discriminant et c'est le meilleur moyen pour faire une fausse manip en impactant trop de lignes si tu as plusieurs opérations de même type réalisées sur un même produit).