¿Número máximo de filas en una tabla de motor de base de datos MS Access?

Question

Sabemos que el motor de la base de datos MS Access está 'acelerado' para permitir un tamaño máximo de archivo de 2GB (o quizás cableado interno para limitarse a menos de una potencia de 2 páginas de datos de 4KB). Pero, ¿qué significa esto en términos prácticos?

Para ayudarme a medir esto, ¿puede decirme el número máximo de filas que se pueden insertar en una tabla de motor de base de datos de MS Access?

Para satisfacer la definición de una tabla, todas las filas deben ser únicas, por lo tanto, una restricción única (por ejemplo, PRIMARY KEY , UNIQUE , CHECK , Macro de datos, etc.) es un requisito.

EDIT: me doy cuenta de que hay un límite teórico, pero lo que me interesa es el límite práctico (y no necesariamente practicable ) de la vida real.

Answer 1

Aquí está mi intento:

Creé una tabla de una sola columna ( INTEGER ) sin clave:

CREATE TABLE a (a INTEGER NOT NULL);

Enteros insertados en secuencia a partir de 1.

Lo detuve (arbitrariamente después de muchas horas) cuando había insertado 65,632,875 filas. El tamaño del archivo era 1,029,772 KB.

Compacté el archivo que lo redujo muy ligeramente a 1,029,704 KB.

Agregué un PK:

ALTER TABLE a ADD CONSTRAINT p PRIMARY KEY (a);

que aumentó el tamaño del archivo a 1,467,708 KB.

Esto sugiere que el máximo está alrededor de los 80 millones.

Answer 2

Algunos comentarios:

1. Los archivos Jet / ACE están organizados en páginas de datos, lo que significa que hay una cierta cantidad de espacio libre cuando los límites de su registro no están alineados con sus páginas de datos.

2. El bloqueo a nivel de fila reducirá en gran medida el número de registros posibles, ya que obliga a un registro por página de datos.

3. En Jet 4, el tamaño de la página de datos se incrementó a 4KB (de 2 KB en Jet 3.x). Como Jet 4 fue la primera versión de Jet que admitía Unicode, esto significaba que podía almacenar 1 GB de datos de doble byte (es decir, 1,000,000,000 de caracteres de doble byte), y con la compresión Unicode activada, 2 GB de datos. Por lo tanto, la cantidad de registros se verá afectada por si tiene o no compresión Unicode activada.

4. Dado que no sabemos cuánto espacio ocupan los encabezados y otros metadatos en un archivo Jet / ACE, ni exactamente cuánto espacio ocupa el almacenamiento del índice, el cálculo teórico siempre estará por debajo de lo que está práctico.

5. Para obtener el almacenamiento más eficiente posible, querrá usar código para crear su base de datos en lugar de la IU de Access, porque Access crea ciertas propiedades que Jet puro no necesita. Esto no quiere decir que haya muchos de estos, ya que las propiedades establecidas en los valores predeterminados de Access generalmente no se establecen en absoluto (la propiedad se crea solo cuando la cambia del valor predeterminado; esto se puede ver al recorrer los campos de un campo colección de propiedades, es decir, muchas de las propiedades enumeradas para un campo en el diseñador de tablas de Access no están allí en la colección de propiedades porque no se han establecido), pero es posible que desee limitarse a los tipos de datos específicos de Jet (campos de hipervínculo son de solo acceso, por ejemplo).

Acabo de perder una hora jugando con esto usando Rnd () para completar 4 campos definidos como tipo byte, con PK compuesto en los cuatro campos, y me llevó una eternidad agregar suficientes registros para obtener una porción significativa de 2 GB . Con más de 2 millones de registros, el archivo tenía menos de 80 MB. Finalmente lo dejé después de alcanzar solo 700K 7 MILLION registros y el archivo compactado a 184MBs. ¡La cantidad de tiempo que tomaría alcanzar cerca de 2 GB es más de lo que estoy dispuesto a invertir!

Answer 3

Como otros han dicho, es una combinación de su esquema y la cantidad de índices.

Un amigo tenía alrededor de 100,000,000 precios de acciones históricas, cotizaciones de cierre diarias, en un MDB que se acercaba al límite de 2 Gb.

Los bajó usando algún código que se encuentra en un artículo de la base de conocimiento de Microsoft. Me sorprendió bastante que cualquier servidor que estaba usando no lo interrumpiera después de los primeros 100K registros.

Podía ver cualquier registro en menos de un segundo.

Answer 4

Han pasado algunos años desde la última vez que trabajé con Access, pero los archivos de bases de datos más grandes siempre solían tener más problemas y eran más propensos a la corrupción que los archivos más pequeños.

A menos que una persona acceda al archivo de la base de datos o se almacene en una red sólida, es posible que esto sea un problema antes de que se alcance el límite de tamaño de la base de datos de 2 GB.

Answer 5

No estamos hablando necesariamente de límites teóricos aquí, estamos hablando de los límites del mundo real del tamaño de archivo máximo de 2 GB y el esquema de la base de datos.

• ¿Es su base de datos una sola mesa o ¿múltiple?
• ¿Cuántas columnas tiene cada tabla?
• ¿Cuáles son los tipos de datos?

El esquema está en equilibrio con el recuento de filas para determinar cuántas filas puede tener.

Hemos utilizado Access MDB para almacenar exportaciones de datos MS-SQL para el análisis estadístico de algunos de nuestros usuarios corporativos. En esos casos, hemos exportado nuestra estructura de tabla principal, típicamente cuatro tablas con 20 a 150 columnas que varían de cien bytes por fila a más de 8000 bytes por fila. En estos casos, nos toparíamos con unos cientos de miles de filas de datos permitidos POR MDB que los enviaríamos.

Entonces, simplemente no creo que esta pregunta tenga una respuesta en ausencia de su esquema.

Answer 6

Todo depende. Teóricamente usando una sola columna con un tipo de datos de 4 bytes. Podrías almacenar 300 000 filas. Pero probablemente haya muchos gastos generales en la base de datos incluso antes de hacer algo. Leí algunos en los que podría tener 1.000.000 de filas, pero de nuevo, todo depende ...

También puede vincular bases de datos. Limitándose a solo espacio en disco.

Answer 7

Practical = 'útil en la práctica', por lo que lo mejor que obtendrás es anecdótico. Todo lo demás es solo creación de prototipos y resultados de pruebas.

Estoy de acuerdo con los demás: determinar 'una cantidad máxima de registros' depende completamente del esquema: # tablas, # campos, # índices.

Otra anécdota para usted: recientemente alcancé un tamaño de archivo de 1.6GB con 2 almacenes de datos primarios (tablas), de 36 y 85 campos respectivamente, con algunas copias de subconjuntos en 3 tablas adicionales.

A quién le importa si los datos son únicos o no, solo material si el contexto lo dice. Los datos son datos, a menos que la duplicación afecte el manejo del indexador.

El recuento total de filas que conforman 1.6GB es 1.72M.

Answer 8

Al trabajar con 4 tablas grandes de Db2, no solo encontré el límite, sino que me hizo ver realmente mal a un jefe que pensó que podía agregar las cuatro tablas (cada una con más de 900,000 filas) a una tabla grande. El resultado de la vida real fue que, independientemente de cuántas veces probé la Tabla (que tenía exactamente 34 columnas: 30 de texto y 3 enteros) escupiría un mensaje críptico "No se puede abrir el formato no reconocido de la base de datos o el archivo puede estar dañado". El resultado final es menos de 1,500,000 registros y solo un poco más de 1,252,000 con 34 filas.