Jak obsłużyć tabele zawierające ponad 256 zmiennych?

Pracuję z danymi spisu i pobrałem kilka plików CSV, każdy z 600 kolumnami / zmiennymi. Chciałbym przechowywać je wszystkie w bazie danych z możliwością zapytania, ale wszystko, co do tej pory próbowałem (MS Access, Arc geobaza danych tabeli) skraca tabelę do 256 kolumn. Czy są jakieś rozwiązania do obsługi dużych tabel, które są dostępne dla kogoś, kto nie jest DBA?

database census csv

— scoball
źródło

Przy dowolnej ilości normalizacji DB podejrzewam, że te ogromne tabele powinny być podzielone na kilka (lub wiele) mniejszych tabel odnoszących się do ich jednostki spisu powszechnego (być może bloku?).

— Roy,

Odpowiedzi:

PostgreSQL ma limit kolumn od 250 do 1600 „w zależności od typów kolumn” i obsługuje dane przestrzenne oraz zapytania z rozszerzeniem PostGIS. Byłbym skłonny zrobić dwie rzeczy:

Po pierwsze, gdy kolumna reprezentuje kategorię zamiast tekstu swobodnego, utwórz oddzielną tabelę z tymi kategoriami i zastąp kolumnę identyfikatorem liczby całkowitej oraz ograniczeniem klucza obcego, odwołując się do tabeli kategorii.

Po drugie, przełam Trzecią Normalną Formę, dzieląc duży stół na dwie lub więcej w logiczny sposób i ustal relację jeden do jednego między nimi. Nie jest to może najbardziej wydajne, ale jeśli rzadko potrzebujesz niektórych danych, zapytanie może znajdować się w tabelach, które chcesz.

Inną zupełnie inną alternatywą byłoby użycie bazy danych „NOSQL”, takiej jak MongoDB, CouchDB i tak dalej. Nie ma sztywnych limitów rozmiaru „wiersza”, a jeśli dane nie występują w rekordzie, nie musi zajmować miejsca.

Obsługa przestrzenna nie jest tak dobra dla tego typu dużych baz danych, ale MongoDB obsługuje zapytania przestrzenne i dane 2D, a CouchDB wydaje się mieć podobną funkcjonalność.

— MerseyViking
źródło

+1 Rozwiązanie łączenia (akapit 3) faktycznie może być niezwykle wydajne, ponieważ dane ze spisu powszechnego mają zwykle grupy powiązanych pól i do każdej konkretnej analizy często potrzebna jest tylko niewielka liczba tych grup. W ten sposób tysiące pól (nie przesadzam: jest to powszechne) można logicznie podzielić na dziesiątki tabel i tylko niewielka liczba tych tabel musi być dostępna dla każdej konkretnej mapy lub analizy.

— whuber

@MerseyViking, jak mógł (@scoball) dzielić tabele lub wykonywać inne wymienione operacje, jeśli nie może zaimportować danych do żadnego programu, który manipuluje tabelami? dane są w CSV.

— Pablo,

@Pablo, myślę, że jesteś niesprawiedliwy wobec MerseyViking: jeśli możesz napisać skrypt do importowania tabel - do czego zasadniczo jesteś zmuszony w celu wdrożenia swojego rozwiązania - to on też, i nie ma trudności na piśmie taki, który jest całkowicie ogólny i elastyczny. (Wiem to z doświadczenia, ponieważ zrobiłem to dla bardzo dużych baz danych spisu powszechnego.) Ponadto sugeruje wiele alternatyw, które działają wokół ograniczenia 256 pól.

— whuber

„gdzie kolumna reprezentuje kategorię zamiast tekstu swobodnego” Musisz ręcznie zmapować te kolumny.

— Pablo,

@Pablo Tylko jeśli używasz nieodpowiedniego oprogramowania :-). Przepływ pracy w paragrafach 2-3 można wykonać za pomocą zaledwie kilku poleceń, na przykład przy użyciu prawie dowolnego nowoczesnego programu statystycznego. (Oczywiście nie opowiadam się za zastosowaniem takiego programu zamiast bazy danych; po prostu wskazuję, że przy użyciu odpowiedniego zestawu narzędzi wszystko w tej odpowiedzi można wykonać łatwo i skutecznie.)

— whuber

Niedawno zajmowałem się dokładnie tym samym problemem z plikami CSV profilu spisowego Statistics Canada zawierającymi 2172 kolumny. Możesz zaimportować swoje csv do Geobazy danych pliku ESRI (FGDB), jeśli masz dostęp do ArcGIS. Według ESRI format FGDB może obsłużyć 65 534 pól w klasie elementów lub tabeli .

W moim przypadku udało mi się bez problemu zaimportować plik CSV o szerokości 2172 kolumn do tabeli FGDB.

Po przeniesieniu całej tabeli do FGDB możesz pokroić ją w dowolny sposób (np. Logicznie lub na podstawie ograniczeń db), upewniając się, że zachowałeś unikalną kolumnę id, aby mieć pewność, że możesz połączyć ją z powrotem jako potrzebne.

— Brent Edwards
źródło

Ciekawy! Próbowałem wykonać import z csv do pliku geobazy. Kiedy go konfigurowałem, spojrzałem na listę zmiennych, które zamierzał zaimportować i przestał wyświetlać je po 256 zmiennych, więc nie kontynuowałem. Spojrzę jeszcze raz.

— scoball,

Sprawdź ten link: resources.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— Brent Edwards

Geobazie plików mają wysokie limity, więc możliwe, że coś się stało podczas importu.

— nicksan

Krótko:
Moją opcją dla danych z dużą liczbą atrybutów lub ze zmiennym typem atrybutu dla każdego obiektu jest użycie modelu danych KEY / VALUE, można go zaimplementować i działa bardzo dobrze w sql (polecam postgresql + postgis).

Opis:
1) Masz jedną tabelę dla funkcji, powiedzmy, punktów. Ta tabela zawiera ID i GEOMETRIĘ dla każdego punktu.

2) Masz jeszcze jedną tabelę dla „atrybutów”, które są parami klucz / wartość. Ta tabela ma identyfikator kolumny, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Teraz każdy punkt może mieć przechowywane praktycznie nieskończone atrybuty:

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

OpenStreetMaps działa w ten sposób i działa bardzo dobrze, zobacz tutaj i tutaj .

Aby zaimportować dane, sugerowałbym skrypt w języku Python.

— Pablo
źródło

Jest to często nazywane „długą” formą danych i warto o tym wiedzieć. Chociaż jest to odpowiednie dla elastycznego przechowywania, jest bezużyteczne dla wszelkiego rodzaju analizy wielowymiarowej (która byłaby dowolną analizą porównującą dwa lub więcej atrybutów).

— whuber

@ Whuber, nie jest to bezużyteczne do analizy wielowymiarowej, ale w rzeczywistości potrzebujesz bardzo ustrukturyzowanego oprogramowania lub dobrych umiejętności programistycznych, ponieważ dane muszą zostać przygotowane, a konkretnie przesłane do tabeli. Tutaj używam kombinacji postgis + django (framework sieci python) do pracy z danymi gleby (ph, al, glina itp.), Kiedy potrzebuję, umieszczam fragmenty danych w tabelach przed przetwarzaniem. Ten model został wybrany, ponieważ ta sama struktura będzie przetwarzać inne arbitralne dane punktowe.

— Pablo,

W porządku: powinienem powiedzieć „bezużyteczne jak jest”. Pod warunkiem, że wszystkie informacje zostaną zachowane - i tak jest - zawsze możesz przetwarzać dane w dowolnym formacie. Przetwarzanie jest stosunkowo łatwe przy użyciu metod @ MerseyViking w porównaniu z podejściem klucz / wartość. Ponadto, gdy tabele stają się naprawdę duże, zaczynamy się martwić o całkowity rozmiar. Nadmiarowość w przechowywaniu kluczy / wartości jest tak duża, że rzadko jest używana do analizy bardzo dużych zestawów danych (nie mogę mówić o częstotliwości jej wykorzystania wyłącznie do przechowywania.)

— whuber

Nie zgadzam się z jego rozwiązaniem, ponieważ dzielenie tabel lub manipulowanie nimi nie jest łatwe, a nawet niemożliwe, jeśli nie można otworzyć danych w bazie danych. Użytkownik musi wysłać dane bezpośrednio do bazy danych za pomocą skryptu, a dzięki modelowi klucz / wartość możesz użyć tego samego skryptu dla dowolnych danych bez potrzeby mapowania kolumn lub kategoryzacji atrybutów.

— Pablo,

Jak sam przyznaje, twoje rozwiązanie wydaje się być tak złożone programowo, jak moje - wymagające „dobrych umiejętności programowania”. Po prostu zalecałem przechowywanie danych w formie, która jest najbardziej wydajna dla RDBMS, takiego jak PostgreSQL. Poza tym wydaje się, że jest to kwestia sporna, ponieważ odpowiedź Brenta pokazuje, że limit 256 kolumn jest fałszywy.

— MerseyViking,