Importar datos XML enormes (> 1 Gb) en SQL Server 2008 diariamente

Question

He encontrado un problema que necesito importar un enorme XML (> 1 Gb) en SQL Server 2008 diariamente. Lo que tengo ahora es un archivo XML de muestra y el esquema XML del mismo. El esquema XML es bastante complejo que contiene muchas personalizado definido tipo simple, y el elemento de tipo complejo, tales como:

<xs:element name="xxxx_url"> 
     <xs:complexType> 
      <xs:simpleContent> 
       <xs:extension base="xs:anyURI"> 
        <xs:attribute ref="target" use="optional"/> 
        <xs:attribute ref="abc" use="optional"/> 
       </xs:extension> 
      </xs:simpleContent> 
     </xs:complexType> 
</xs:element> 

Después de la importación, un servicio WCF se llevará a cabo para recuperar los datos almacenados en SQL Sever, algo así como la búsqueda , recuperar etc. (operaciones de solo lectura).

Los pasos de implementación que se me ocurren son como:

1. Definir un modelo de objetos de acuerdo con el XSD proporcionado (manualmente), el modelo de objetos se utiliza para el servicio WCF para devolver valores.
2. Defina un esquema de base de datos del XSD proporcionado (manualmente), se estima que el esquema tiene aproximadamente de 20 a 30 tablas.
3. Crea un paquete SSIS para cargar XML en la base de datos diariamente.
4. Crea un servicio WCF que lee de la base de datos, rellena datos en el modelo de objetos definido en el paso 1 y devuelve el objeto al cliente de servicio.

El problema es que estos pasos implican mucho trabajo manual. Tengo que investigar el XSD fila por fila, y transformarlo en modelo de objeto y esquema de la base de datos mannualy.

Investigué que hay algunas herramientas de automatización para transformar XSD en clases, y también transformar XSD en el esquema de la base de datos. Pero las clases transformadas de XSD con la herramienta están bastante desordenadas, y la transformación a esquema falla porque no se ajusta al formato de conjunto de datos de MS.

Me pregunto si hay alguna buena solución a este problema, para ahorrar un montón de trabajo manual?

¡Cualquier sugerencia es apreciada!

Answer 1

En algún momento tienes que hacer la transformación. Ya sea que lo haga leyendo el XML en objetos o en datos en tablas. El trabajo debe hacerse una vez y luego solo tiene que ejecutar el proceso resultante. Los problemas que veo son:

• El XML es muy grande.

• Aún no tiene una asignación del XSD al esquema deseado.

La asignación es un trabajo que vas a tener que hacer. Creo que funcionaría mejor si puede importar el XSD en la tabla y luego importar desde esa tabla temporal al esquema que desea usar. Trabajar con el archivo XML le dará problemas debido a su tamaño.

Así que mi sugerencia es forzar/fudge la importación del XML en cualquier estructura de tabla que funcione. Luego, escriba un procedimiento almacenado para "importar" los datos de esas tablas en su esquema "real".

Pat O

Answer 2

tratar spliting el xml que más de un archivo debido a problemas en el futuro, donde la materia como ýÿơƝƈï pueden aparecer en la base de datos debido a subir errores

Answer 3

En resumen, nuestra solución requerirá algo de trabajo - no hay una solución rápida.

Para la escalabilidad, recomendaría una tecnología que le permita transmitir a través del XML (a-la SAX) en lugar de intentar cargar y transfigurar todo en RAM. Para los propósitos de SSIS, no hay una gran cantidad de valor para convertir el XML en un objeto-gráfico, así que considere cualquiera de las siguientes oportunidades:

1. corriente y shread el documento XML utilizando un script personalizado con múltiples salidas , luego use otros componentes de SSIS para transformar los datos resultantes.
2. Carga masiva (secuencia) del XML en una instancia provisional del servidor SQL, luego consulte el XML desde allí (no es una gran solución, pero es más fácil que 1.) o
3. Semi-shread el documento en trozos más pequeños, A granel cargar esos trozos en un área de ensayo, luego trabajar en ellos por separado utilizando transformadas XSD, etc. Esto abre las puertas a un mejor paralelismo.

Answer 4

¿Tiene datos de ejemplo que puede publicar con al menos un registro completo de datos?

Además, ¿tiene acceso a la base de datos de origen utilizada para crear esta información XML? XML no está realmente diseñado para este tamaño de transferencia de datos: su tarea sería mucho más fácil con los datos en formatos de archivo planos para cada tabla.

Answer 5

SQL Server ha incorporado tipos XML - puede create tables from your schema.

¿Lo ayudarían aquí?