Làm cách nào tôi có thể xử lý các bảng có hơn 256 biến?

Tôi đang làm việc với dữ liệu điều tra dân số và đã tải xuống một số tệp CSV, mỗi tệp có 600 cột / biến. Tôi muốn lưu trữ tất cả chúng trong cơ sở dữ liệu có thể truy vấn, nhưng mọi thứ tôi đã thử cho đến nay (MS Access, bảng cơ sở dữ liệu địa lý Arc) cắt ngắn bảng thành 256 cột. Có giải pháp nào để xử lý các bảng lớn có thể truy cập được đối với người không phải là DBA không?

database census csv

— scoball
nguồn

Với bất kỳ số lượng Chuẩn hóa DB nào, tôi nghi ngờ rằng các bảng khổng lồ này nên được tách thành nhiều (hoặc nhiều) bảng nhỏ hơn liên quan đến đơn vị Điều tra dân số (có thể là khối?).

— Roy

Câu trả lời:

PostgreSQL có giới hạn cột trong khoảng từ 250 đến 1600 "tùy thuộc vào loại cột" và hỗ trợ dữ liệu không gian và truy vấn với tiện ích mở rộng PostGIS. Vì vậy, tôi sẽ có xu hướng làm hai điều:

Đầu tiên, trong đó một cột biểu thị một danh mục thay vì văn bản tự do, hãy tạo một bảng riêng với các danh mục đó và thay thế cột bằng ID số nguyên và ràng buộc khóa ngoài, tham chiếu bảng danh mục.

Thứ hai, phá vỡ hình thức bình thường thứ ba bằng cách chia bảng lớn thành hai hoặc nhiều hơn theo một cách hợp lý nào đó và thiết lập mối quan hệ một-một giữa chúng. Đây có lẽ không phải là hiệu quả nhất, nhưng nếu bạn hiếm khi cần một số dữ liệu, thì truy vấn có thể chỉ nằm trên các bảng bạn muốn.

Một cách khác hoàn toàn khác là sử dụng cơ sở dữ liệu "NOSQL" như MongoDB, CouchDB, v.v. Không có giới hạn cứng cho kích thước "hàng" và nếu dữ liệu không có trong hồ sơ, nó sẽ không chiếm bất kỳ không gian nào.

Hỗ trợ không gian không tốt cho các loại cơ sở dữ liệu bigtable này, nhưng MongoDB hỗ trợ các truy vấn và dữ liệu không gian 2D và CouchDB dường như có chức năng tương tự.

— MerseyViking
nguồn

+1 Giải pháp tham gia (đoạn 3) thực sự có thể cực kỳ hiệu quả, vì dữ liệu Điều tra dân số có xu hướng có các nhóm lĩnh vực liên quan và đối với bất kỳ phân tích cụ thể nào, người ta thường chỉ cần một số lượng nhỏ các nhóm này. Theo cách này, hàng ngàn trường (tôi không phóng đại: điều này là phổ biến) có thể bị phá vỡ một cách hợp lý trên hàng chục bảng và chỉ một số lượng nhỏ các bảng đó cần được truy cập cho bất kỳ bản đồ hoặc phân tích cụ thể nào.

— whuber

@MerseyViking, Làm thế nào anh ta (@scoball) có thể chia bảng hoặc thực hiện các thao tác được đề cập khác nếu anh ta không thể nhập dữ liệu vào bất kỳ chương trình nào thao túng bảng? dữ liệu ở dạng CSV.

— Pablo

@Pablo, tôi nghĩ rằng bạn không công bằng với MerseyViking: nếu bạn được phép viết một kịch bản để nhập các bảng - mà về cơ bản bạn buộc phải thực hiện giải pháp của mình - thì anh ta cũng vậy, và không có khó khăn gì bằng văn bản một là hoàn toàn chung chung và linh hoạt. (Tôi biết điều này từ kinh nghiệm vì tôi đã thực hiện nó cho cơ sở dữ liệu Điều tra dân số cực kỳ lớn.) Ngoài ra, ông đề xuất nhiều giải pháp thay thế hoạt động xung quanh giới hạn 256 trường.

— whuber

"Trong đó một cột biểu thị một danh mục thay vì văn bản miễn phí" Bạn phải ánh xạ thủ công các cột đó.

— Pablo

@Pablo Chỉ khi bạn đang sử dụng phần mềm không đầy đủ :-). Ví dụ, quy trình làm việc trong các đoạn 2-3 có thể được thực hiện chỉ bằng một vài lệnh sử dụng hầu hết mọi chương trình thống kê hiện đại. (Tất nhiên tôi không ủng hộ việc sử dụng một chương trình như vậy thay cho cơ sở dữ liệu; tôi chỉ chỉ ra rằng với bộ công cụ thích hợp , mọi thứ trong câu trả lời này có thể được thực hiện dễ dàng và hiệu quả.)

— whuber

Gần đây tôi đã xử lý vấn đề tương tự chính xác với các tệp CSV hồ sơ điều tra dân số thống kê Canada chứa 2172 cột. Bạn có thể nhập csv của mình vào Cơ sở dữ liệu địa lý tệp ESRI (FGDB) nếu bạn có quyền truy cập vào ArcGIS. Theo ESRI, định dạng FGDB có thể xử lý 65.534 trường trong một lớp tính năng hoặc bảng .

Trong trường hợp của tôi, tôi đã có thể nhập tệp CSV rộng 2172 cột của mình vào bảng FGDB mà không gặp sự cố nào.

Khi bạn đưa toàn bộ bảng vào FGDB, bạn có thể cắt nó theo bất kỳ cách nào bạn thích (ví dụ: logic hoặc dựa trên các giới hạn db), đảm bảo rằng bạn giữ một cột id duy nhất, để đảm bảo rằng bạn có thể nối lại với nhau như cần thiết

— Brent Edwards
nguồn

Hấp dẫn! Tôi đã cố gắng thực hiện nhập từ csv để tập tin geodatabase. Khi tôi cài đặt nó, tôi đã xem danh sách các biến nó sẽ nhập và nó đã dừng liệt kê chúng sau 256 biến, vì vậy tôi đã không tiếp tục. Tôi sẽ có một cái nhìn khác.

— scoball

Kiểm tra liên kết này: property.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— Brent Edwards

Cơ sở dữ liệu địa lý tệp có giới hạn cao, vì vậy có thể đã xảy ra sự cố trong quá trình nhập.

— nicksan

Ngắn gọn:
Tùy chọn của tôi cho dữ liệu có nhiều thuộc tính hoặc với loại thuộc tính biến đổi cho từng đối tượng là sử dụng mô hình dữ liệu KEY / VALUE, nó có thể được triển khai và hoạt động rất tốt, trong sql (tôi muốn giới thiệu postgresql + postgis).

Mô tả:
1) Bạn có một bảng cho các tính năng, giả sử, điểm. Bảng này chứa ID và GEOMETRY cho mỗi điểm.

2) Bạn có thêm một bảng cho 'thuộc tính' là cặp khóa / giá trị. Bảng này có các cột ID, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Bây giờ mỗi điểm có thể có các thuộc tính gần như vô hạn được lưu trữ như thế:

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

OpenStreetMaps hoạt động như thế và hoạt động rất tốt, xem tại đây và đây .

Để nhập dữ liệu, tôi sẽ chọn một tập lệnh python.

— Pablo
nguồn

Đây thường được gọi là dạng "dài" của dữ liệu và rất tốt để biết về nó. Mặc dù không thể lưu trữ linh hoạt, nhưng nó vô dụng đối với bất kỳ loại phân tích đa biến nào (sẽ là bất kỳ phân tích nào so sánh hai hoặc nhiều thuộc tính).

— whuber

@whuber, nó không vô dụng đối với phân tích đa biến, nhưng thực sự bạn cần một phần mềm rất có cấu trúc hoặc kỹ năng lập trình tốt vì dữ liệu cần phải được chuẩn bị, cụ thể, được chuyển vào một bảng. Ở đây tôi sử dụng kết hợp postgis + django (khung web python) để xử lý dữ liệu đất (ph, al, clay, v.v.) khi tôi cần tôi trích đoạn dữ liệu vào bảng trước khi xử lý. Mô hình này được chọn vì cấu trúc tương tự sẽ xử lý dữ liệu đúng giờ khác tùy ý.

— Pablo

Đủ công bằng: tôi nên nói "vô dụng như vậy." Miễn là tất cả thông tin được giữ lại - và đó là - bạn luôn có thể xử lý dữ liệu thành bất kỳ định dạng nào bạn muốn. Việc xử lý tương đối dễ dàng bằng cách sử dụng các phương thức của @ MerseyViking so với phương pháp khóa / giá trị. Ngoài ra, khi các bảng trở nên thực sự lớn, chúng tôi bắt đầu quan tâm đến tổng kích thước. Sự dư thừa trong lưu trữ khóa / giá trị lớn đến mức hiếm khi được sử dụng để phân tích các bộ dữ liệu rất lớn (tôi không thể nói về tần suất sử dụng của nó hoàn toàn để lưu trữ.)

— whuber

Tôi không đồng ý với giải pháp của anh ấy vì không dễ, không thể nói là không thể, phân tách hoặc thao tác các bảng nếu bạn không thể mở dữ liệu trong cơ sở dữ liệu. Người dùng cần gửi dữ liệu trực tiếp đến cơ sở dữ liệu một đoạn mã và với mô hình khóa / giá trị, bạn có thể sử dụng cùng một đoạn mã cho bất kỳ dữ liệu nào mà không cần phải ánh xạ các cột hoặc phân loại các thuộc tính.

— Pablo

Giải pháp của bạn dường như, bằng sự thừa nhận của riêng bạn, phức tạp về mặt lập trình như của tôi - cần "kỹ năng lập trình tốt". Tôi chỉ chủ trương giữ dữ liệu ở dạng hiệu quả nhất cho RDBMS như PostgreQuery. Ngoài ra, nó dường như là một điểm cần thiết vì câu trả lời của Brent cho thấy giới hạn cột 256 là không có thật.

— MerseyViking