Folco (./25) :
Ta question initiale du "comment je fais", ça peut se résoudre de différentes manières, avec par exemple une table chronologique des mouvements, référençant les opérations d'ajouts, modifications et suppressions, chacune d'elle liée à une référence.

En matière de modélisation de base de données, le problème qui est soulevé ici fait référence aux formes normales.

En théorie, tu as raison : dans une BDD, on ne doit normalement avoir une information qu'une et une seule fois. Typiquement, dans ton cas, tu devrais avoir une table de références, et une tables d'E/S avec ta référence.

Table 1 - Référence
Code interne (que tu peux avoir deux fois : un code interne à la BDD, plus une référence métier)
Code objet fournisseur
Code fournisseur
Libellé court
Libellé long
Description
...

Table 2 - Mouvements de stock
Code interne
Numéro de série
Date d'entrée
Date de sortie
...

Si tu avais tout dans une seule table, tu reproduirais de façon inutile tout un tas de données (le code fournisseur, les libellés, la description...).

Dans la pratique, il y a tout un tas de situations où on ne le fait pas. Tout va dépendre du nombre d'occurrences de la chose répété et de l'utilisabilité.
Dans le cas présent, je ne vois pas ce qui pourrait défendre la solution de la table unique (sauf si tu n'as que très peu d'informations redondantes, mais en général, même s'il y en a peu au début, il y a toujours du monde pour vouloir en rajouter au fil du temps), sauf éventuellement à ne pas partir sur une base de données mais un tableau Excel (où les données peuvent être plus difficiles à manipuler lorsqu'elles proviennent de deux feuilles différentes).

Mais tu vas forcément te retrouver avec des situations où on fera le choix d'avoir de la donnée redondante, parce que ce sera plus simple à maintenir (ou parce que la structure de données pré-existante ne te permettra pas de le faire, ou encore parce qu'on t'aura mal expliqué à quoi ça correspond ).