Discussion :

[vba_lieb]

Bonjour à tous,

Alors tout d'abord, je débute et me lance dans la création d'une base de donnée...

J'ai commencé par étudier les relations. Mais je rame un peu car trop d'informations pour une bonne pratique de création d'une base de donnée.



Voici ce que j'ai fait:
Pour chaque produit qui arrive dans mon atelier (Numéro OF unique), j'ai des informations qui sont associés. Voir table OF_GENERAL.

J'ai créer pour mes besoins diverses tables comme REF_STATUS qui permet de pouvoir avoir une référence de statut à fournir à la table OF_GENERAL.

VOici ci-dessous les relations que j'ai mis en place.

Bon en fait, je ne sais pas par quel bout prendre tout cela. Si j'instruis dans ma table OF_GENERAL un nouvel OF (champ Number_OF), déja comment je peux avoir dans ma table TABLE_STATUT, le numéro d'OF ainsi que son statut qui s'instruit.

Bref, vous l'aurez compris, y a un truc que j'ai pas tout à fait pigé sur le mode et les bonnes pratiques à mettre en place une base de donnée Access...


Au plaisir de vous lire.

[EricDgn]

Bonjour,

Je ne vais pas donner des recommandations mais indiquer quelques unes de mes façons habituelles de procéder, résultats d'arbitrages entre divers avantages et inconvénients (et n'ai donc aucune objection à ce que d'autres aient d'autres avis).

Je donne des noms aussi courts que possible aux tables, champs, requêtes, formulaires et états. Les noms des champs reprennent en début le nom de la table. Si un champ d'une table est lié à un champ d'une autre table le nom du champ est construit en utilisant le caractère _ pour marquer le lien (j'évite d'avoir un même nom utilisé dans 2 tables différentes). Exemple ci-dessous: CltN° de la table tClt alimente Fct_CltN° de la table tFct.

Dans le graphe des relations je place systématiquement les côtés 1 à gauche des côtés N cela afin d'avoir une vision claire de la cascade d'alimentation des tables.
Pour moi l'avantage des noms courts est de rendre les codes VBA et les requêtes SQL plus lisibles (ou moins difficiles à lire).
En mode création de table, je complète systématiquement la "description" et la "légende" de chaque champ. Pour ce qui est des "liste de choix", je les exploite le plus souvent (= pas toujours).

Cordialement.

[vba_lieb]

Bonjour,

Je ne vais pas donner des recommandations mais indiquer quelques unes de mes façons habituelles de procéder, résultats d'arbitrages entre divers avantages et inconvénients (et n'ai donc aucune objection à ce que d'autres aient d'autres avis).

Je donne des noms aussi courts que possible aux tables, champs, requêtes, formulaires et états. Les noms des champs reprennent en début le nom de la table. Si un champ d'une table est lié à un champ d'une autre table le nom du champ est construit en utilisant le caractère _ pour marquer le lien (j'évite d'avoir un même nom utilisé dans 2 tables différentes). Exemple ci-dessous: CltN° de la table tClt alimente Fct_CltN° de la table tFct.

Dans le graphe des relations je place systématiquement les côtés 1 à gauche des côtés N cela afin d'avoir une vision claire de la cascade d'alimentation des tables.
Pour moi l'avantage des noms courts est de rendre les codes VBA et les requêtes SQL plus lisibles (ou moins difficiles à lire).
En mode création de table, je complète systématiquement la "description" et la "légende" de chaque champ. Pour ce qui est des "liste de choix", je les exploite le plus souvent (= pas toujours).

Cordialement.

Merci pour votre retour,

Bon j'avance : Voici mon fichier pour les mises en relations que j'ai établi :
BDD_ZIP.zip

Mon souci de compréhension, c'est maintenant que les relations sont en place, si je veux crée (pour mon exemple) un nouvel OF, il vaut que je crée mon code VBA pour dupliquer l'information sur les tables autres qui sont en relations ?

[nico84]

Bonjour,

Mon souci de compréhension, c'est maintenant que les relations sont en place, si je veux crée (pour mon exemple) un nouvel OF, il vaut que je crée mon code VBA pour dupliquer l'information sur les tables autres qui sont en relations ?

Quelques remarques en vrac :
- les relations sont là pour garantir la cohérence de la base de données, ce n'est ni obligatoire ni "normé"
- si on crée plusieurs tables liées c'est justement pour ne rien dupliquer ! Par exemple number_of ne devrait pas être dans la table des taches
- autant il est utile de préciser le niveau de priorité d'un OF pour pouvoir les trier, autant je ne vois pas à quoi peut servir une table des OF "urgents" ???
- les livraisons devraient être en liaison avec les commandes clients me semble-t-il (ou avec les OF supérieurs...)

[vba_lieb]

Bonjour,

J'ai au final corrigé quelques erreurs avec des confusions tables/requêtes

Voici ma nouvelle mouture :



N'hésitez pas à me dire si ça vous parait cohérent

Au plaisir de vous lire.

[EricDgn]

Bonjour,

Quelques petites suggestions. Pas possible d'en dire plus sans avoir une bonne connaissance de l'organisation de l'activité.

Cordialement.