Discussion :

[Papy Turbo]

Bonne question, bien sûr, mais à laquelle tu as quasiment répondu !
Tu indiques bien le principal argument en faveur d'une seule base : l'intégrité référentielle.
Si tu "splittes" la même base en 2 ou 3, tu la perds, donc tu dois gérer toi même, dans chacune des applications :
- vérifier que chaque clé étrangère existe dans sa table d'origine,
- en cas de suppression : à toi de gérer soit l'interdiction de supprimer, soit les suppressions en cascade...
Sachant, de +, que tes applications vont gérer plusieurs bases, donc plusieurs attaches...
Notre routine qui réattache les tables au démarrage sait le faire, mais quand même : simplifions autant que possible.

Si tu as des applications + des bases séparées, à toi donc d'estimer
1- le temps nécessaire (1 fois), pour les regrouper en une seule base cohérente + mettre en place une vraie intégrité + (éventuellement) supprimer le code inutile qui gérait cette intégrité...
2- le temps que tu vas perdre, à moyen et à long terme, pour gérer ces "bouts de ficelle mal attachés entre eux".
Dans l'immédiat, c'est toujours 2 le + facile : on continue à bidouiller sur l'existant.
Sur ne serait-ce que quelques semaines, c'est, à mon avis, toujours le 1 qui coûte (nettement) moins cher.

Il y a un seul argument que j'aie vu, en faveur du split : la limite en nombre d'utilisateurs simultanés.
Je n'ai encore jamais eu ce problème, mais j'ai vu une application complexe d'un collègue qui fonctionnait avec plusieurs bases reliées seulement dans certains cas.
Pour permettre 5 à 10 utilisateurs par département (production + commercial + compta + ...), chaque application a sa base propre.
Les éléments communs à ces bases sont encore dans d'autres bases, qui ne sont connectées qu'aux utilisateurs qui en ont besoin.
Je suppose que tu vois d'ici les problèmes pour syncroniser tout cela.

Mais ça marche.

[Papy Turbo]

Un très très grand merci à Serge qui a servi de cobaye pour cette première expérience de cours "en direct", et bien sûr à tous les membres du forum et ceux de l'équipe Access qui ont apporté leur soutien et leurs commentaires, directement ou par MP.

Nous nous sommes amusés pendant près d'un an et demi, à survoler, sans aucun plan, les divers aspects de construction et mise au point d'une application de gestion type, avec base de données et interface.

Je vais maintenant, pendant les semaines/mois qui viennent, réexaminer tout ça pour voir ce qu'on peut concrètement en retirer. En gros, un exemple d'application type avec
- un formulaire type, (plein d'autres sont possibles)
- un début de bibliothèque pour stocker du code et des objets réutilisables,
- un journal d'erreur qui enregistre les erreurs non prévues,
- un moteur de mise à jour de la base, qui peut aussi servir de point de départ pour toute synchronisation ou autre import/export de données entre 2 bases relationnelles (.mdb ou autres).
- etc.

Tous commentaires sont bienvenus, essentiellement sur les méthodes de travail, bien sûr (pour les questions techniques, il reste le forum )

À plus...