Керування ArcSDE?

Витративши трохи часу на Googling для передового досвіду управління ArcSDE, я підійшов з порожніми руками. Я добре розумію просторові бази даних та їх управління, впровадивши кілька масштабних просторових баз даних Oracle, але хотів отримати свої думки щодо практик чи зразків, яких слід дотримуватися, щоб полегшити їхнє життя, а їхні просторові сховища зручні та безпечні.

Які практики ви використовуєте у своїй базі даних ArcSDE, щоб забезпечити цілісність, безпеку та послідовність свого екземпляра ArSDE?

До яких цілей дизайну ви прагнете, плануючи свій примірник ArcSDE і чому?

Вони є широкими питаннями, і відповідь може суттєво змінитися в залежності від розміру, вимог та обсягу реалізації, але я хотів би оцінити інтерес до посібника, заснованого в громаді, до цієї теми.

Це фактично те, про що ви мало знайдете публічну документацію. Існують заняття / семінари, за які платить ESRI або які ви можете відвідувати в ESRIUC, але менше в публічному просторі.

Кілька пунктів, які ви згадуєте, випливають з хороших практик DBA; але деякі справді не знають і справді залежать від ваших систем та потреб.

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

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

Те, про що ви також хочете подумати, - це використовувати внутрішні об'єкти, такі як домени, порівняно з довідковими таблицями, з тими значеннями, які підходять вам; домени можуть бути недоступні в сторонніх програмах, які переглядають ваші дані; де можна приєднати довідкову таблицю, і у вас є ці закодовані значення.

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

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

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

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

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

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