Как я могу обрабатывать таблицы с 256+ переменными?

Я работаю с данными переписи и скачал несколько CSV-файлов, каждый с 600-ю столбцами / переменными. Я хотел бы сохранить их все в базе данных с возможностью запроса, но все, что я пробовал до сих пор (MS Access, таблица базы геоданных Arc), усекает таблицу до 256 столбцов. Существуют ли решения для работы с большими таблицами, которые доступны для тех, кто не является администратором баз данных?

database census csv scoball
источник

При любом значении нормализации БД я подозреваю, что эти огромные таблицы следует разделить на несколько (или много) меньших таблиц, относящихся к их UID единицы переписи (может быть, блока?).

Рой

Ответы:

PostgreSQL имеет ограничение столбцов от 250 до 1600 «в зависимости от типов столбцов» и поддерживает пространственные данные и запросы с расширением PostGIS. Поэтому я был бы склонен сделать две вещи:

Во-первых, если столбец представляет категорию, а не свободный текст, создайте отдельную таблицу с этими категориями и замените столбец целочисленным идентификатором и ограничением внешнего ключа, ссылаясь на таблицу категорий.

Во-вторых, разбейте Third Normal Form, разделив большую таблицу на два или более логическим образом, и установите отношения один-к-одному между ними. Это, пожалуй, не самый эффективный, но если вам редко нужны некоторые данные, тогда запрос может быть просто на те таблицы, которые вы хотите.

Другой совершенно другой альтернативой может быть использование базы данных "NOSQL", такой как MongoDB, CouchDB и так далее. Не существует жестких ограничений размера «строки», и если данные отсутствуют для записи, это не должно занимать места.

Пространственная поддержка не так хороша для таких типов больших таблиц, но MongoDB поддерживает двухмерные пространственные запросы и данные, и CouchDB, похоже, обладает аналогичной функциональностью.

MerseyViking
источник

+1 Решение о соединении (параграф 3) на самом деле может быть чрезвычайно эффективным, поскольку данные переписи, как правило, имеют группы связанных полей, и для любого конкретного анализа часто требуется только небольшое количество этих групп. Таким образом, тысячи полей (я не преувеличиваю: это обычное явление) могут быть логически разбиты на десятки таблиц, и для любой конкретной карты или анализа необходимо получить доступ только к небольшому количеству этих таблиц.

whuber

@MerseyViking, Как он (@scoball) может разбивать таблицы или выполнять другие упомянутые операции, если он не может импортировать данные в любую программу, которая управляет таблицами? данные в CSV.

Пабло

@Pablo, я думаю, что вы несправедливы по отношению к MerseyViking: если вам разрешено писать сценарий для импорта таблиц - что вы, по сути, вынуждены для реализации своего решения - то он тоже, и в этом нет никаких трудностей. в письменном виде, который является полностью общим и гибким. (Я знаю это из опыта, потому что я сделал это для очень больших баз данных переписи.) Кроме того, он предлагает много альтернатив, которые обходят ограничение в 256 полей.

whuber

«где столбец представляет категорию, а не свободный текст». Вы должны вручную сопоставить эти столбцы.

Пабло

@Pablo Только если вы используете неадекватное программное обеспечение :-). Рабочий процесс в параграфах 2-3 может быть выполнен с помощью нескольких команд, например, с использованием практически любой современной статистической программы. (Конечно, я не защищаю использование такой программы вместо базы данных; я просто указываю, что с надлежащим набором инструментов все в этом ответе может быть выполнено легко и эффективно.)

whuber

Недавно я имел дело с той же самой проблемой с файлами CSV профиля переписи Статистического управления Канады, содержащими 2172 столбца. Вы можете импортировать свой CSV в файловую базу геоданных ESRI (FGDB), если у вас есть доступ к ArcGIS. Согласно ESRI, формат FGDB может обрабатывать 65 534 поля в классе пространственных объектов или таблице .

В моем случае мне удалось без проблем импортировать мой CSV-файл шириной 2172 в таблицу FGDB.

Как только вы поместите всю таблицу в FGDB, вы можете нарезать ее по своему усмотрению (например, логически или на основе ограничений по БД), убедившись, что вы сохраняете столбец уникального идентификатора, чтобы гарантировать, что вы можете объединить его вместе как необходимо.

Брент Эдвардс
источник

Интересно! Я попытался сделать импорт из CSV в файловую базу геоданных. Когда я его настраивал, я посмотрел список переменных, которые он собирался импортировать, и перестал перечислять их после 256 переменных, поэтому я не продолжил. Я еще раз посмотрю.

scoball

Проверьте эту ссылку: assets.nhgis.org/How_to_Import_256_Columns_GIS.pdf

Брент Эдвардс

Файловые базы геоданных имеют высокие ограничения, поэтому, возможно, что-то произошло при импорте.

Никсан

Коротко:
Мой вариант для данных с большим количеством атрибутов или с переменным типом атрибута для каждого объекта - использовать модель данных KEY / VALUE, она может быть реализована и очень хорошо работает в SQL (я бы порекомендовал postgresql + postgis).

Описание:
1) У вас есть одна таблица для функций, скажем, очков. Эта таблица содержит ID и ГЕОМЕТРИЮ для каждой точки.

2) У вас есть еще одна таблица для «атрибутов», представляющая собой пары ключ / значение. Эта таблица имеет идентификатор столбцов, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Теперь каждая точка может иметь практически бесконечные атрибуты, хранящиеся так:

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

OpenStreetMaps работает так и работает очень хорошо, смотрите здесь и здесь .

Для импорта данных я бы предложил скрипт на python.

Pablo
источник

Это часто называют «длинной» формой данных, о которой полезно знать. Хотя это подходит для гибкого хранения, оно бесполезно для любого многомерного анализа (который будет любым анализом, сравнивающим два или более атрибута).

whuber

@whuber, это не бесполезно для многомерного анализа, но на самом деле вам нужно очень структурированное программное обеспечение или хорошие навыки программирования, потому что данные должны быть подготовлены, в частности, перенесены в таблицу. Здесь я использую комбинацию postgis + django (веб-фреймворк Python) для обработки данных почвы (ph, al, clay и т. Д.), Когда мне нужно, перед обработкой я помещаю отрывки данных в таблицы. Эта модель была выбрана потому, что та же структура будет обрабатывать другие произвольные точечные данные.

Пабло

Справедливо: мне следовало сказать «бесполезен как есть». При условии, что вся информация сохраняется - и это так - вы всегда можете обработать данные в любом формате, который вы хотите. Обработка относительно проста с использованием методов @ MerseyViking по сравнению с подходом ключ / значение. Кроме того, когда таблицы становятся действительно большими, мы начинаем беспокоиться об общем размере. Избыточность в хранилище ключей / значений настолько велика, что редко используется для анализа очень больших наборов данных (я не могу говорить о частоте его использования исключительно для хранения.)

whuber

Я не согласен с его решением, потому что нелегко, если не сказать невозможно, разбивать или манипулировать таблицами, если вы не можете открыть данные в базе данных. Пользователь должен отправлять данные непосредственно в базу данных через сценарий, и с моделью ключ / значение вы можете использовать один и тот же сценарий для любых данных без необходимости сопоставлять столбцы или классифицировать атрибуты.

Пабло

По твоему признанию, твоё решение кажется таким же сложным в программном отношении, как и моё, - требующее «хороших навыков программирования». Я просто выступал за сохранение данных в форме, наиболее эффективной для СУБД, такой как PostgreSQL. Кроме того, это, кажется, спорный вопрос, потому что ответ Брента показывает, что ограничение в 256 столбцов является поддельным.

MerseyViking