Управление ArcSDE?

Потратив немного времени на поиск лучших рекомендаций по управлению ArcSDE, я пришел с пустыми руками. Я хорошо разбираюсь в пространственных базах данных и их управлении, внедрив несколько крупномасштабных баз данных Oracle Spatial, но хотел бы поделиться своими мыслями о методах или шаблонах, которых следует придерживаться, чтобы сделать их жизнь проще, а их пространственные возможности удобными и безопасными.

Какие методы вы используете в своей базе данных ArcSDE для обеспечения целостности, безопасности и согласованности вашего экземпляра ArSDE?

Какие цели дизайна вы ставите перед собой при планировании своего экземпляра ArcSDE и почему?

Это широкие вопросы, и ответ может значительно измениться в зависимости от размера, требований и объема реализации, но я хотел бы оценить интерес к руководству для сообщества по этой теме.

Это на самом деле то, что вы найдете мало документации публично. Существуют классы / семинары, за которые ESRI взимает плату или которые вы можете посещать в ESRIUC, но меньше в общественных местах.

Несколько упомянутых вами моментов проистекают из хороших практик DBA; но некоторые действительно не зависят от ваших систем и потребностей.

Для целостности, безусловно, ключевой является стабильная аппаратная платформа (я всегда использую кластерные системы); и используя правильный бэкэнд БД. Я из сильного штата и федерального происхождения, поэтому я обычно использую большие железные базы данных, такие как MSSQL или Oracle. Пространственный MSSQL2008 дает хороший набор инструментов по цене; по сравнению с тем, если вы действительно хотите пуленепробиваемого доступа со стороны, вы хотите рассмотреть Oracle; где множество приложений подключаются к пространственной стороне.

Безопасность; там у вас есть сильный администратор базы данных, который должен убедиться, что ваши учетные записи настроены правильно; но тогда вам также необходимо использовать встроенные элементы управления ESRI для того, кто может читать / записывать и т. д. из ваших БД. Это также ставит под вопрос структуру ваших данных и ваших систем, использующих их; нужно ли вам создавать бункеры с более высоким уровнем безопасности, где у вас более строгий уровень безопасности пользователей; или это просто огромная отдельная БД, в которой вы поддерживаете пользователя с правами на уровне пользователя для всех функций.

Вы также должны подумать о том, чтобы использовать внутренние объекты, такие как домены, и справочные таблицы с этими значениями, которые вам подходят; домены могут быть недоступны из сторонних приложений, просматривающих ваши данные; где справочная таблица может быть объединена, и у вас есть эти закодированные значения.

Нормализация данных является большой темой для рассмотрения; некоторые люди довольны созданием твердого нормализованного дизайна с функциями SDE только с геометрией, а затем со всеми табличными элементами в бизнес-таблицах, которые затем содержат множество индексов и представлений для повышения производительности при поиске другими приложениями.

Так что если у вас есть конкретные области, которые вам интересны; не стесняйтесь добавлять больше деталей к своим вопросам, но многое из того, что вы ищете, действительно зависит от вашей платформы и ваших функциональных потребностей. Высокоскоростное веб-приложение может не хотеть SDE, а не только fGDB; по сравнению с динамическими данными потребуется SDE.

Я думаю, что DeWright в значительной степени ударил гвоздь по голове. Чем сложнее стратегия безопасности, которую вы хотите, тем сложнее вы захотите свои rdbms.

У меня всегда было желание создавать базы данных с несколькими типами доступа. Такие как sdo, postgis. Позволяет нескольким программам или IDE манипулировать или отображать данные.

Я бы посоветовал отправиться на большую дорогу и потратить дополнительное время на исследования / тестовые сценарии, прежде чем начинать. Некоторые из этих параметров звучат великолепно, но имеют ограничения.

Оптимизация, нормализация и продуманный дизайн базы данных обеспечат гибкость (пространственно) в долгосрочной перспективе.