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?
10
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ść.
źródło
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.
źródło
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:
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.
źródło