Después de pasar un poco de tiempo buscando en Google las mejores prácticas de gestión de ArcSDE, llegué con las manos vacías. Tengo una buena comprensión de las bases de datos espaciales y su gestión al haber implementado varias bases de datos espaciales de Oracle a gran escala, pero quería tener su opinión sobre las prácticas o los patrones que uno debe cumplir para facilitarles la vida y sus propiedades espaciales utilizables y seguras.
¿Qué prácticas emplea en su base de datos ArcSDE para garantizar la integridad, seguridad y consistencia de su instancia de ArSDE?
¿Qué objetivos de diseño aspira al planificar su instancia de ArcSDE y por qué?
Son preguntas amplias, y la respuesta puede cambiar significativamente con el tamaño, los requisitos y el alcance de la implementación, pero me gustaría medir el interés en una guía basada en la comunidad para este tema.
Eso es realmente algo en lo que encontrará poca documentación públicamente. Hay clases / talleres por los que ESRI cobra o que puedes asistir en el ESRIUC pero menos en el espacio público.
Algunos de los puntos que menciona provienen de buenas prácticas de DBA; pero algunos realmente no dependen de sus sistemas y necesidades.
Por integridad, seguro que una plataforma de hardware estable (siempre uso sistemas agrupados) es clave; y usando el backend DB correcto. Soy de una sólida formación estatal y federal, por lo que generalmente me adhiero a bases de datos grandes como MSSQL u Oracle. MSSQL2008 espacial le brinda un buen juego de herramientas para el costo; frente a si realmente desea a prueba de balas con acceso de terceros que desea considerar Oracle; donde muchas aplicaciones se conectan al lado espacial.
Seguridad; bueno, allí tiene una fuerte necesidad de DBA para asegurarse de tener las cuentas configuradas correctamente; pero también tiene la necesidad de usar los controles ESRI integrados para saber quién puede leer / escribir, etc. desde sus bases de datos. Esto también pone en tela de juicio la estructura de sus datos y los sistemas que los utilizan; ¿Necesita crear silos de mayor seguridad donde tenga una seguridad de nivel de usuario más estricta? o es simplemente una gran base de datos única que está bien si mantiene al usuario por permisos de nivel de usuario en todas las funciones.
También debe pensar en usar objetos internos como dominios versus tablas de referencia con esos valores adecuados para usted; es posible que no se pueda acceder a los dominios desde aplicaciones de terceros que miren sus datos; donde se puede unir una tabla de referencia y tener esos valores codificados.
La normalización de datos es un gran tema a considerar; algunas personas están contentas de hacer un diseño normalizado sólido con características SDE de geometría solamente y luego todas las cosas tabulares en las tablas de negocios que luego tienen muchos índices y vistas para optimizar el rendimiento para buscar en otras aplicaciones.
Entonces, si tiene áreas particulares que le interesan; siéntase libre de agregar más detalles a sus preguntas, pero gran parte de lo que busca realmente depende de su plataforma y sus necesidades funcionales. Una aplicación web de alta velocidad puede no querer SDE en lugar de solo fGDB; versus datos dinámicos demandarían SDE.
Sabía que hacer esta pregunta obtendría respuestas amplias, como es la naturaleza de la pregunta. Muchas gracias por su respuesta. Tengo mi propia lista de mejores prácticas que he desarrollado a lo largo de los años en función del desarrollo y la administración de la base de datos, aunque creo que sería beneficioso para la comunidad en un esfuerzo de colaboración para compilar una lista basada en los temas que ha esbozado. ¿Estarías de acuerdo?
OptimizePrime
Sí, eso creo. Quizás la sección Wiki podría servir como punto de partida; incluso considere mirar desde Spatial DB's en masa; no solo la ruta ESRI / ArcSDE. Hay algunas cosas diferentes que puede ver por consideraciones de diseño en un Oracle / Spatial versus lo que estoy haciendo en mi sistema MSSQL2008; donde tengo la capa MS-Spatial recién envuelta por ESRI para algún acceso a la aplicación; todo lo demás, como Safe / FME, se comunica directamente con MSSQL. Esa es una consideración de diseño deliberada para reducir la dependencia de la capa ESRI.
DEWright
1
Creo que DeWright dio en el clavo. Cuanto más compleja sea la estrategia de seguridad que desee, más sofisticados serán sus rdbms.
Siempre tuve el deseo de construir bases de datos con múltiples tipos de acceso. Como sdo, postgis. Permitir que más de un software o IDE manipule o muestre los datos.
Sugeriría tomar el camino y pasar más tiempo en escenarios de investigación / prueba antes de comprometerse. Algunas de estas opciones suenan muy bien pero tienen limitaciones.
La optimización, la normalización y el diseño sólido de db de antemano permitirán mucha flexibilidad (espacialmente) a largo plazo.
Creo firmemente en un buen plan;) Pero continuamente encuentro empresas que quieren implementar inteligencia de ubicación y fruncir el ceño ante una estrategia escrita bien definida para hacerlo. Para mí, el punto óptimo es "dar al uso lo que necesitan / desean al tiempo que garantiza que las funciones de gestión de datos se mantengan lo más elegantes / funcionales posible". Estos son los dos objetivos que siempre tengo en cuenta.
OptimizePrime
podrías pasar mucho tiempo en el archivo dbtune.
Brad Nesom el
La mayor parte es tu diseño; si necesita construir datos que se utilizarán en herramientas espaciales y no espaciales, realmente desea normalizar sus datos; separando lo espacial de lo tabular. Solo para mantener sus mesas más limpias y reducir la cantidad de cosas que almacena en ese espacio.
Creo que DeWright dio en el clavo. Cuanto más compleja sea la estrategia de seguridad que desee, más sofisticados serán sus rdbms.
Siempre tuve el deseo de construir bases de datos con múltiples tipos de acceso. Como sdo, postgis. Permitir que más de un software o IDE manipule o muestre los datos.
Sugeriría tomar el camino y pasar más tiempo en escenarios de investigación / prueba antes de comprometerse. Algunas de estas opciones suenan muy bien pero tienen limitaciones.
La optimización, la normalización y el diseño sólido de db de antemano permitirán mucha flexibilidad (espacialmente) a largo plazo.
fuente