Các cơ sở dữ liệu địa lý cá nhân phù hợp hơn để truy vấn nhanh các thuộc tính được lập chỉ mục so với cơ sở dữ liệu địa lý tệp?

Tôi đang chuẩn bị dữ liệu cho ứng dụng ArcGIS Engine truy vấn dữ liệu để tìm kiếm địa chỉ. Đôi khi chúng tôi chỉ tìm kiếm trên trường tên phố, chỉ trên trường số nhà hoặc cả hai. Khi sử dụng cơ sở dữ liệu địa lý cá nhân hoặc cơ sở dữ liệu địa lý SDE, người ta có thể thêm một chỉ mục thuộc tính nhiều cột bên cạnh các chỉ mục cột đơn. Vì một số lý do, theo bài viết Tạo chỉ mục thuộc tính ESRI, chỉ mục thuộc tính nhiều cột là không thể khi sử dụng cơ sở dữ liệu địa lý tệp. Họ không đề cập đến lý do tại sao lại như vậy - có thể tệp cơ sở dữ liệu địa lý không cần chúng vì một số lý do?

Một chỉ mục nhiều cột trên trường số nhà và trường tên phố về mặt lý thuyết sẽ cải thiện hiệu suất truy vấn của tôi khi tìm kiếm cả hai trường cùng một lúc, nhưng có đáng để chuyển sang sử dụng cơ sở dữ liệu địa lý cá nhân không? Tôi có cảm giác rằng những nhược điểm của việc sử dụng cơ sở dữ liệu địa lý cá nhân có thể phủ nhận những lợi ích của chỉ mục nhiều cột.

Tôi đã có ấn tượng rằng Esri muốn chúng tôi tránh xa cơ sở dữ liệu địa lý cá nhân, nhưng đây có phải là trường hợp cơ sở dữ liệu địa lý cá nhân là lựa chọn tốt hơn? Nếu bạn có bất kỳ kinh nghiệm nào với điều này, tôi rất muốn biết.

Để trả lời phần đầu tiên của câu hỏi của bạn, tôi nghĩ rằng sẽ giúp xem xét văn bản bổ sung trong tệp trợ giúp Tạo chỉ mục thuộc tính về các chỉ mục nhiều cột.

Thứ tự mà các trường xuất hiện trong một chỉ mục nhiều màu là quan trọng. Trong một chỉ mục nhiều màu với cột A trước cột B, cột A sẽ được sử dụng để tiến hành tìm kiếm ban đầu. Ngoài ra, một chỉ mục như vậy sẽ hữu ích hơn nhiều đối với các truy vấn chỉ liên quan đến cột A so với các truy vấn chỉ liên quan đến cột B.
Tạo một chỉ mục nhiều màu trên A và B. Chỉ mục này thường hiệu quả hơn cho các truy vấn liên quan đến cả hai cột. Đối với các truy vấn chỉ liên quan đến A, chỉ mục này sẽ chậm hơn chỉ mục trên A một mình. Chỉ mục này sẽ ít được sử dụng cho các truy vấn chỉ liên quan đến B. Để bù lại, bạn có thể tạo một chỉ mục bổ sung trên B.

Cả hai đoạn này cho thấy các chỉ mục nhiều cột tốt hơn cho việc sử dụng chuyên biệt. Hơn nữa, việc sử dụng một chỉ mục như vậy để sắp xếp chỉ một trong các cột được bao gồm, thực sự có thể ảnh hưởng đến hiệu suất. Vì lý do này, có khả năng các chỉ mục cột riêng lẻ sẽ cần thiết cho từng thuộc tính được bao gồm trong một chỉ mục nhiều cột.

Tôi đã tìm thấy một liên kết đến một tài liệu cũ, nhưng thú vị bằng ESRI nêu 9 lý do để chọn Tệp qua GDB cá nhân . Điều thú vị ở chỗ nó đặc biệt gọi hiệu suất là một lý do. Một phần của hiệu suất này là do hệ thống lưu trữ dựa trên tệp. Tôi nghĩ rằng điều này cũng có thể chơi trong việc thiếu hỗ trợ nhiều cột. Không giống như trong GDB cá nhân, là một tệp duy nhất, một chỉ mục trong Tệp GDB được lưu trữ dưới dạng một tệp riêng biệt trong cấu trúc GDB. Điều này có nghĩa là tệp chỉ mục và tệp thuộc tính cho một featureclass cụ thể sẽ phải được liên kết và truy cập cùng nhau. Tôi có thể thấy một chỉ mục nhiều cột sẽ dẫn đến việc nhảy qua lại giữa các tệp chỉ mục và thuộc tính và có khả năng gây ra hiệu năng đạt hiệu quả vượt xa mức tăng hiệu suất lập chỉ mục.

Vì đã có hiệu suất tăng đáng kể với Tệp GDB so với GDB cá nhân, có lẽ không đáng để thực hiện chỉ mục nhiều cột.

Theo kinh nghiệm làm việc với cả hai loại GDB, tôi đã thấy GDB cá nhân chạy lớn hơn khoảng 50% so với tệp. Dựa trên dữ liệu bạn đã cung cấp về Tệp GDB của mình, nếu bạn chuyển đổi sang PGDB, có thể bạn sẽ kết thúc với ~ 300 MB GDB cá nhân. Từ những gì tôi đã thấy, làm việc với cơ sở dữ liệu MS Access, cả trong các sản phẩm ESRI và riêng biệt, là bạn bắt đầu thấy sự suy giảm hiệu suất khi các tệp ".mdb" tăng kích thước đáng kể trên 100 MB.

Vấn đề khác có thể là ngay cả khi bạn có thể tăng tốc tìm kiếm thuộc tính của mình, bạn sẽ thấy một hiệu suất lớn liên quan đến việc di chuyển trong khung dữ liệu và làm mới chế độ xem. Lớp chỉ đơn giản là không vẽ nhanh như trong PGDB. Bài viết này so sánh các loại cơ sở dữ liệu địa lý cung cấp thêm thông tin về sự khác biệt hiệu suất.

Cũng như rất nhiều thứ, sự lựa chọn tốt nhất cuối cùng sẽ làm rõ trường hợp sử dụng của bạn là gì. Nếu có nhiều hoạt động cụ thể của cơ sở dữ liệu mà bạn muốn thực hiện, như truy vấn và cập nhật, bạn có thể thực hiện trong giao diện Access, thì GDB cá nhân có thể tốt hơn. Nếu bạn chỉ có kế hoạch thực hiện một số truy vấn, nhưng chủ yếu sẽ trực quan hóa dữ liệu không gian, thì hiệu suất chắc chắn nằm ở phía của Tệp GDB.

Có ít nhất 9 lý do hàng đầu để sử dụng Cơ sở dữ liệu địa lý tệp trên Cơ sở dữ liệu địa lý cá nhân. Thật không may, vẫn còn rất nhiều lý do để giữ PGDB cũ; tiến thoái lưỡng nan của bạn là một trong số họ. (không có ấn phẩm ESRI về chủ đề này)

Tôi tin rằng mục đích chính của FGDB trên PGDB là dung lượng lưu trữ và hiệu suất của dữ liệu không gian (tốc độ vẽ, truy xuất, lập chỉ mục không gian, truy vấn không gian, v.v.) chứ không phải là chức năng như chỉ mục "thuộc tính" nhiều cột và các hàm SQL nâng cao khác. thường là một phần không thể thiếu của bất kỳ DBMS nào. (PGDB dựa trên MS Access nào và FGDB gốc ESRI không) Như một ghi chú bên lề; Giới hạn kích thước tệp tối đa của cơ sở dữ liệu MS Access là 2GB, cũng là kích thước tối đa của bất kỳ PGDB nào. Ngược lại, giới hạn kích thước tệp FGDB là 1TB có thể sử dụng đến 256TB.

ESRI cũng nói rằng: Cú pháp bạn sử dụng để xây dựng biểu thức SQL khác nhau tùy thuộc vào nguồn dữ liệu. Điều này là do mặc dù SQL là một tiêu chuẩn, nhưng không phải tất cả các phần mềm cơ sở dữ liệu đều thực hiện cùng một phương ngữ của SQL. và Để truy vấn dữ liệu dựa trên tệp, bao gồm cơ sở dữ liệu địa lý tệp, bìa, shapefiles, bảng INFO, bảng dBASE, CAD và dữ liệu VPF, bạn sử dụng một phương ngữ của SQL được triển khai trong ArcGIS hỗ trợ một tập hợp con các tính năng và chức năng có sẵn trong cá nhân và Cơ sở dữ liệu địa lý ArcSDE.

Nói cách khác (và PGDB và ArcSDE GDB là một bằng chứng về điều đó) nếu cơ sở dữ liệu địa lý cơ sở DBMS hỗ trợ chức năng này thì nó sẽ có sẵn . Đây có thể là lý do tại sao bạn có thể tạo chỉ mục nhiều cột trong PGDB có cơ sở dữ liệu MS Access nằm bên dưới. Tương tự với bất kỳ cơ sở dữ liệu địa lý ArcSDE nào với DBMS cơ bản hỗ trợ chức năng này.

Đối với Cơ sở dữ liệu địa lý tệp ; tại bản phát hành FGDB 9.2, ESRI đã nhấn mạnh rằng một số tính năng và chức năng này có thể được thêm vào trong các bản phát hành FGDB trong tương lai, trích dẫn; "Cơ sở dữ liệu địa lý tệp không hỗ trợ tất cả các tính năng và chức năng có sẵn cho cơ sở dữ liệu địa lý cá nhân. Tại ArcGIS 9.2, các chức năng được sử dụng phổ biến nhất không được hỗ trợ bởi cơ sở dữ liệu địa lý tệp bao gồm DISTINCT, GROUP BY và ORDER BY và các chức năng thiết lập AVG, COUNT, MIN, MAX và SUM không được hỗ trợ bên ngoài các truy vấn con. Hỗ trợ cho một số trong số này có thể sẽ được thêm vào trong các bản phát hành trong tương lai. "

Bốn năm sau tại phiên bản 10, không có chức năng và tính năng nào trong số này có sẵn. ( Danh sách các chức năng có sẵn )

Dường như FGDB là một công việc đang tiến triển và nó cần các khả năng lập chỉ mục nhiều cột nhiều như nó cần tất cả các hàm DBMS SQL cần thiết. Tôi đoán rằng chúng ta sẽ bị mắc kẹt với PGDB cho đến khi các nhà phát triển ESRI quyết định rằng điều quan trọng là mở rộng chức năng của nó sang FGDB.

Hồi sinh chủ đề / vấn đề này, tôi thấy nó có thể hữu ích để kết hợp, khi có thể, FGDB và PGDB. Chẳng hạn, tạo một cơ sở dữ liệu địa lý đầu tiên một PGDB giúp thực hiện rất nhiều các truy vấn. Kích thước của PGDB không nên tăng quá nhiều, như đã đề cập ở trên.