Questions sur MS Access - Évolutivité / indexation / transactions

Question

Quelques questions sur les bases de données MS Access -

Taille: la taille d'une base de données d'accès est-elle limitée? La raison pour laquelle je demande est que nous avons une base de données d'accès qui a quelques tables simples. La taille de la base de données est d'environ 1 Go. Quand je fais une requête à ce sujet, je vois qu'il prend plus de 10 minutes pour s'exécuter.

Avec une indexation appropriée, MS Access devrait-il être en mesure de le gérer ou existe-t-il des limitations fondamentales à la technologie?

Ceci est MS Access XP.

MS Access prend-il également en charge les transactions, les validations et les restaurations de bases de données?

Answer 1

Vous obtiendrez ici de nombreuses réponses variées, mais dans MON OPINION, l’accès n’est tout simplement pas une solution évolutive. Il ne gère pas très bien les situations multi-utilisateurs, alors que vous commencez à approcher 1 Go, la stabilité commence à devenir une préoccupation MAJEURE et, en réalité, elle n’a tout simplement pas la performance.

En ce qui concerne le support des transactions, veuillez consulter le ce fichier Microsoft Artic .

En outre, voici un article qui souligne une bonne majorité de limitations d'accès .

Answer 2

En réponse -

Taille: la taille maximale d'une base de données Access est de 2 Go.

Transactions: les transactions sont entièrement prises en charge par le moteur de base de données JET sous-jacent.

D'après mon expérience passée, je suis enclin à dire que vous atteignez probablement la taille maximale utilisable et que vous devriez peut-être envisager de passer à SQL Server Express.

Answer 3

Personnellement, j'ai trouvé que la limite «utilisable» se situait dans la plage de quelques centaines de mégaoctets.

Access est conçu pour les petites bases de données. Pour les grands, c’est-à-dire ceux qui vont au-delà de quelque chose que vous et quelques personnes utilisez, vous devriez rechercher un "réel". SGBDR tels que SQL Server, ORacle, DB2, MySQL, etc.

MODIFIER - voir http: //www.blueclaw-db .com / vb_transaction_processing.htm pour gérer les transactions avec Access. Apparemment, ce n'est pas natif.

Answer 4

La taille maximale d'une base de données Access est de 2 Go. Vous pouvez contourner ce problème en utilisant des tables liées dans d'autres fichiers, mais il est probablement temps d'utiliser une base de données plus robuste si vous rencontrez déjà des problèmes de performances.

Ma recommandation serait de consulter SQL Server Compact , qui est une base de données gratuite, basée sur des fichiers ou, mieux encore, SQL Server Express , qui est gratuit, "léger". version de SQL Server qui prendra en charge plusieurs utilisateurs et l’interopérabilité avec SQL Server. Les deux vous limitent à 4 Go de bases de données.

Tous les produits mentionnés, y compris Access, prennent en charge les transactions.

Answer 5

Je ne sais pas s'ils existent toujours dans la version XP, mais dans Access 97, il existait des options de compactage et de réparation. Si ce sont toujours des options, ils peuvent aider.

Answer 6

Bien que cela remonte à plusieurs années à une époque où le coût d'entrée dans une installation SQL Server était aussi prohibitif que celui d'Oracle, un de mes clients utilisait Access pour essayer de gérer un centre d'appels entrants.

Nous parlons de 40 millions de lignes de concepts de bases de données très volumineuses VLDB. C'était à l'époque des compagnies de téléphone qui déployaient l'identification de l'appelant et offraient à leurs abonnés un moyen de recevoir un dispositif d'identification de l'appelant gratuit. En raison de contraintes de coût, ils ont dû ignorer mes arguments: investir dans SQL Server.

En pratique, il semblait que l’accès avait basculé à environ 800 Mo. Nous avons partitionné les tables en plusieurs bases de données Access pour gérer la charge. Croyez-le ou non, cela a fonctionné à merveille. Le client était reconnaissant.

Dans la pratique, étant donné la disponibilité de SQL Express, je vous recommande également de suivre cette voie.

Answer 7

En lisant les groupes de discussion Access au fil des années, mon impression est que le moteur ACE / Jet (fichier .accdb, .mdb ou .mde) n’est recommandé qu’aujourd’hui lorsque MS Access est utilisé comme environnement de développement basé sur des formulaires RAD et utilisant des formulaires liés. Si vous ne disposez pas d'un serveur Access, il existe peu d'arguments en faveur d'un serveur dorsal ACE / Jet lorsque vous envisagez des alternatives beaucoup plus évolutives (et capables): SQL Server Express ou SQL Server Compact Edition pour les magasins MS, MySQL, etc.

En tant que support de transaction reagrds dans le moteur ACE / Jet, oui, il est présent et natif. Une autre réponse est liée à un article sur l'utilisation de transactions via DAO: notez que de nombreux aspects de DAO sont limités car son développement est à la traîne par rapport au moteur, et les transactions en sont un exemple. Heureusement, vous pouvez utiliser SQL DCL: BEGIN TRANSACTION, COMMIT TRANSACTION, ROLLBACK TRANSACTION, etc. pour accomplir des tâches impossibles avec DAO, par exemple. transactions imbriquées. SQL DCL nécessite que l'interface d'accès soit en mode de requête ANSI-92; utiliser ADO fonctionnera car ADO utilise ce mode de manière native. Pour plus de détails, voir:

SQL avancé pour Microsoft Jet pour Access 2000

Answer 8

Jet peut être un très bon magasin de données pour n’importe quel nombre de plates-formes de développement de postes de travail, pas seulement avec Access lui-même. Cela a toujours été un premier choix pour les développeurs VB et l’est toujours (pour une bonne raison).

Une MDB de 1 Go qui ne devrait pas connaître une croissance importante ne devrait pas poser de problème en termes de rapidité ou de fiabilité. Si c'est lent, alors vous ne l'avez pas bien indexé, ou vous écrivez du SQL très inefficace. Un exemple de code SQL inefficace serait l’application de clauses WHERE à des expressions, qui ne peuvent donc pas utiliser d’index. Un exemple serait

.

WHERE Year([MyTable].[MyDate]) = 2002

par opposition à

WHERE MyTable.MyDate Between #1/1/2002# And #12/31/2002#

Si vous rencontrez des problèmes de stabilité (c'est-à-dire une corruption récurrente), c'est un problème qui doit être résolu - il est généralement dû à une erreur humaine, à un problème matériel ou à des problèmes logiciels (tels que les logiciels antivirus interférant avec les opérations d'écriture internes de Jet). .

Mais le facteur déterminant est la rapidité avec laquelle la MDB se développe. Si vous extrapolez le taux de croissance historique et approchez les 2 Go dans les 5 ans, je dirais que vous devez passer à la vitesse supérieure. Si c'est plus comme 10 ans, vous devriez probablement le faire quand même. Si c'est 20 ans, alors pas tant que ça.