Numero massimo di righe in una tabella del motore di database di MS Access?

Question

Sappiamo che il motore di database di MS Access è "limitato" per consentire una dimensione massima del file di 2 GB (o forse cablata internamente per essere limitata a meno della potenza di 2 pagine di dati 4KB). Ma cosa significa questo in termini pratici?

Per aiutarmi a misurare questo, puoi dirmi il numero massimo di righe che possono essere inserite in una tabella del motore di database di MS Access?

Per soddisfare la definizione di una tabella, tutte le righe devono essere univoche, quindi un vincolo univoco (ad esempio PRIMARY KEY , UNIQUE , CHECK , Macro dati, ecc.) È un requisito.

EDIT: mi rendo conto che esiste un limite teorico ma ciò che mi interessa è il limite pratico (e non necessariamente praticabile ), reale.

Answer 1

Ecco il mio tentativo:

Ho creato una tabella a colonna singola ( INTEGER ) senza chiave:

CREATE TABLE a (a INTEGER NOT NULL);

Numeri interi inseriti in sequenza a partire da 1.

L'ho fermato (arbitrariamente dopo molte ore) quando aveva inserito 65.632.875 righe. La dimensione del file era 1.029.772 KB.

Ho compattato il file che lo ha ridotto leggermente a 1.029.704 KB.

Ho aggiunto un PK:

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

che ha aumentato le dimensioni del file a 1.467.708 KB.

Questo suggerisce che il massimo è da qualche parte intorno al segno di 80 milioni.

Answer 2

Alcuni commenti:

1. I file Jet / ACE sono organizzati in pagine di dati, il che significa che esiste una certa quantità di spazio libero quando i confini dei record non sono allineati con le pagine di dati.

2. Il blocco a livello di riga ridurrà notevolmente il numero di record possibili, poiché impone un record per pagina di dati.

3. In Jet 4, la dimensione della pagina di dati è stata aumentata a 4KB (da 2 KB in Jet 3.x). Poiché Jet 4 è stata la prima versione di Jet a supportare Unicode, ciò significa che è possibile memorizzare 1 GB di dati a doppio byte (ovvero 1.000.000.000 di caratteri a doppio byte) e, con la compressione Unicode attivata, 2 GB di dati. Quindi, il numero di record sarà influenzato dalla presenza o meno della compressione Unicode.

4. Dal momento che non sappiamo quanto spazio in un file Jet / ACE è occupato da intestazioni e altri metadati, né precisamente quanto spazio occupa l'indice dello spazio, il calcolo teorico sarà sempre sotto ciò che è pratico.

5. Per ottenere l'archiviazione più efficiente possibile, si desidera utilizzare il codice per creare il database anziché l'interfaccia utente di Access, poiché Access crea determinate proprietà di cui Jet puro non ha bisogno. Questo non vuol dire che ce ne sono molti, poiché le proprietà impostate sui valori predefiniti di Access non sono in genere affatto impostate (la proprietà viene creata solo quando la si modifica dal valore predefinito - questo può essere visto scorrendo ciclicamente un campo raccolta di proprietà, ovvero molte delle proprietà elencate per un campo nella finestra di progettazione delle tabelle di Access non sono presenti nella raccolta di proprietà perché non sono state impostate, ma potresti voler limitarti a tipi di dati specifici di Jet (campi di collegamenti ipertestuali sono solo Access, ad esempio).

Ho appena perso un'ora a perdere tempo usando Rnd () per popolare 4 campi definiti come byte di tipo, con PK composito sui quattro campi, e ci sono voluti un'eternità ad aggiungere abbastanza record per arrivare a qualsiasi porzione significativa di 2 GB . Con oltre 2 milioni di record, il file era inferiore a 80 MB. Alla fine ho smesso dopo aver raggiunto solo 700K 7 MILIONI e il file è stato compattato a 184 MB. Il tempo necessario per alzarsi vicino a 2 GB è solo più di quanto io sia disposto a investire!

Answer 3

Come altri hanno affermato, è la combinazione del tuo schema e del numero di indici.

Un amico aveva circa 100.000.000 di azioni storiche, quotazioni di chiusura giornaliere, in un MDB che si avvicinava al limite di 2 GB.

Li ha tirati giù usando del codice trovato in un articolo della Microsoft Knowledge Base. Sono stato piuttosto sorpreso dal fatto che qualunque server stesse usando non lo ha interrotto dopo i primi 100.000 dischi.

Poteva visualizzare qualsiasi record in meno di un secondo.

Answer 4

Sono passati alcuni anni dall'ultima volta che ho lavorato con Access, ma i file di database più grandi hanno sempre avuto più problemi e sono più inclini alla corruzione rispetto ai file più piccoli.

A meno che il file di database non sia accessibile solo a una persona o archiviato su una rete solida, è possibile che si tratti di un problema prima che venga raggiunto il limite di dimensioni del database da 2 GB.

Answer 5

Non stiamo necessariamente parlando di limiti teorici qui, stiamo parlando di limiti del mondo reale delle dimensioni massime del file da 2 GB E dello schema del database.

• Il tuo db è una tabella singola o multipla?
• Quante colonne ha ogni tabella?
• Quali sono i tipi di dati?

Lo schema è in pareggio con il conteggio delle righe nel determinare quante righe puoi avere.

Abbiamo utilizzato Access MDB per archiviare le esportazioni di dati MS-SQL per l'analisi statistica di alcuni dei nostri utenti aziendali. In questi casi abbiamo esportato la nostra struttura di tabella principale, in genere quattro tabelle con 20-150 colonne che variano da cento byte per riga a un massimo di 8000 byte per riga. In questi casi, ci imbatteremo in alcune centinaia di migliaia di righe di dati consentite per MDB che le spediremmo.

Quindi, non penso proprio che questa domanda abbia una risposta in assenza del tuo schema.

Answer 6

Tutto dipende. Teoricamente usando una singola colonna con tipo di dati a 4 byte. È possibile memorizzare 300000 righe. Ma probabilmente c'è un sacco di overhead nel database anche prima di fare qualsiasi cosa. Ho letto alcuni dove potresti avere 1.000.000 di righe ma, di nuovo, tutto dipende ..

È inoltre possibile collegare insieme database. Limitare solo a spazio su disco.

Answer 7

Pratico = 'utile in pratica' - quindi il meglio che otterrai è aneddotico. Tutto il resto è solo prototipazione e test dei risultati.

Sono d'accordo con gli altri: determinare "una quantità massima di record" dipende completamente dallo schema - # tabelle, # campi, # indici.

Un altro aneddoto per te: di recente ho raggiunto dimensioni del file di 1,6 GB con 2 archivi di dati primari (tabelle), rispettivamente di 36 e 85 campi, con alcune copie di sottoinsiemi in 3 tabelle aggiuntive.

Chi se ne frega se i dati sono unici o no - solo materiale se il contesto lo dice. I dati sono dati sono dati, a meno che la duplicazione non influenzi la gestione da parte dell'indicizzatore.

Il numero totale di righe che compongono quel 1.6GB è 1.72M.

Answer 8

Quando ho lavorato con 4 grandi tabelle Db2 non solo ho trovato il limite, ma mi ha fatto sembrare davvero brutto per un boss che pensava di poter aggiungere tutte e quattro le tabelle (ognuna con oltre 900.000 righe) a una grande tabella. il risultato della vita reale è stato che, indipendentemente da quante volte ho provato la tabella (che aveva esattamente 34 colonne - 30 testo e 3 numeri interi) sputavo fuori qualche messaggio criptico "Impossibile aprire il formato non riconosciuto del database o il file potrebbe essere danneggiato". Bottom Line è inferiore a 1.500.000 di record e poco più di 1.252.000 con 34 righe.