Trộn các loại hình học trong một bảng PostGIS

Tôi đang đối mặt với vấn đề sau. Tôi phải di chuyển từ cơ sở dữ liệu Oracle sang PostgreSQL + PostGIS. Hiện tại tất cả các dạng hình học của tất cả các loại được lưu trữ trong một bảng và mỗi bản ghi chứa trường "nắp" cho biết các tính năng của cùng một lớp.

Những ưu và nhược điểm của việc sử dụng một phương pháp như vậy là gì? Tôi có nên chia dữ liệu thành nhiều bảng nếu tôi không cần sử dụng cơ sở dữ liệu với phần mềm của bên thứ ba? Điều gì về hiệu suất của các truy vấn không gian, các chỉ mục sẽ giúp tôi?

Nếu bạn không cần sự hỗ trợ của bên thứ ba và không thấy cần phải truy vấn bằng cách gõ giữ chúng trong cùng một bảng sẽ hoạt động tốt. Ngoài ra, bạn có thể sử dụng mô hình thừa kế như được thảo luận trong chương 3 của PostGIS in Action.

http://www.postgis.us/ch CHƯƠNG_03_edition_1

Từ góc độ kiến ​​trúc, PostGIS không thực sự quan tâm nếu trong một truy vấn, nhiều loại khác nhau được sử dụng. Nếu nó hoạt động tốt với bạn trong Oracle thì sẽ như thể không hoạt động tốt hơn trong PostGIS.

Có 2 lý do để phân tách nó (và có thể được thực hiện sau này khi cần thiết): 1) Ngăn chặn mọi người chèn các loại khác nhau mà bạn không muốn như bộ sưu tập hình học, chuỗi tròn và những gì không (mà bạn chỉ có thể xác định thủ công một ràng buộc )

2) Nếu bạn có một tỷ điểm và 1000 đa giác, và thực hiện nhiều điểm trong các bài kiểm tra đa giác, tốc độ sẽ tốt hơn nhiều nếu bạn truy vấn và thực hiện phép nối của mình - so với bảng tỷ tỷ đến 1000 bảng kỷ lục một tỷ đến tỷ. Đây sẽ là trường hợp cho bất kỳ cơ sở dữ liệu không gian nào tôi nghĩ (không cụ thể cho PostGIS). Điều này đúng với tất cả các truy vấn quan hệ tôi cũng sẽ đoán (không cụ thể đối với các truy vấn không gian).

Điều này thực sự làm phiền tôi. Tôi đoán đó là vì tôi đã thấy quá nhiều tệp CAD với dữ liệu trên một lớp, chỉ phân biệt bằng màu sắc.

Những gì nó nói đến thực sự là một sự lựa chọn giữa việc tổ chức dữ liệu theo cấu trúc hoặc theo thuộc tính .

Với sự lựa chọn đó, tôi sẽ luôn tổ chức dữ liệu của mình thông qua cấu trúc dữ liệu.

Để bắt đầu, khi xử lý dữ liệu, bạn có một vòng nhảy ít hơn (ví dụ: chọn a, b, c từ bảng trong đó id = X trái ngược với chọn a, b, c từ bảng trong đó id = X AND nắp = Y )

Sau đó, hãy xem xét tại sao cơ sở dữ liệu cho phép nhiều bảng - nếu một định dạng dữ liệu cung cấp các cấu trúc dữ liệu cụ thể mà bạn phải nghĩ rằng chúng sẽ xử lý dữ liệu hiệu quả hơn nếu bạn sử dụng chúng.

Nhưng vấn đề lớn (đối với tôi) là khi bạn muốn di chuyển dữ liệu ra và vào một hệ thống khác. Sau đó, tôi nghĩ rằng nó trở thành một thách thức thực sự, bởi vì ứng dụng cuối có thể không sử dụng dữ liệu theo cùng một cách. Tôi đã thấy rất nhiều người không thể tham gia vào kịch bản này.

Vì vậy - theo kinh nghiệm của tôi - bạn sẽ có thể sử dụng và truyền dữ liệu hiệu quả gấp đôi khi có mô hình dữ liệu phù hợp (sâu hơn và có cấu trúc hơn).