Come posso gestire le tabelle con oltre 256 variabili?

Sto lavorando con i dati del censimento e scaricato diversi file CSV, ognuno con colonne / variabili 600ish. Vorrei memorizzarli tutti in un database con query, ma tutto ciò che ho provato finora (MS Access, Arc geodatabase table) tronca la tabella a 256 colonne. Esistono soluzioni per la gestione di tabelle di grandi dimensioni accessibili a qualcuno che non è un DBA?

database census csv

— scoball
fonte

Con qualsiasi quantità di normalizzazione DB sospetto che queste enormi tabelle debbano essere separate in più (o molte) tabelle più piccole relative all'UID della loro unità di censimento (forse blocco?).

— Roy,

Risposte:

PostgreSQL ha un limite di colonna compreso tra 250 e 1600 "a seconda dei tipi di colonna" e supporta dati spaziali e query con l'estensione PostGIS. Quindi sarei propenso a fare due cose:

Innanzitutto, dove una colonna rappresenta una categoria anziché un testo libero, crea una tabella separata con quelle categorie e sostituisci la colonna con un ID intero e un vincolo di chiave esterna, facendo riferimento alla tabella delle categorie.

In secondo luogo, spezza la terza forma normale suddividendo il grande tavolo in due o più in qualche modo logico e stabilendo una relazione uno a uno tra di loro. Questo non è forse il più efficiente, ma se raramente hai bisogno di alcuni dei dati, la query può essere solo nelle tabelle che desideri.

Un'altra alternativa completamente diversa sarebbe quella di utilizzare un database "NOSQL" come MongoDB, CouchDB e così via. Non ci sono limiti fissi alla dimensione della "riga" e, se i dati non sono presenti per un record, non è necessario occupare spazio.

Il supporto spaziale non è altrettanto valido per questi tipi di database bigtable, ma MongoDB supporta query e dati spaziali 2D e CouchDB sembra avere funzionalità simili.

— MerseyViking
fonte

+1 La soluzione di join (paragrafo 3) in realtà può essere estremamente efficiente, poiché i dati del censimento tendono ad avere gruppi di campi correlati e per qualsiasi analisi particolare spesso è necessario solo un piccolo numero di questi gruppi. In questo modo migliaia di campi (non esagero: questo è comune) possono essere suddivisi logicamente in dozzine di tabelle e solo un numero limitato di tali tabelle deve essere accessibile per qualsiasi mappa o analisi particolare.

— whuber

@MerseyViking, Come ha potuto (@scoball) dividere le tabelle o eseguire le altre operazioni menzionate se non è in grado di importare i dati in alcun programma che manipola le tabelle? i dati sono in CSV.

— Pablo,

@Pablo, penso che tu sia ingiusto con MerseyViking: se ti è permesso scrivere uno script per importare le tabelle - a cui sei essenzialmente obbligato per implementare la tua soluzione - allora lo è anche lui, e non ci sono difficoltà per iscritto uno completamente generale e flessibile. (Lo so per esperienza perché l'ho fatto per database di censimento estremamente grandi.) Inoltre, suggerisce molte alternative che aggirano il limite di 256 campi.

— whuber

"dove una colonna rappresenta una categoria anziché testo libero" Devi mappare manualmente quelle colonne.

— Pablo,

@Pablo Solo se stai utilizzando un software inadeguato :-). Il flusso di lavoro di cui ai paragrafi 2-3 può essere eseguito con pochi comandi, ad esempio utilizzando quasi tutti i programmi statistici moderni. (Ovviamente non sto sostenendo di utilizzare un programma del genere al posto di un database; sto solo sottolineando che con la suite di strumenti adeguata , tutto in questa risposta può essere realizzato facilmente ed efficientemente.)

— whuber

Di recente ho affrontato lo stesso identico problema con i file CSV del profilo del censimento di Statistics Canada contenenti 2172 colonne. Puoi importare il tuo CSV in un geodatabase di file ESRI (FGDB) se hai accesso ad ArcGIS. Secondo ESRI, il formato FGDB può gestire 65.534 campi in una classe di caratteristiche o tabella .

Nel mio caso, sono stato in grado di importare il mio file CSV a colonna 2172 in una tabella FGDB senza problemi.

Una volta ottenuto l'intero tavolo nell'FGDB, puoi dividerlo come preferisci (es. Logicamente o in base alle limitazioni del db), assicurandoti di mantenere una colonna id univoca, per assicurarti di poterlo ricollegare come necessario.

— Brent Edwards
fonte

Interessante! Ho provato a fare un'importazione da CSV al file geodatabase. Quando l'ho impostato ho guardato l'elenco delle variabili che stava per importare e ha smesso di elencarle dopo 256 variabili, quindi non ho proceduto. Prenderò un'altra occhiata.

— scoball,

Dai

— Brent Edwards

I file geodatabase hanno limiti elevati, quindi è possibile che sia successo qualcosa durante l'importazione.

— nicksan,

Breve: la
mia opzione per i dati con molti attributi o con il tipo di attributo variabile per ogni oggetto è di usare il modello di dati KEY / VALUE, può essere implementato e funziona molto bene, in sql (consiglierei postgresql + postgis).

Descrizione:
1) Hai una tabella per le caratteristiche, diciamo, punti. Questa tabella contiene un ID e la GEOMETRIA per ciascun punto.

2) Hai un'altra tabella per gli "attributi" che sono le coppie chiave / valore. Questa tabella ha le colonne ID, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Ora ogni punto potrebbe avere attributi praticamente infiniti memorizzati in questo modo:

ID   POINT_ID   KEY   VALUE
1        1      type     burger shop
2        1      name     SuperBurger
3        1      address  123, a ST.

OpenStreetMaps funziona così e funziona molto bene, vedi qui e qui .

Per importare i dati vorrei richiedere uno script Python.

— Pablo
fonte

Questa è spesso chiamata la forma "lunga" dei dati ed è utile conoscerla. Anche se va bene per l'archiviazione flessibile, è inutile per qualsiasi tipo di analisi multivariata (che sarebbe qualsiasi analisi che confronta due o più attributi).

— whuber

@whuber, non è inutile per l'analisi multivariata, ma in effetti hai bisogno di un software molto strutturato o di buone capacità di programmazione perché i dati devono essere preparati, in particolare, trasferiti su una tabella. Qui uso la combinazione di postgis + django (python web framework) per lavorare i dati del suolo (ph, al, clay, ecc.) Quando ho bisogno di inserire estratti dei dati nelle tabelle prima dell'elaborazione. Questo modello è stato scelto perché la stessa struttura elaborerà altri dati puntuali arbitrari.

— Pablo,

Abbastanza giusto: avrei dovuto dire "inutile com'è". A condizione che tutte le informazioni siano conservate - ed è - è sempre possibile elaborare i dati in qualsiasi formato desiderato. L'elaborazione è relativamente semplice utilizzando i metodi di @ MerseyViking rispetto all'approccio chiave / valore. Inoltre, quando le tabelle diventano molto grandi, iniziamo a preoccuparci delle dimensioni totali. La ridondanza nell'archiviazione chiave / valore è così grande che viene raramente utilizzata per l'analisi di set di dati molto grandi (non posso parlare della frequenza del suo utilizzo puramente per l'archiviazione.)

— whuber

Non sono d'accordo con la sua soluzione perché non è facile, per non dire impossibile, dividere o manipolare le tabelle se non è possibile aprire i dati in un database. L'utente deve inviare i dati direttamente al database tramite uno script e con il modello chiave / valore è possibile utilizzare lo stesso script per tutti i dati senza la necessità di mappare le colonne o classificare gli attributi.

— Pablo,

La tua soluzione sembra, per tua stessa ammissione, essere programmaticamente complessa come la mia, che necessita di "buone capacità di programmazione". Ho semplicemente sostenuto di conservare i dati in una forma più efficiente per un RDBMS come PostgreSQL. Inoltre, sembra essere un punto controverso perché la risposta di Brent mostra che il limite di 256 colonne è falso.

— MerseyViking