Je crée un MS Access *.accdb
base de données avec plusieurs tables et relations spécifiques.
Cette base de données sera utilisée pour un transport de données ponctuel vers un autre système, contenant l'ordre de quelques millions d'entrées. Un test avec 2 millions d'entrées factices atteint déjà une taille de fichier d'environ 1,8 Go. Étant donné que MS Access a une limite intégrée de 2 Go par fichier de base de données, je recherche des solutions pour contourner cette limite.
Jusqu'à présent, j'ai proposé deux idées:
Fractionnez la base de données en deux fichiers, poursuivez l'indexation lors de la transition de fichier1 à fichier2, en prenant soin de l'indépendance des entrées dans les tables associées.
file1_table1 (indices 1..1000)
file2_table1 (indices 1001..N)
Exportez les tables dans différents fichiers, en utilisant un fichier d'interface maître
file1_table1
file2_table2
file3_table3
masterfile (linking table1..3 and creating table relationships)
J'aimerais obtenir des commentaires sur ces idées concernant le concept, les performances et la convivialité ou s'il y a d'autres idées à ce sujet.
Veuillez noter que je veux m'en tenir à MS Access, la création d'une base de données SQL serait exagérée, car elle ne sera utilisée que pour un transport unique.
Les données sont réparties sur plusieurs sources (MS Access .accdb, Excel Sheets *.xlsx
, fichiers délimités *.csv
) et est analysé, fusionné et préparé en tant que base de données MS Access temporaire à usage unique, puis transformé en une base de données de travail basée sur SQL, qui comprend beaucoup plus que ce que je prépare. C'est donc un processus ETL classique.
La commande "Compacter et réparer" n'aidera pas, car il s'agit en fait uniquement de la grande quantité de données, pas d'une grande quantité d'opérations laissant derrière elles beaucoup de déchets. La procédure "Fractionner une base de données Access" semble seulement séparer les requêtes/formulaires/rapports du fichier principal contenant les tables, mais j'ai besoin de fractionner les tables elles-mêmes, me laissant avec le problème de cohérence entre les fichiers fractionnés. Ce n'est pas un problème avec la séparation de l'interface (front-end) et du back-end de données; J'ai besoin de diviser le backend de données lui-même en raison de la grande quantité de données.
Vous ne pouvez pas contourner la limitation intégrée d'une base de données Access. Vous pouvez cependant contourner la limitation intégrée en utilisant des fonctionnalités intégrées comme la division des objets de base de données entre plusieurs *.accdb
fichiers et les référencer en conséquence.
état des spécifications Access 2016 :
Taille totale d'une base de données Access 2016 (.accdb), y compris tous les objets et données de base de données:
2 gigaoctets, moins l'espace nécessaire pour les objets système.
Remarque: vous pouvez contourner cette limitation de taille en établissant un lien vers des tables dans d'autres bases de données Access. Vous pouvez créer un lien vers des tables dans plusieurs fichiers de base de données, chacun pouvant atteindre 2 Go. Conseil: Pour plus d'informations sur la réduction de la taille de votre base de données, consultez Aidez à prévenir et à corriger les problèmes de fichiers de base de données en utilisant Compact et Repair.
Vous pouvez même aller plus loin et, comme vous l'avez déjà mentionné, diviser les données et l'interface.
Fractionner une base de données Access
Envisagez de fractionner toute base de données que plusieurs personnes partagent sur un réseau. Le fractionnement d'une base de données partagée peut aider à améliorer ses performances et à réduire les risques de corruption de fichiers de base de données.
Après avoir fractionné la base de données, vous pouvez décider de déplacer la base de données principale ou d'utiliser une autre base de données principale. Vous pouvez utiliser le gestionnaire de tables liées pour modifier la base de données principale que vous utilisez.
Parce que c'est Microsoft Access, je recommanderais de rester avec les options prises en charge plutôt que d'essayer une autre solution qui pourrait ou pourrait [~ # ~] pas [~ # ~] travail.
Nous avions l'habitude d'avoir une application qui avait l'interface (FE) et les données (BE) divisées. Aucune différence de performance notable, lorsqu'il est hébergé sur un serveur de fichiers. Cependant, lorsque le BE a atteint 2 Go, une écriture a corrompu le BE et les données étaient irrécupérables, c'est à ce moment-là que nous avons décidé de passer à SQL Server Express, puis à SQL Server. Je ne pense pas qu'il devrait y avoir un impact notable sur les performances lorsque vous accédez à plusieurs fichiers BE contenant les différentes tables. Mais avoir le BE sur des partages de fichiers sera généralement plus lent que de les stocker localement.
Je recommande fortement de migrer le back-end vers SQL Server.
Les tables peuvent être attachées depuis l'accès via table liée à SQL Server .
L'avantage de cette approche est que vous pouvez évoluer pour éviter la restriction du fichier d'accès tout en utilisant tout le travail que vous avez effectué en matière d'accès.
Il y a même assistants pour aider avec l'importation et la mise à l'échelle depuis l'accès.
Les performances seront directement affectées par la conception de votre fichier sql, table et index. Mais grosso modo, les performances devraient être aussi bonnes, sinon meilleures que l'accès. Conseils de base:
Créez une base de données utilisateur avec une taille de fichier décente et définissez la croissance du fichier sur 100 Mo ou 1 Go.
Assurez-vous que chaque table a une clé primaire définie dans le serveur SQL. Pas seulement un index unique. Access ne vous permettra pas de mettre à jour une table sql sans clé primaire définie dans la définition de table liée.
L'équivalent d'un numéro automatique d'accès est une colonne d'identité. Si vous avez des tables intermédiaires avec des doublons, cela vaut la peine d'ajouter une colonne d'identité en tant que clé p.
Si vous n'avez pas accès à une instance SQL, vous pouvez installer SQL Express ou Developer sur votre PC.
Si vous n'êtes pas familier avec le serveur SQL, il y aura un peu de courbe d'apprentissage, mais cela en vaut la peine.
SQL est livré avec des outils puissants qui vous ouvrent de nombreuses options. L'apprentissage de SSIS est peut-être trop pour ce projet, mais vous pouvez accomplir beaucoup de choses avec l'assistant d'importation dans SSMS et enregistrer les packages à réutiliser.
S'il s'agit d'un transport unique, pourquoi utilisez-vous Access du tout? Mettez les données dans un fichier délimité (virgule/tabulation/pipe) et terminez avec. La plupart des systèmes importeront à partir de ce format.