Quản lý ArcSDE?

Sau khi dành một ít thời gian để làm việc với các thực tiễn tốt nhất về quản lý ArcSDE, tôi đã ra về tay không. Tôi hiểu rõ về Cơ sở dữ liệu Không gian và ban quản lý của họ đã triển khai một số cơ sở dữ liệu Không gian Oracle quy mô lớn, nhưng muốn suy nghĩ của bạn về các thực tiễn hoặc mô hình nên tuân thủ để làm cho cuộc sống của họ dễ dàng hơn và việc giữ không gian của họ có thể sử dụng và bảo mật.

Những thực hành nào bạn sử dụng trên cơ sở dữ liệu ArcSDE của mình để đảm bảo tính toàn vẹn, bảo mật và tính nhất quán của Trường hợp ArSDE của bạn?

Mục tiêu thiết kế nào bạn nhắm đến khi lập kế hoạch cho ArcSDE của bạn và tại sao?

Chúng là những câu hỏi rộng và câu trả lời có thể thay đổi đáng kể theo quy mô, yêu cầu và phạm vi triển khai, nhưng tôi muốn đánh giá sự quan tâm trong hướng dẫn dựa trên cộng đồng cho chủ đề này.

Đó thực sự là một cái gì đó bạn sẽ tìm thấy tài liệu nhỏ trên công khai. Có các lớp / hội thảo mà ESRI tính phí hoặc bạn có thể tham dự tại ESRIUC nhưng ít hơn trong không gian công cộng.

Một vài điểm bạn đề cập đến từ các hoạt động DBA tốt; nhưng một số thực sự không và thực sự phụ thuộc vào sytems và nhu cầu của bạn.

Đối với tính toàn vẹn, chắc chắn một nền tảng phần cứng ổn định (tôi luôn đi theo hệ thống cụm) là chìa khóa; và sử dụng phụ trợ DB đúng. Tôi đến từ một tiểu bang mạnh và liên bang nên tôi thường gắn bó với các DB lớn như MSSQL hoặc Oracle. Không gian MSSQL2008 cung cấp cho bạn một bộ công cụ tốt cho chi phí; so với nếu bạn thực sự muốn chống đạn với quyền truy cập của bên thứ 3, bạn muốn xem xét Oracle; nơi có rất nhiều ứng dụng kết nối với phía không gian.

Bảo vệ; ở đó bạn có một DBA mạnh mẽ để đảm bảo rằng bạn có các tài khoản được cấu hình đúng; nhưng sau đó bạn cũng có nhu cầu sử dụng các điều khiển ESRI tích hợp cho những người có thể đọc / ghi, v.v. từ DB của bạn. Điều này cũng đặt ra câu hỏi về cấu trúc dữ liệu của bạn và các hệ thống của bạn sử dụng nó; bạn có cần tạo các silo bảo mật cao hơn không, nơi bạn có bảo mật cấp độ người dùng chặt chẽ hơn; hoặc chỉ là một DB lớn duy nhất ok với bạn duy trì người dùng theo quyền của người dùng trên các tính năng.

Điều bạn cũng muốn nghĩ đến là sử dụng các đối tượng bên trong như tên miền so với bảng tham chiếu với những giá trị tốt cho bạn; tên miền có thể không truy cập được từ các ứng dụng của bên thứ 3 đang xem dữ liệu của bạn; trong đó một bảng tham chiếu có thể được nối và bạn có các giá trị được mã hóa đó.

Chuẩn hóa dữ liệu là một chủ đề lớn cần xem xét; một số người hài lòng với thiết kế chuẩn hóa vững chắc chỉ có các tính năng SDE hình học và sau đó tất cả các công cụ dạng bảng trong bảng doanh nghiệp mà sau đó bạn có rất nhiều chỉ mục và chế độ xem để tối ưu hóa hiệu suất để tìm kiếm bởi các ứng dụng khác.

Vì vậy, nếu bạn có các khu vực cụ thể mà bạn tò mò về; vui lòng thêm chi tiết vào câu hỏi của bạn nhưng phần lớn những gì bạn muốn thực sự phụ thuộc vào nền tảng và nhu cầu chức năng của bạn. Một ứng dụng web tốc độ cao có thể không muốn SDE thay vì chỉ fGDB; so với dữ liệu động sẽ yêu cầu SDE.

Tôi nghĩ DeWright khá nhiều đánh vào đầu đinh. Chiến lược bảo mật mà bạn muốn càng phức tạp thì bạn càng muốn rdbms của mình.

Tôi luôn có mong muốn xây dựng cơ sở dữ liệu với nhiều loại truy cập. Chẳng hạn như sdo, postgis. Cho phép nhiều hơn một phần mềm hoặc IDE để thao tác hoặc hiển thị dữ liệu.

Tôi sẽ đề nghị đi đường cao tốc và dành thêm thời gian cho các kịch bản nghiên cứu / thử nghiệm trước khi cam kết. Một số tùy chọn này nghe có vẻ tuyệt vời nhưng có những hạn chế.

Tối ưu hóa, chuẩn hóa và thiết kế db vững chắc trước khi sử dụng sẽ cho phép nhiều tính linh hoạt (không gian) trong thời gian dài.