Nombre maximal de lignes dans une table de moteur de base de données MS Access?
Nous savons que le moteur de base de données MS Access est «limité» pour permettre une taille de fichier maximale de 2 Go (ou peut-être que le câblage interne doit être limité à moins d'une puissance de 2 pages de données de 4 Ko). Mais qu'est-ce que cela signifie concrètement?
Pour m'aider à mesurer cela, pouvez-vous me dire le nombre maximal de lignes pouvant être insérées dans une table de moteur de base de données MS Access?
Pour satisfaire à la définition d'une table, toutes les lignes doivent être uniques. Par conséquent, une contrainte unique (par exemple, PRIMARY KEY, UNIQUE, CHECK, macro de données, etc.) est requise.
EDIT: Je réalise qu’il ya une limite théorique, mais ce qui m’intéresse, c’est la limite pratique (et pas nécessairement réalisable ), réelle.
Voici ma tentative:
J'ai créé une table à une colonne (INTEGER) sans clé:
CREATE TABLE a (a INTEGER NOT NULL);
Nombre entier inséré dans la séquence commençant à 1.
Je l'ai arrêté (arbitrairement après de nombreuses heures) après avoir inséré 65 632 875 lignes ..__ La taille du fichier était de 1 029 772 Ko.
J'ai compacté le fichier qui l'a très légèrement réduit à 1 029 704 Ko.
J'ai ajouté un PK:
ALTER TABLE a ADD CONSTRAINT p PRIMARY KEY (a);
ce qui a porté la taille du fichier à 1 467 708 Ko.
Cela suggère que le maximum est quelque part autour de 80 millions.
Certains commentaires:
Les fichiers Jet/ACE sont organisés en pages de données, ce qui signifie qu'il y a un certain espace libre lorsque les limites de vos enregistrements ne sont pas alignées sur vos pages de données.
Le verrouillage au niveau de la ligne réduira considérablement le nombre d’enregistrements possibles, car il impose un enregistrement par page de données.
Dans Jet 4, la taille de la page de données a été portée à 4 Ko (au lieu de 2 Ko dans Jet 3.x). Comme Jet 4 était la première version de Jet à prendre en charge l’Unicode, cela signifiait que vous pouviez stocker 1 Go de données codées sur deux octets (c’est-à-dire 1 000 000 000 de caractères codés sur deux octets) et, avec la compression Unicode activée, 2 Go de données. Ainsi, le nombre d'enregistrements sera affecté par la présence ou non de la compression Unicode.
Etant donné que nous ne savons pas combien de place dans un fichier Jet/ACE est occupée par des en-têtes et d’autres métadonnées, ni précisément par la quantité de stockage des index de salle, le calcul théorique sera toujours conforme à la pratique.
Pour obtenir le stockage le plus efficace possible, vous souhaitez utiliser le code pour créer votre base de données plutôt que l'interface utilisateur Access, car Access crée certaines propriétés dont pure Jet n'a pas besoin. Cela ne veut pas dire qu'il y en a beaucoup, car les propriétés définies sur les valeurs par défaut d'accès ne sont généralement pas définies du tout (la propriété est créée uniquement lorsque vous la modifiez à partir de la valeur par défaut - vous pouvez le voir en parcourant les champs d'un champ. collection de propriétés, c’est-à-dire que de nombreuses propriétés répertoriées pour un champ dans le concepteur de table Access ne sont pas présentes dans la collection de propriétés car elles n’ont pas été définies), mais vous pouvez vous limiter aux types de données spécifiques à Jet (champs de lien hypertexte sont uniquement accessibles, par exemple).
Je viens de perdre une heure à me servir de cette méthode en utilisant Rnd () pour renseigner 4 champs définis comme octet de type, avec une PK composite sur les quatre champs, et il a fallu une éternité pour ajouter suffisamment d’enregistrements pour obtenir une portion significative de 2 Go. Avec plus de 2 millions d’enregistrements, le fichier comptait moins de 80 Mo. J'ai finalement arrêté après avoir atteint juste 700K 7 MILLIONS enregistrements et le fichier compacté à 184Mo. Le temps qu'il faudrait pour me lever près de 2 Go est un peu plus long que ce que je suis prêt à investir!
Comme d’autres l’ont dit, il s’agit d’une combinaison de votre schéma et du nombre d’index.
Un ami avait environ 100 000 000 de cours de bourse historiques, cours de clôture quotidiens, dans une BMD approchant de la limite de 2 Gb.
Il les a supprimés en utilisant du code contenu dans un article de la base de connaissances Microsoft. J'étais plutôt surpris que le serveur qu'il utilisait ne l'ait pas coupé après les premiers 100 000 enregistrements.
Il pouvait voir n'importe quel enregistrement en moins d'une seconde.
Cela fait quelques années que j'ai travaillé pour la dernière fois avec Access, mais les fichiers de base de données volumineux avaient toujours plus de problèmes et étaient plus sujets à la corruption que les fichiers plus petits.
À moins que le fichier de base de données ne soit accédé que par une seule personne ou stocké sur un réseau robuste, vous constaterez qu'il s'agit d'un problème avant que la limite de taille de la base de données de 2 Go soit atteinte.
Nous ne parlons pas nécessairement de limites théoriques ici, nous parlons des limites du monde réel de la taille de fichier maximale de 2 Go ET du schéma de base de données.
- Est-ce que votre base de données est une seule table ou plusieurs.
- Combien de colonnes a chaque table?
- Quels sont les types de données?
Le schéma est sur un pied d'égalité avec le nombre de lignes pour déterminer le nombre de lignes que vous pouvez avoir.
Nous avons utilisé des MDB Access pour stocker les exportations de données MS-SQL à des fins d'analyse statistique par certains de nos utilisateurs. Dans ces cas, nous avons exporté notre structure de table principale, généralement quatre tables de 20 à 150 colonnes allant de 100 octets par ligne à plus de 8 000 octets par ligne. Dans ces cas-là, nous nous heurterions à quelques centaines de milliers de lignes de données, ce qui nous permettait PER MDB de les envoyer.
Donc, je ne pense pas que cette question a une réponse en l’absence de votre schéma.
En travaillant avec 4 grandes tables Db2, non seulement j'ai trouvé la limite, mais cela m'a fait très mal paraître à un patron qui pensait que je pouvais annexer les quatre tables (chacune avec plus de 900 000 rangées) à une grande table. Le résultat réel était que peu importe le nombre de fois où j'essayais la table (qui contenait exactement 34 colonnes - 30 textes et 3 entiers) crachait un message cryptique "Impossible d'ouvrir le format de base de données non reconnu ou le fichier peut être corrompu". En résumé, moins de 1 500 000 enregistrements et un peu plus de 1 252 000 avec 34 lignes.
Pratique = 'utile dans la pratique' - le meilleur que vous obtiendrez est donc anecdotique. Tout le reste ne fait que prototyper et tester les résultats.
Je suis d'accord avec les autres - la détermination du nombre maximal d'enregistrements dépend entièrement du schéma: # tables, # champs, # index.
Une autre anecdote pour vous: j'ai récemment atteint une taille de fichier de 1,6 Go avec 2 magasins de données primaires (tables), de 36 et 85 champs respectivement, ainsi que des copies de sous-ensembles dans 3 tableaux supplémentaires.
Qui se soucie de savoir si les données sont uniques ou non - seulement du matériel si le contexte le dit Les données sont les données, les données, sauf si la duplication affecte la gestion par l'indexeur.
Le nombre total de lignes jusqu'à 1,6 Go correspond à 1,72 M.
Tout dépend. Théoriquement, utilisez une seule colonne avec un type de données à 4 octets. Vous pouvez stocker 300 000 lignes. Mais il y a probablement beaucoup de surcharge dans la base de données avant même de faire quoi que ce soit. J'en ai lu des endroits où vous pourriez avoir 1.000.000 lignes mais encore une fois, tout dépend ..
Vous pouvez également lier des bases de données ensemble. Limitez-vous à un espace disque uniquement.