Concurrence MS Access (MDB)

Question

Pour un petit projet, j'ai besoin d'utiliser une base de données simple avec des exigences très légères : quelques tables, pas plus de quelques milliers d'enregistrements au total, 2 ou 3 utilisateurs. Je travaille dans un environnement .NET.

Comme un serveur de base de données (même les éditions Express) semble être une surcharge énorme dans ce cas, une base de données MDB très simple pourrait répondre à la plupart des besoins. Je suis cependant préoccupé par la concurrence. Mon idée est de placer le fichier .mdb sur un partage réseau et de laisser les utilisateurs accéder à ce fichier à partir de leurs clients .NET. La base de données est principalement destinée à des opérations en lecture seule, mais les utilisateurs devront occasionnellement mettre à jour/supprimer des enregistrements. Si cela n'est pas possible à ce moment-là (parce que la base de données est verrouillée ou autre), je peux conserver les mises à jour sur le client et les traiter ultérieurement.

La question elle-même va dans ce sens :

• Comment les lectures simultanées sont-elles gérées dans MDB ?
• Comment les mises à jour/suppressions simultanées sont-elles gérées dans les MDB ?
• Existe-t-il un concept de verrou et comment puis-je l'exploiter dans une application .NET ?
• Placer le fichier MDB sur un partage réseau est-il une bonne ou une mauvaise idée ?

Comme je travaille en .NET, j'aimerais également savoir comment détecter tout problème de concurrence et prendre les mesures appropriées. Par exemple, quelle exception dois-je attraper et quelle action me recommandez-vous de prendre ?

EDIT : C'est peut-être ma mauvaise description du problème, mais la plupart des réponses semblent conseiller d'opter pour un serveur de base de données complet. Je comprends les différences et les avantages de l'installation d'un serveur et j'ai en fait mis en œuvre un bon nombre de projets sur MSSQL et Oracle. Dans cette question, cependant, je ne suis concerné que par Access et ses problèmes de concurrence, donc s'il vous plaît ne suggérez pas un serveur de base de données.

Merci pour votre aide.

Answer 1

C'est une vieille question, mais personne n'y a jamais répondu. Voici les questions :

1. Comment les lectures simultanées sont-elles gérées dans MDB ?
2. Comment les mises à jour/suppressions simultanées sont-elles gérées dans les MDB ?
3. Existe-t-il un concept de verrou et comment puis-je l'exploiter dans une application .NET ?
4. Placer le fichier MDB sur un partage réseau est-il une bonne ou une mauvaise idée ?

Une seule explication suffit pour répondre aux deux premières questions. Une mise en garde importante : les réponses que je donne ici sont spécifiques aux MDB Jet (et leurs variantes) et ne s'appliquent pas complètement au nouveau format de fichier introduit à partir de A2007, c'est-à-dire le format ACCDB. Je n'ai pas entièrement exploré les implications de la suppression de Jet ULS de l'ACE et certains des commentaires ci-dessous peuvent supposer Jet ULS sous le capot. Pour beaucoup de choses, cependant, vous pouvez remplacer "fichier LACCDB" par "fichier LDB" et les résultats seront les mêmes.

1-2) lectures/mises à jour/suppressions simultanées

Le moteur de base de données Jet est souvent considéré comme une base de données "serveur de fichiers" dans la mesure où il n'y a pas de démon côté serveur qui gère les E/S avec les fichiers de données sur le serveur. Cela signifie que tous les clients utilisant une MDB Jet lisent directement le fichier.

C'est, bien sûr, une recette pour le désastre s'il n'y a pas un mécanisme intégré pour gérer l'accès simultané au fichier.

Jet utilise un fichier de verrouillage des enregistrements. Si votre MDB est "MyFile.MDB", le fichier de verrouillage des enregistrements se trouve dans le même dossier et s'appelle "MyFile.LDB". Le fichier LDB enregistre les utilisateurs de Jet ULS qui ont le fichier MDB ouvert, la station de travail à partir de laquelle l'utilisateur est connecté, et toutes les informations nécessaires pour négocier les problèmes de concurrence.

Maintenant, pour ceux qui ont fait leurs dents sur les moteurs de base de données client/serveur, cela peut sembler primitif et dangereux, mais à l'époque où le moteur de base de données Jet a été développé, son but était d'être utilisé comme un moteur de base de données de bureau pour les petits groupes de travail, et il était en concurrence avec d'autres moteurs de base de données de bureau comme xBase et Paradox, qui utilisaient tous deux des fichiers de verrouillage analogues pour gérer l'utilisation simultanée de fichiers de données de plusieurs clients.

Dans un fichier de base de données Jet, les verrous sont appliqués soit sur les pages de données (qui dans Jet 4 sont passées à 4K, alors que dans Jet 3.x et avant, elles étaient de 2K), soit au niveau de l'enregistrement si la table de données a été créée à l'origine pour utiliser le verrouillage au niveau de l'enregistrement. Dans les premiers jours de Jet 4, le verrouillage au niveau de l'enregistrement a été trouvé par beaucoup comme étant assez lent, en particulier lors de l'utilisation du verrouillage pessimiste, de sorte que beaucoup de développeurs Access n'ont jamais utilisé autre chose que le verrouillage au niveau de la page (@David Fenton lève la main !).

En fait, lorsque vous utilisez le verrouillage optimiste, vous évitez la plupart des problèmes de concurrence qui se posent avec le verrouillage pessimiste.

Quelques mises en garde :

1. à partir de DAO, le verrouillage au niveau des enregistrements n'est pas disponible, et vous n'obtenez jamais que le verrouillage au niveau des pages.

2. à partir de DAO, il existe un certain nombre d'options pour contrôler le verrouillage optimiste/pessimiste, en particulier l'argument LockEdits de la méthode OpenRecordset, mais qui interagit également avec certains des paramètres spécifiés dans l'argument OpenRecordset Options (par exemple, l'option dbReadOnly ne peut pas être utilisée avec LockEdits). En plus du verrouillage, il existe également des options pour les mises à jour cohérentes/inconsistantes, et tout ceci peut interagir avec les transactions (par exemple, les modifications au sein d'une transaction non verrouillée ne seront pas visibles pour les autres utilisateurs et n'entreront donc pas en conflit avec eux, mais elles peuvent poser des verrous en lecture seule sur les tables concernées).

A partir d'ADO/OLEDB, ces structures de contrôle de concurrence de Jet vont être mappées sur les fonctions et arguments pertinents trouvés dans ADO/OLEDB. Comme je n'utilise Jet qu'à partir d'Access, je n'interagis avec lui que via DAO, je ne peux donc pas vous conseiller sur la façon de contrôler ces structures avec ADO/OLEDB, mais le fait est que le moteur de base de données Jet offre un contrôle du verrouillage des enregistrements lorsque vous y accédez par programme (par opposition à l'interface utilisateur d'Access) - c'est juste plus compliqué.

3) Écluses et .NET

Je ne peux pas vous donner de conseils ici, si ce n'est que vous utiliserez probablement OLEDB comme interface de données, mais le fait est que la fonctionnalité de verrouillage/contrôle est présente dans le moteur de base de données lui-même, il y a donc probablement un moyen de la contrôler via OLEDB. Ce n'est peut-être pas très joli, cependant, car il me semble que OLEDB est conçu pour les architectures client/serveur, et le verrouillage basé sur les fichiers de Jet n'est peut-être pas adapté de manière élégante.

4) MDB sur un partage réseau

Jet est très sensible au moindre accroc dans une connexion réseau. Pour cette raison, les réseaux à faible bande passante peuvent augmenter la vulnérabilité des bases de données Jet ouvertes sur une connexion lente.

En effet, des parties importantes du fichier de la base de données doivent être transférées par câble vers la mémoire vive de l'ordinateur local pour être traitées. De nombreuses personnes affirment à tort que l'ensemble du fichier MDB est transféré par câble, ou que des tables entières sont transférées par câble. Ce n'est pas le cas. Au lieu de cela, Jet demande d'abord les index (et n'en demande pas plus que nécessaire pour répondre à la requête) et ensuite, à partir de ce résultat, détermine exactement quelles pages de données sont nécessaires et ne tire que ces pages. Cette méthode est étonnamment efficace et rapide.

De plus, Jet effectue une mise en cache très intelligente qui peut signifier qu'une première demande de données peut prendre un certain temps, mais que les demandes suivantes pour les mêmes données se font presque instantanément grâce à la mise en cache.

Maintenant, si vous n'avez pas bien indexé vos tables, vous pouvez finir par extraire la table entière et faire un balayage complet de la table. De même, si vous basez des critères sur des fonctions côté client qui ne font pas partie du dialecte SQL de Jet, vous pouvez finir par extraire une table entière (le tri sur, disons, Replace(MyField, "A", "Z") est susceptible de provoquer un balayage complet de la table). Mais ce genre de chose sera également inefficace dans une architecture client/serveur. Il s'agit donc d'une conception de schéma de bon sens pour indexer les choses correctement et faire attention à l'utilisation d'UDF ou de fonctions non compatibles avec Jet. En général, les mêmes choses qui sont efficaces avec le client/serveur vont l'être avec Jet (la différence majeure étant qu'avec Jet, il est préférable d'avoir une connexion persistante afin d'éviter les frais généraux de recréation du fichier LDB, qui sont importants).

L'autre chose à éviter est d'essayer d'utiliser Jet data à travers une connexion WiFi. Nous savons tous à quel point le WiFi n'est pas fiable, et c'est tout simplement chercher les ennuis que d'essayer de travailler avec les données Jet à travers une connexion WiFi.

L'essentiel :

Si vous utilisez une MDB comme magasin de données pour servir les données d'un serveur Web, vous devez placer les données aussi près que possible de la RAM du serveur Web. Cela signifie que, dans la mesure du possible, sur un volume de disque qui est attaché au serveur Web physique. Lorsque ce n'est pas possible, vous voulez une connexion LAN rapide et fiable. Les réseaux locaux de Go dans les centres de données sont assez courants de nos jours et je serais très à l'aise de travailler avec des données Jet sur ce type de connexion.

Pour une utilisation partagée, par exemple, plusieurs postes de travail clients exécutant une application de bureau VB.NET partageant un seul Jet MDB comme magasin de données, il est assez sûr d'avoir le fichier de données sur un serveur de fichiers fiable. Dans la mesure du possible, c'est une bonne idée de placer vos fichiers Jet MDB sur des machines qui ne servent pas plusieurs objectifs (par exemple, votre contrôleur de domaine qui exécute Exchange, SQL Server et qui agit comme serveur de fichiers et serveur d'impression n'est peut-être pas le meilleur emplacement). Les applications comme Exchange peuvent interférer avec la fonctionnalité du serveur de fichiers, et je recommande généralement de ne jamais placer les fichiers MDB sur un serveur qui est multi-tâches comme un serveur Exchange, sauf si le volume est extrêmement faible.

Autres considérations :

1. n'essayez jamais de distribuer une MDB sur un système de fichiers répliqué, sauf si tous les utilisateurs utilisent la même réplique. Autrement dit, si vous avez deux serveurs qui répliquent des fichiers entre eux, ne pensez même pas à modifier le fichier MDB à partir des deux serveurs. Cela corromprait le fichier presque immédiatement.

2. Je vous déconseille de stocker une MDB sur autre chose qu'un système de fichiers Windows natif desservi par le réseau SMB natif de Microsoft. Cela signifie pas de Novell, pas de Linux, pas de SAMBA. La raison principale est qu'il existe apparemment des crochets de bas niveau de Jet dans certaines fonctionnalités de verrouillage de bas niveau dans le système de fichiers Windows qui ne sont pas répliqués à 100% sur d'autres systèmes de fichiers. Je suis très prudent sur ce point, et de nombreux développeurs Access compétents ont rapporté d'excellents résultats avec des serveurs de fichiers Novell correctement configurés (il est souvent nécessaire de procéder à certains ajustements de verrouillage des enregistrements, bien que cela puisse être moins pertinent de nos jours - je ne sais même pas si Novell existe encore ! Je suis prudent sur ce point et je recommanderais à tout client de ne pas l'utiliser (cela inclut également divers périphériques SAN, puisque peu d'entre eux sont basés sur Windows).

3. Je ne les utiliserais jamais sur un système de fichiers virtualisé pour les mêmes raisons. Cependant, j'ai un client qui utilise son application Access mono-utilisateur sous Parallels sur un Mac Air depuis plusieurs années maintenant sans aucun problème. Mais il s'agit d'un utilisateur unique, donc les problèmes de verrouillage seront relativement mineurs.

Je ne sais pas si cela répond à vos questions ou non. Tout est basé sur mes 13 années d'utilisation régulière de Jet en tant que développeur Access et sur l'étude du seul livre publié sur Jet, le Jet Database Engine Programmers Guide (pour Jet 3.5 uniquement). Je n'ai pas fourni de véritables citations, mais si quelqu'un a besoin de détails sur ce que j'ai dit, je ferai la recherche si je le peux.

Answer 2

Au fil des ans, j'ai créé une douzaine d'applications pour petites entreprises en Access. La plupart ont un maximum de 10-20 utilisateurs à la fois. Les bases de données sont réparties entre une base de données "application" et une base de données "données". Les performances sont décentes et il n'y a pas de problèmes de concordance. De plus, la corruption est pratiquement inexistante depuis Access 2000 SP2.

Beaucoup de gens disent "n'utilisez jamais Access" - eh bien, s'il est bien fait (c'est-à-dire par un développeur professionnel), Access est un excellent logiciel de développement et j'en ai fait mon métier. Mes clients sont très satisfaits de ce que j'ai construit.

Answer 3

J'ai écrit deux produits commerciaux qui utilisent une base de données Access, fonctionnant à partir d'un partage réseau, pour un maximum de 10 utilisateurs. Si vous n'en abusez pas, il n'y a pas vraiment de problème ; mais comme vous pouvez le voir, de nombreux développeurs n'y arrivent jamais - et en raison de sa nature bas de gamme, il y a beaucoup de bidouilles merdiques construites dessus. Dans le cas d'un produit, j'ai dû revoir la conception de l'application à cause de tous les problèmes décrits en détail par d'autres ; mais après avoir fait le ménage, je n'ai jamais eu de problème d'intégrité de base de données sur des centaines d'installations.

Son grand avantage est la base de données à fichier unique, qui est facile à sauvegarder, à restaurer et à copier sur votre ordinateur portable pour la disséquer. Pratiquement toutes les alternatives, y compris sqlite (bien que certains ne veuillent pas l'admettre), nécessitent une certaine forme d'attention de la part du DBA de temps en temps.

Dans la plupart des cas, Access fournit par défaut des verrous d'enregistrement et des verrous de fichier pour certaines DDL (par exemple, les modifications de schéma).

Mais Microsoft est en train de le rendre obsolète, et certains de vos collègues vous mépriseront pour l'avoir utilisé.

(À ce stade, je me mets normalement à l'abri et je crie "INCOMING ! !!").

Answer 4

Access est vraiment une solution de bureau, pour un seul utilisateur. Dans la pratique, la limite supérieure de l'utilisateur est de "un".

Il s'agit également d'un moteur local. C'est-à-dire que lorsque vous exécutez une requête, les données sont tirées à travers le réseau vers le moteur JET local pour être traitées. Un fichier .ldb est placé sur le partage réseau pour contrôler les verrous.

Si vous utilisez un moteur côté serveur (MSSQL, MySQL, Sybase, 'Orable etc.), vous soumettez une requête à un moteur qui la traite et vous renvoie les résultats. Les verrous sont conservés en interne.

Cela a d'énormes répercussions sur les performances, la stabilité et l'intégrité des données.

Si votre utilisateur décide d'appuyer sur le bouton de réinitialisation, la base de données Access a de bonnes chances d'être corrompue et vous devrez supprimer le fichier .ldb.

Avec un moteur de base de données approprié (MSSQL, Sybase, 'Orable : je n'aime pas les sauvegardes de MySQL), vous avez également une capacité de sauvegarde appropriée. À moins que vous n'ayez un logiciel génial pour sauvegarder les fichiers en cours d'utilisation, il est possible que vous n'ayez aucune sauvegarde de vos données dans la base de données Access.

J'ai mentionné les verrous spécifiquement parce qu'un moteur de base de données peut gérer la concurrence et les transactions de manière beaucoup plus efficace et élégante que n'importe quel système basé sur des fichiers.

Je peux envisager d'utiliser un projet Access comme frontal pour un moteur de base de données, mais pas d'investir dans une application client complète avec un back-end Access.

Answer 5

J'ai utilisé Access, ou plus exactement Jet, comme back-end sur un tout petit site privé qui ne pourra jamais s'agrandir car il est limité par la taille d'une profession dans ce petit pays. En trois ans, je n'ai eu aucun problème. Il y a moins de 100 utilisateurs, dont 30 à 40 l'utilisent chaque jour. Les tables ont quelques milliers d'enregistrements.