¿Cómo puedo manejar tablas con más de 256 variables?

Estoy trabajando con datos del censo y descargué varios archivos CSV, cada uno con 600 columnas / variables. Me gustaría almacenarlos todos en una base de datos que se pueda consultar, pero todo lo que he probado hasta ahora (MS Access, tabla de geodatabase de Arc) trunca la tabla a 256 columnas. ¿Hay alguna solución para manejar tablas grandes que sean accesibles para alguien que no sea un DBA?

database census csv

— scoball
fuente

Con cualquier cantidad de normalización de base de datos, sospecho que estas tablas enormes deben separarse en varias (o muchas) tablas más pequeñas relacionadas con su UID de la unidad del censo (¿bloque quizás?).

— Roy

Respuestas:

PostgreSQL tiene un límite de columna de entre 250 y 1600 "dependiendo de los tipos de columna", y admite datos espaciales y consultas con la extensión PostGIS. Entonces me inclinaría a hacer dos cosas:

Primero, cuando una columna representa una categoría en lugar de texto libre, cree una tabla separada con esas categorías y reemplace la columna con una ID de entero y una restricción de clave externa, haciendo referencia a la tabla de categorías.

En segundo lugar, divida la Tercera Forma Normal dividiendo la mesa grande en dos o más de una manera lógica, y establezca una relación uno a uno entre ellos. Este no es quizás el más eficiente, pero si rara vez necesita algunos de los datos, entonces la consulta puede estar en las tablas que desee.

Otra alternativa completamente diferente sería utilizar una base de datos "NOSQL" como MongoDB, CouchDB, etc. No hay límites fijos para el tamaño de "fila", y si los datos no están presentes para un registro, no necesita ocupar espacio.

El soporte espacial no es tan bueno para este tipo de bases de datos bigtable, pero MongoDB admite consultas y datos espaciales 2D, y CouchDB parece tener una funcionalidad similar.

— MerseyViking
fuente

+1 La solución de unión (párrafo 3) en realidad puede ser extremadamente eficiente, porque los datos del Censo tienden a tener grupos de campos relacionados y, para cualquier análisis en particular, a menudo solo se necesita un pequeño número de estos grupos. De esta manera, miles de campos (no exagero: esto es común) se pueden dividir lógicamente en docenas de tablas y solo se necesita acceder a un pequeño número de esas tablas para cualquier mapa o análisis en particular.

— whuber

@MerseyViking, ¿cómo podría él (@scoball) dividir tablas o realizar las otras operaciones mencionadas si no puede importar los datos a ningún programa que manipule tablas? Los datos están en CSV.

— Pablo

@Pablo, creo que estás siendo injusto con MerseyViking: si se te permite escribir un script para importar tablas, lo que esencialmente te obliga a implementar tu solución, entonces él también, y no hay dificultad al escribir uno que sea completamente general y flexible. (Sé esto por experiencia porque lo hice para bases de datos del Censo extremadamente grandes). Además, sugiere muchas alternativas que funcionan alrededor de la limitación de 256 campos.

— whuber

"donde una columna representa una categoría en lugar de texto libre" Debe asignar manualmente esas columnas.

— Pablo

@Pablo Solo si está utilizando un software inadecuado :-). El flujo de trabajo en los párrafos 2-3 se puede hacer con solo unos pocos comandos usando casi cualquier programa estadístico moderno, por ejemplo. (Por supuesto, no estoy abogando por emplear un programa de este tipo en lugar de una base de datos; solo estoy señalando que con el conjunto adecuado de herramientas, todo en esta respuesta se puede lograr de manera fácil y eficiente.)

— whuber

Recientemente he tratado exactamente el mismo problema con los archivos CSV del perfil censal de Statistics Canada que contienen 2172 columnas. Puede importar su csv a una geodatabase de archivos ESRI (FGDB) si tiene acceso a ArcGIS. Según ESRI, el formato FGDB puede manejar 65.534 campos en una clase de entidad o tabla .

En mi caso, pude importar mi archivo CSV de 2172 columnas en una tabla FGDB sin ningún problema.

Una vez que obtenga toda la tabla en el FGDB, puede dividirla de la forma que desee (por ejemplo, lógicamente o según las limitaciones de db), asegurándose de mantener una columna de identificación única, para asegurarse de que pueda volver a unirla como desee. necesario.

— Brent Edwards
fuente

¡Interesante! Traté de importar desde csv a la geodatabase de archivos. Cuando lo configuré, miré la lista de variables que iba a importar y dejó de enumerarlas después de 256 variables, así que no procedí. Voy a echar otro vistazo.

— scoball

Echa un vistazo a este enlace: assets.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— Brent Edwards

Las geodatabases de archivos tienen límites altos, por lo que es posible que algo haya sucedido en la importación.

— nicksan

Corto:
Mi opción para datos con muchos atributos o con un tipo de atributo variable para cada objeto es usar el modelo de datos KEY / VALUE, se puede implementar y funciona muy bien en sql (recomendaría postgresql + postgis).

Descripción:
1) Tiene una tabla para características, digamos, puntos. Esta tabla contiene una ID y la GEOMETRÍA para cada punto.

2) Tiene una tabla más para los 'atributos' que son los pares clave / valor. Esta tabla tiene las columnas ID, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Ahora cada punto podría tener atributos virtualmente infinitos almacenados así:

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

OpenStreetMaps funciona así y funciona muy bien, mira aquí y aquí .

Para importar los datos, sugeriría un script de Python.

— Pablo
fuente

Esto a menudo se llama la forma "larga" de los datos y es bueno saberlo. Aunque está bien para el almacenamiento flexible, es inútil para cualquier tipo de análisis multivariado (que sería cualquier análisis que compare dos o más atributos).

— whuber

@whuber, no es inútil para el análisis multivariante, pero de hecho necesita un software muy estructurado o buenas habilidades de programación porque los datos deben prepararse, específicamente, transferirse a una tabla. Aquí uso la combinación de postgis + django (marco web de Python) para trabajar los datos del suelo (ph, al, clay, etc.) cuando necesito poner extractos de los datos en tablas antes de procesarlos. Se eligió este modelo porque la misma estructura procesará otros datos puntuales arbitrarios.

— Pablo

Bastante justo: debería haber dicho "inútil como es". Siempre que se conserve toda la información, y lo es, siempre puede procesar los datos en el formato que desee. El procesamiento es relativamente fácil utilizando los métodos de @ MerseyViking en comparación con el enfoque clave / valor. Además, cuando las tablas se hacen realmente grandes, comenzamos a preocuparnos por el tamaño total. La redundancia en el almacenamiento de clave / valor es tan grande que rara vez se usa para el análisis de conjuntos de datos muy grandes (no puedo hablar de la frecuencia de su uso exclusivamente para el almacenamiento)

— Whuber

No estoy de acuerdo con su solución porque no es fácil, por no decir imposible, dividir o manipular tablas si no puede abrir los datos en una base de datos. El usuario debe enviar datos directamente a la base de datos a través de una secuencia de comandos, y con el modelo de clave / valor puede usar la misma secuencia de comandos para cualquier dato sin la necesidad de mapear las columnas o categorizar los atributos.

— Pablo

Su solución parece, por su propia admisión, ser tan programáticamente compleja como la mía: necesita "buenas habilidades de programación". Simplemente recomendé mantener los datos en una forma que sea más eficiente para un RDBMS como PostgreSQL. Además, parece ser un punto discutible porque la respuesta de Brent muestra que el límite de 256 columnas es falso.

— MerseyViking