Discussion :

[mascip]

Je suis un électricien qui aime utiliser des spreadsheets. Je créée un system sur Access + Excel pour m'aider à acheter des matériaux. En ce moment je les achète chez 7 fournisseurs. C'est surprenant comme chacun d'entre eux a des prix bas sur certains produits ou marques spécifiques, et des prix bien plus hauts sur d'autres, ce qui fait que ça vaut le coup de comparer les prix et d'acheter chez plusieurs fournisseurs.

Ma question est à propos de comment structurer ma base de données Access. J'ai deux idées, et c'est la première fois que je vais utiliser Access donc je n'ai pas d'expérience sur laquelle baser ma décision.

Mon idée numéro 1 est la plus facile: chaque ligne/enregistrement correspond à un produit, et chaque colonne/champ correspond au prix chez un fournisseur donné, comme ceci :

Référence produit | Fournisseur 1 | Fournisseur 2 | Fournisseur 3
001ABC | 10.50 | 9.90 | 7.20
0DEF5 | 1.10 | 0.7 | 1.15

Ça a l'avantage d'être très léger comme je ne retiens que le dernier prix pour chaque fournisseur, et c'est facile à chercher des produits et comparer leurs prix (lecture rapide). Mais ce n'est pas un format tabulaire comme ils sont recommandés dans Excel, et ça ne me permet pas de garder un historique des prix précédents, ce qui pourrait être pratique à avoir sous la main.

(Question : quel est le vocabulaire correct en français : ligne et colonne, ou enregistrement et champ ? Est-ce que les deux sont utilisés et compris par la communauté ?)

Mon idée numéro 2 est tabulaire : à chaque fois que j'obtiens un prix pour une produit, je l'ajoute comme un nouvel enregistrement dans la table. Et ensuite quand je veux lire les prix, il faut que je trouve le dernier prix pour chaque produit. Ça ressemblerait à ça :

Date d'entrée | Fournisseur | Référence produit | Prix
28/01/2026 | Fournisseur 1 | 001ABC | 10.50
28/01/2026 | Fournisseur 1 | 0DEF5 | 1.10
29/01/2026 | Fournisseur 2 | 001ABC | 9.50
29/01/2026 | Fournisseur 2 | 0DEF5 | 0.7
29/01/2026 | Fournisseur 3 | 001ABC | 7.20
29/01/2026 | Fournisseur 3 | 0DEF5 | 1.15
30/01/2026 | Fournisseur 2 | 001ABC | 9.90

Je pourrais aussi ajouter un champ pour les numéros de facture par exemple, et possiblement d'autres informations, par example des Notes pour expliquer pourquoi j'ai eu une promotion sur un article dans cette facture parceque je l'ai commandé en grande quantité.

Je voudrais avoir une meilleur idée des avantages et désavantages de chaque approche, et des conseils sur laquelle choisir.

Voici un peu plus de contexte :

• en ce moment j'ai une table Excel avec 200 produits, et j'imagine qu'avec le temps j'en aurait 1000 ou davantage. Et pour rappel j'ai 7 fournisseurs en ce moment ; ce nombre pourrait augmenter mais pas trop ;
• j'imagine que j'aurai... je ne sais pas, peut être 100.000 à 1.000.000 entrées par an dans la base de données (avec l'idée numéro 2). Je n'ai aucune idée de si c'est beaucoup ou peu pour Access et Excel, et si ce système risque de devenir lent ou pas ;
• pour certains fournisseurs je peux obtenir automatiquement en ligne une liste de prix pour tous les produits de mon choix. Par contre pour d'autres fournisseurs ils me tappent ces prix manuellement, donc je ne peux pas leur demander de remplir la liste très souvent. Pour ces fournisseurs en général j'obtiens les prix "petit à petit" à chaque facture que je demande et reçois. Je vais devoir créer un système pour entrer ces données dans la base de données facilement ;
• je commencerai avec une base de données Access sur mon ordinateur, mais idéalement à l'avenir j'aimerais avoir cette base de données online, pour pouvoir y accéder n'importe quand et de n'importe où.
  

Tout feedback, idées et suggestions sont les bienvenues, merci pour toute aide :-)




--------MESSAGE ORIGINAL EN ANGLAIS (je pensais en anglais au moment où je l'ai écris, je n'ai pas fait attention que j'étais sur un forum français) -------

I'm an electrician who loves using spreadsheets. I'm creating an Access+Excel system to help me buy materials. At the moment, I buy them from 7 different suppliers: It's surprising how each of them has much lower prices on some specific products or brands, and much higher prices on others, which makes it worth comparing prices and buying from different suppliers.

My question is about how to structure my Access database. I have two ideas, and it's the first time that I'm going to use Access so I don't have any experience to base my decision on.

My idea number 1 is the easiest: each record corresponds to a product, and each field would be the price at a specific supplier, like this:


Product reference | Supplier 1 | Supplier 2 | Supplier 3
001ABC | 10.50 | 9.90 | 7.20
0DEF5 | 1.10 | 0.7 | 1.15

It has the advantage of being very lightweight and easy to search for products and compare prices (fast read time). But it's not a tabular format as recommended in Excel, and it doesn't allow me to keep a history of previous prices, which could come in handy.

My idea number 2 is tabular: every time I get a price for a product, I enter it in the table. And then when I want to read the table, I have to find the latest price for each product. It would look like this:

Date of input | Supplier name | Product reference | Price
28/01/2026 | Supplier 1 | 001ABC | 10.50
28/01/2026 | Supplier 1 | 0DEF5 | 1.10
29/01/2026 | Supplier 2 | 001ABC | 9.50
29/01/2026 | Supplier 2 | 0DEF5 | 0.7
29/01/2026 | Supplier 3 | 001ABC | 7.20
29/01/2026 | Supplier 3 | 0DEF5 | 1.15
30/01/2026 | Supplier 2 | 001ABC | 9.90

I could also add a field for Invoice numbers for example, and possibly other information, for example some Notes about why in that invoice I got a bargain on a specific product because I bought a bigger quantity.

I would like to get a better idea of the advantages and disadvantages of each approach, and some advice on which one to choose.

Here is a bit more context:

- Right now I have a table in Excel with about 200 products, and I'm guessing over time it might grow up to 1000 products or more. And as a reminder I have 7 suppliers at the moment; this number might grow a bit but now much.
- For some suppliers I can get a list of prices for all my products online automatically. While some other suppliers have to type me the prices manually, so I can't ask for the full list of prices very often. For these suppliers I mostly get the prices "little by little" in each invoice I ask for. I will have to create a system for entering data in the database easily.
- I am guessing that I might get... I don't know, possibly 100,000 to 1,000,000 entries per year in the database (with idea number 2). I have no idea whether that's little or a lot for Access and Excel, and whether that might slow things down much or not.
- I'm going to start with the database in my work computer, but ideally in the future I would like to have this database online so I can access it any time from anywhere.

Any feedback, ideas and suggestions are very welcome, thank you for any help :-)

[marot_r]

Hi, as I don't know why you have posted in English on French speaking forum I am to answer in French first, an English version will follow.

Bonjour.

La bonne réponse dans une base de données relationnelle est la seconde.

C'est la seulle qui te permet d'exploiter pleinement les fonctionnalités de la BD.

Par exemple trouver le prix minimum pour un article parmis plusieurs fournisseurs ce fait avec une simple requête de regroupement sur le min.

Si tes prix sont dans des colonnes (champ) différentes alors il te faut autant de requêtes que de colonnes et ensuite une requête pour regrouper les requêtes.

Note que par contre ce n'est pas forcément la plus agréable à utiliser pour un humain :-).

Ce que tu peux faire pour la présentation est d'utiliser les requêtes croisées dynamiques (il y a un assistant dans Access pour cela) pour présenter un truc du genre.
Article, Prix 1, Prix , ... , Prix N.

Même chose pour la saisie, tu peux présenter les données sous format Article, Prix 1, Prix , ... , Prix N en utilisant une table temporaire de saisie mais ensuite tu écris les données sous forme
Article, Fournisseur, Prix.

Pour la place utilisée c'est celle qui prend le moins de place et note qu'une BD Access ne peut pas dépasser 2Go. On peut tricher en faisant plusieurs BDs mais ça complique les choses.
====

Hello,

The correct answer in a relational database is the second one.

It’s the only option that allows you to fully take advantage of the DB’s features.

For example, finding the minimum price for an item among several suppliers can be done with a simple grouping query on MIN.

If your prices are stored in different columns (fields), then you need as many queries as there are columns, and then an additional query to combine the results.

Note, however, that this is not necessarily the most user‑friendly structure for a human. :-)

For presentation purposes, you can use dynamic crosstab queries (Access has a wizard for this) to display something like:
Item, Price 1, Price 2, …, Price N.

The same applies to data entry: you can display the data in the form Item, Price 1, Price 2, …, Price N using a temporary input table, but then you store the data as
Item, Supplier, Price.

For the used space, this is the best. And be aware that an Access database is limited to 2GB. It is possible to work around this but it makes things more complicated.
======

A+

[marot_r]

Re-bonjour.

Autre astuce pour les prix que j'utilise c'est d'avoir une date de début et de fin du prix, ce qui permet facilement de trouver le prix valide à une date donnée.

Un truc du genre
tblPrix

DateDebut (valuer par défaut 1901-01-01)
DateFin (valeur par défaut 9999-12-31)
CodeProduit
CodeFournisseur
Prix

Ha again.

Another trick I used for my prices is to have a Start and End date for a price. This allow for an easy retrieval of a price for specific date.

Something like
tblPrice

StartDate (default value 1901-01-01)
EndDate (default value 9999-12-31)
ProductCode
SupplierCode
Price

[mascip]

Wow, merci beaucoup pour ces réponses très claires :-) Va pour la deuxième solution alors. Elle a l'air plus complexe de premier abord, mais je me disais qu'elle avait l'air plus "correcte" aussi. Ce format "dépivoté" est recommandé pour les tableaux Excel.

Et merci pour l'astuce de la date de début et de fin, ça parait bien pratique effectivement. La date de début c'est facile: c'est quand j'entre le prix dans la DB. Par contre la date de fin, je ne peux l'indiquer qu'une fois que je rentre les données suivantes. Au moment où j'ajoute des données, il y a un mécanisme qui permet d'aller modifier l'entrée précédente?

Il me reste à apprendre Access et le SQL. C'est parti!

PS: j'ai écrit en anglais par inadvertance: on parle 3 langues à la maison et je ne me rends plus toujours compte de quelle langue j'utilise. En particulier cette fois j'étais en train de lire en anglais, donc c'est le l'anglais qui est sorti au clavier. Merci pour la compréhension. Je vais traduire le message original en Français tout de suite.

[escartefigue]

Bonjour

Effectivement, la première solution est à bannir, dans une base de données, il ne faut jamais répéter les colonnes, et les attributs de chaque ligne doivent dépendre fonctionnellement de l'identifiant de cette ligne.

Ensuite, la modélisation est une conséquence directe des règles de gestion, il faut donc commencer par rédiger celles-ci pour être certain de ne pas s'engouffrer dans une impasse, je vous suggère de consulter ce fil de discussion quant au formalisme à adopter pour plus de clarté concernant ces règles de gestion.

Enfin, stocker les prix des produits par fournisseur, c'est bien, mais à condition de s'assurer que ceux-ci restent valides, comment avez-vous prévu de mettre à jour la BDD ?
100 000 à 1 000 000 de lignes par an, ça exclut définitivement une saisie manuelle.

À ce sujet :

quel est le vocabulaire correct en français : ligne et colonne, ou enregistrement et champ ? Est-ce que les deux sont utilisés et compris par la communauté ?)

Dans une table d'une base de données relationnelle, on parle de lignes et de colonnes.
Le champ est une zone de saisie d'un formulaire ou une zone de restitution sur un état.
Un enregistrement est une occurrence de ligne dans un fichier.
Toutefois, dans la documentation Access, il y a très souvent confusion entre colonne et champ, parce qu'Access est non seulement un SGBD-R (assez pauvre) et une interface de saisie qui propose des formulaires.
Dans ces formulaires, les noms des champs sont les mêmes que les noms des colonnes de la table sous-jacente. Mais c'est un abus de langage, champ n'est pas colonne

[mascip]

Merci escartefigue pour ces conseils et clarifications de vocabulaire. Tu me fends le coeur

J'ai compris qu'il faut que j'apprenne à créer un MCD.

Pour la mise à jour des données, j'obtiens de la part des fournisseurs des fichiers CSV avec références produits et prix correspondants. À priori avec ce format de base de données il me suffira d'ajouter (append) ces données à la base de données, avec les infos supplémentaires qui vont avec: numéro de facture s'il y en a un, date, etc. Il faudra que je créée des "commandes" pour cela (en SQL, j'imagine). Jusqu'à maintenant j'utilisais Power Query pour faire ça semi-manuellement dans Excel.

Au niveaux des dates, la suggestion de marot_r me parait très bonne: indiquer pour chaque prix sa date de départ et de fin. Mais pour cela il faut pouvoir indiquer la date de fin d'un prix, au moment où l'on ajoute le prix suivant pour ce même article chez ce même fournisseur. Comment fait-on ce genre de chose en SQL (ou sur Access)? C'est au moment de l'UPDATE qu'il faut indiquer une modification d'une ancienne donnée (qu'il faut aller retrouver)? Tout indice m'intéresse. Et sinon je trouverai bien comment faire le moment venu.

Et finalement il faudra que je créée mes queries SQL pour obtenir les informations qui m'intéressent (comparaisons de prix, évolutions de prix, etc).

Pour l'instant ce projet est au ralenti: je suis sur 2 gros chantiers de maisons où je fais toute l'installation électrique, j'ai peu de temps pour ce projet de base de données ce moins ci; bien que j'y cogite souvent :-) Son temps viendra. D'ici là je pense, j'apprends, je le prépare. Merci beaucoup pour votre aide!

[marot_r]

Bonjour.

Au niveaux des dates, la suggestion de marot_r me parait très bonne: indiquer pour chaque prix sa date de départ et de fin. Mais pour cela il faut pouvoir indiquer la date de fin d'un prix, au moment où l'on ajoute le prix suivant pour ce même article chez ce même fournisseur. Comment fait-on ce genre de chose en SQL (ou sur Access)? C'est au moment de l'UPDATE qu'il faut indiquer une modification d'une ancienne donnée (qu'il faut aller retrouver)? Tout indice m'intéresse. Et sinon je trouverai bien comment faire le moment venu.

Il n'y a pas mécanisme automatique pour mettre à jour la date de fin quand on ajoute une nouvelle date de début.
Le mécanisme en place dépend aussi un peu de comment tu mets à jour cette donnée.
Par exemple si c'est à la main via un formulaire de saisie tu peux avoir du code VBA qui va changer la valeur.
Sinon on doit pouvoir faire une requête de mise a jour qui cherche tous les enregistrements pour le code article qui ont une date de début inférieure à la nouvelle date de début et dont la date de fin est 9999-12-31.
Il faudra expérimenter un peu mais l'idée est là.
Perso j'avais toujours des volumes de mise à jour faible donc le faire à la main était assez simple.

A+

[mascip]

Merci pour ces informations Il faudra que je me renseigne sur comment automatiser ça. Si quelqu'un lit ça et sait comment faire, merci pour tout indice.
J'imagine que ça se passera au moment du UPDATE, et je me demande si ça aurait à voir avec les Triggers... Il va falloir que j'apprenne.

Mais en premier il faudra que je créée le MCD. Je mettrai une update ici quand je l'aurai fait.

En attendant je n'ai pas avancé concrètement, mais je me suis renseigné et il semblerait que SQLite serait mieux indiqué que Access. Et je pense utiliser Beekeeper Hive comme front end pour cette base de donnée.

[Robert1957]

Bonjour mascip, marot_r,
Il n'est pas vraiment nécessaire d'avoir une date de fin saisie. On peut utiliser la date de début suivante moins 1 jour comme exemple pour avoir notre date de fin. Voici un exemple qui reprend un peu votre besoin:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT T_Produit.Nom_Produit, 
    T_Fournisseur.Nom_Fournisseur, 
    T_Produit_Fournisseur.AppelationFournisseur, 
    T_Prix_Produit_Fournisseur.Date_Debut AS Date_Debut, 
    DateAdd("d",-1,(SELECT Min(Date_Debut) AS MinDeDate_Debut FROM T_Prix_Produit_Fournisseur AS T1 WHERE T1.Date_Debut > [T_Prix_Produit_Fournisseur].[Date_Debut] AND T1.Produit_Fournisseur_FK =  [PRODUIT_FOURNISSEUR_ID];)) AS Date_Fin, 
    T_Prix_Produit_Fournisseur.Prix
FROM ((T_Produit_Fournisseur 
    INNER JOIN 
T_Prix_Produit_Fournisseur ON T_Produit_Fournisseur.PRODUIT_FOURNISSEUR_ID = T_Prix_Produit_Fournisseur.Produit_Fournisseur_FK) 
    INNER JOIN 
T_Produit ON T_Produit_Fournisseur.Produit_FK = T_Produit.PRODUIT_ID) 
    INNER JOIN 
T_Fournisseur ON T_Produit_Fournisseur.Fournisseur_FK = T_Fournisseur.FOURNISSEUR_ID
ORDER BY T_Produit.Nom_Produit, T_Fournisseur.Nom_Fournisseur, T_Prix_Produit_Fournisseur.Date_Debut;

Et le résultat aurais l'air de ça:


Bonne soirée

[marot_r]

Bonjour Robert1957

Il n'est pas vraiment nécessaire d'avoir une date de fin saisie.

Tout à fait ce n'est pas nécessaire mais ça facilite les recherches et la performance quand on a pas mal de données.
Et la requête est franchement plus simple.
Tu as juste à faire un truc du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from taTable where taDate between dateDebut and dateFin

.
A+

[Robert1957]

Bonjour marot_r,

Je ne suis pas certains pour les performances, je travaille plutôt avec Access comme "Front-End" et SQL serveur comme "Back-End". Les performances pour une table de plus de 100 000 lignes sont très bonnes.

Pour la complexité des recherches, une fois qu'on a créé la requête du post #9 et sauvegarder celle-ci "R_ListeDePrix" on peut utiliser la requête que tu proposes dans le post #10 comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from R_ListeDePrix where taDate between dateDebut and dateFin

Le principe est de minimiser le traitement des données. Plus il y a d'opérations à faire et plus le système est lourd à tenir à jour.

C'est une question de préférences...

Bonne journée

[marot_r]

Bonjour Robert1957
Pour les performances, j'avais fais une solution sembable à la tienne sur un BD Access/Access il y a un paquet d'années et c'était d'une lenteur effroyable, d'où l'idée de début et fin.
C'était pour un planing d'utilisation de véhicules et je ne me souviens plus des volumes mais ce n'était simplement pas utilisable.
Mais comme tu le dis c'est une histoire de préférences, de volumes et d'intuitivité perçue.

[EricDgn]

Bonjour,

Plutôt que d'avoir à travailler sur des dates début et fin, il me parait plus indiqué d'avoir un champ PrixActif de type Oui/Non (Oui par défaut, mis à Non quand un nouveau prix est encodé) ... ce qui ramènera la requête à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select * from R_ListeDePrix where PrixActif

Cordialement.

[mascip]

Merci pour ces échanges d'idées :-)

Pour l'idée de la date de fin, je me demandais si une des deux solutions est objectivement meilleure que l'autre et j'ai peut-être trouvé la réponse: si la date de fin est indiquée dans une colonne, ça ne viole le principe d'unicité de l'information il me semble? La date de début d'un "nouveau prix" correspond à la date de fin du prix précédent. Avoir cette information répétée est dangereux, non? Que fait-on si à un moment ces deux dates ne collent pas, s'il y a un conflit introduit dans la base de données?

Et puis comme le dit Robert1957, une fois que la requête est sauvée on a toujours accès à la date de fin de chaque prix: on peut recréer cette colonne à tout moment.

Le prix actif, je pense que c'est pareil (?) : tout prix qui n'a pas de date de fin est le prix actif.

Niveau performance je n'ai aucune idée de ce que ça donne... mais niveau principe on ne veut pas que la même information soit répétée plusieurs fois, non?

Je n'ai pas du tout eu le temps de plancher sur ce projet récemment, mais je l'ai souvent en tête. J'y reviendrai prochainement.

[User]

Bonjour,

Pour simplifier, si on part d'une table des prix :

T_Prix (ID_Prix, Prix_Unit, Date_Entree, ID_Produit, ID_Fournisseur, ..)

Un scénario possible dans un formulaire Access :

1) Lors de la création d'une facture, après la saisie de la référence du produit (ou de son id) dans le détail de la facture, je pourrais avoir une liste déroulante (alimentée par une requête) permettant de faire un choix parmi les derniers prix des différents fournisseurs pour ce produit : le prix choisi est alors enregistré dans le détail (faut-il une marge ?) :

Pour avoir la requête SQL qui permet d'afficher automatiquement le prix le plus récent pour chaque produit chez chaque fournisseur, ça devrait pas poser de problème requête que l'on la filtre ensuite sur l'ID_Produit qui a été choisi.

Avec la possibilité aussi d'ajouter le dernier prix d'un fournisseur (dans la table T_Prix) depuis la facture en cliquant sur un bouton avant de choisir le prix dans le détail.

Cdlt