Tôi đã làm việc với cả ba cơ sở dữ liệu và thực hiện di chuyển giữa chúng, vì vậy hy vọng tôi vẫn có thể thêm thứ gì đó vào bài đăng cũ. Mười năm trước, tôi đã được giao nhiệm vụ đặt một đối tượng không gian lớn - 450 triệu không gian - tập dữ liệu từ GML vào cơ sở dữ liệu không gian. Tôi quyết định thử MySQL và Postgis, vào thời điểm đó không có không gian trong SQL Server và chúng tôi đã có một môi trường khởi động nhỏ, vì vậy MySQL có vẻ phù hợp. Sau đó tôi đã tham gia vào MySQL, tôi đã tham dự/nói chuyện tại một vài hội nghị và tham gia rất nhiều vào thử nghiệm beta về các chức năng tương thích với GIS trong MySQL mà cuối cùng đã được phát hành với phiên bản 5.5. Tôi sau đó đã được tham gia với việc di chuyển dữ liệu không gian của chúng tôi để Postgis và dữ liệu công ty của chúng tôi (với các yếu tố không gian) cho SQL Server. Đây là những phát hiện của tôi.
MySQL
1). Sự cố ổn định. Trong quá trình 5 năm, chúng tôi đã có một số vấn đề về cơ sở dữ liệu bị hỏng, chỉ có thể được khắc phục bằng cách chạy myismachk trên tệp chỉ mục, quá trình này có thể mất hơn 24 giờ trên bảng hàng 450 triệu.
2). Cho đến gần đây chỉ có các bảng MyISAM hỗ trợ kiểu dữ liệu không gian. Điều này có nghĩa là nếu bạn muốn hỗ trợ giao dịch, bạn đã hết may mắn. Loại bảng InnoDB hiện hỗ trợ các loại không gian, nhưng không hỗ trợ các chỉ mục trên chúng, với các kích thước điển hình của các tập dữ liệu không gian, không hữu ích lắm. Xem http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Kinh nghiệm của tôi từ việc đi đến hội nghị là không gian đã được rất nhiều suy nghĩ - chúng tôi đã thực hiện sao chép, phân vùng, vv, nhưng nó không hoạt động với không gian. EDIT: Trong upcoming 5.7.5 release InnoDB cuối cùng sẽ hỗ trợ các chỉ mục trên cột không gian, có nghĩa là ACID, khóa ngoài và chỉ mục không gian cuối cùng sẽ có sẵn trong cùng một công cụ.
3). Các chức năng không gian là vô cùng hạn chế so với cả Postgis và SQL Server không gian. Hiện vẫn còn không có chức năng ST_Union sẽ tác động đến toàn bộ một lĩnh vực hình học, một trong những thắc mắc tôi chạy thường xuyên nhất, ví dụ, bạn không thể viết:
select attribute, ST_Union(geom) from some_table group by some_attribute
mà là rất hữu ích trong một bối cảnh GIS. Select ST_Union(geom1, const_geom) from some_table, tức là, một trong những hình học là một hình học liên tục mã hóa cứng là một chút hạn chế trong so sánh.
4). Không hỗ trợ cho rasters. Việc có thể thực hiện phân tích kết hợp vectơ kết hợp trong một db là chức năng GIS rất hữu ích.
5). Không hỗ trợ chuyển đổi từ hệ thống tham chiếu không gian này sang hệ thống tham chiếu không gian khác.
6). Kể từ khi mua lại bởi Oracle, không gian đã thực sự được đưa vào giữ.
Nói chung, công bằng với MySQL, nó hỗ trợ trang web của chúng tôi, WMS và xử lý không gian chung trong nhiều năm và dễ thiết lập. Nhược điểm, dữ liệu tham nhũng là một vấn đề, và bằng cách buộc phải sử dụng các bảng MyISAM bạn đang từ bỏ rất nhiều lợi ích của một RDBMS.
PostGIS
Với những vấn đề chúng tôi đã có với MySQL, chúng tôi cuối cùng chuyển đổi sang PostGIS. Các điểm chính của trải nghiệm này đã được.
1). Cực kỳ ổn định. Không có dữ liệu tham nhũng trong 5 năm và bây giờ chúng tôi có khoảng 25 hộp Postgres/GIS trên centos máy ảo, theo mức độ tải khác nhau.
2). Tốc độ phát triển nhanh - raster, tô pô, hỗ trợ 3D là những ví dụ gần đây về điều này.
3). Cộng đồng rất tích cực. Kênh irc và danh sách gửi thư của Postgis là những tài nguyên tuyệt vời. Hướng dẫn tham khảo Postgis cũng rất tuyệt vời. http://postgis.net/docs/manual-2.0/
4). Chơi rất tốt với các ứng dụng khác, dưới ô OSGeo, chẳng hạn như GeoServer và GDAL.
5). Thủ tục được lưu trữ có thể được viết bằng nhiều ngôn ngữ, ngoài plpgsql mặc định, chẳng hạn như Python hoặc R.
5). Postgres là một RDBMS tuân thủ rất chuẩn, đầy đủ tính năng, nhằm duy trì các tiêu chuẩn ANSI.
6). Hỗ trợ các chức năng cửa sổ và truy vấn đệ quy - không phải trong MySQL, nhưng trong SQL Server. Điều này đã làm cho việc viết các truy vấn không gian phức tạp hơn rõ ràng hơn.
Máy chủ SQL.
Tôi chỉ sử dụng chức năng không gian SQL Server 2008 và nhiều phiền toái trong bản phát hành đó - thiếu hỗ trợ chuyển đổi từ CRS này sang CRS khác, cần thêm tham số của riêng bạn vào chỉ mục không gian - hiện có đã được giải quyết.
1). Vì các đối tượng không gian trong SQL Server về cơ bản là các đối tượng CLR, cú pháp cảm thấy ngược lại. Thay vì ST_Area (geom) bạn viết geom.STArea() và điều này trở nên rõ ràng hơn khi bạn kết nối các hàm với nhau. Việc giảm dấu gạch dưới trong các tên hàm chỉ đơn thuần là một sự khó chịu nhỏ.
2). Tôi đã có một số đa giác không hợp lệ đã được chấp nhận bởi SQL Server, và thiếu một chức năng ST_MakeValid có thể làm cho một chút đau đớn.
3). Chỉ dành cho Windows. Nói chung, các sản phẩm của Microsoft (như các sản phẩm ESRI) được thiết kế để hoạt động rất tốt với nhau, nhưng không phải lúc nào cũng có sự tuân thủ và tương thích của tiêu chuẩn như các mục tiêu chính. Nếu bạn đang chạy một cửa sổ chỉ có cửa hàng, đây không phải là một vấn đề.
CẬP NHẬT: đã phát một chút với SQL Server 2012, tôi có thể nói rằng nó đã được cải thiện đáng kể. Bây giờ có một hàm xác nhận hình học tốt, có hỗ trợ tốt cho kiểu dữ liệu Địa lý, bao gồm đối tượng GLOBE FULL, cho phép biểu diễn các đối tượng chiếm nhiều hơn một bán cầu và hỗ trợ cho Compound Curves and Circular Strings. và vòng kết nối) trong số những thứ khác. Việc chuyển đổi các tọa độ từ một CRS này sang một CRS khác vẫn cần được thực hiện trong các thư viện của bên thứ 3, mặc dù đây không phải là một nút hiển thị trong hầu hết các ứng dụng.Tôi đã không sử dụng SQL Server với bộ dữ liệu đủ lớn để so sánh một trên một với Postgis/MySQL, nhưng từ những gì tôi đã thấy các chức năng hoạt động chính xác, và trong khi không khá đầy đủ tính năng như Postgis, nó là một cải thiện các dịch vụ của MySQL.
Xin lỗi vì câu trả lời dài như vậy, tôi hy vọng một số nỗi đau và niềm vui mà tôi đã trải qua trong nhiều năm có thể giúp ích cho ai đó.
PostGIS sẽ là người trưởng thành nhất trong số các tùy chọn. –
PostGIS là giải pháp GIS trưởng thành nhất. Và nếu bạn đang sử dụng R, bạn thậm chí có thể sử dụng PL/R để viết các thủ tục lưu sẵn trong R. Các phần mở rộng không gian của MySQL khá mỏng và không đáng thử, khả năng của SQL Server GIS khá mới và có vẻ hơi hạn chế nhưng tôi có chưa có kinh nghiệm với nó. – Wolph
Câu hỏi tuyệt vời và quan trọng. Ý kiến dựa trên các sự kiện có giá trị. Không nên đóng cửa. – ErichBSchulz