Crear controlador personalizado para System.Data.Common

StackOverflow https://stackoverflow.com/questions/1531007

Pregunta

Antecedentes:

Nuestra C # aplicación genera y ejecuta las consultas a varios tipos de bases de datos (Oracle, SQL Server, MySQL), sino un requisito acercó a aplicarse también a un formato de archivo propietario.

  1. El espacio de nombres utilizado hasta ahora es System.Data.Common.
  2. Las consultas tenemos que aplicar no son triviales (selecciona anidados, alias de FROM, subcadena métodos y concatenaciones de cadenas)

Inicialmente se convirtieron los contenidos del archivo propietario a CSV, para la cual existe el controlador {conductor del texto de Microsoft (* .txt, * .csv)} . Sin embargo, el cliente requiere que no se generan archivos temporales, y todo lo que debería ocurrir en memoria.

Creación de un controlador ODBC para consultar el archivo parece directamente demasiado tiempo exigente. Por lo tanto, estamos considerando la creación de un conductor (posiblemente ODBC), en el que vamos a "encajar" el conductor SQLITE ODBC. Dentro de ese conductor, podemos cargar el contenido de los archivos CSV en la base de datos "en memoria", y luego enviar la consulta al controlador ODBC interior.

Mis preguntas:

  1. ¿Esta solución parece factible?
  2. ¿Por dónde empezar con el fin de crear un controlador ODBC desde cero?

Gracias

¿Fue útil?

Solución

Si se utiliza SQLite como backend es una posibilidad, no puedo ver por qué no se podía utilizar un proveedor de ADO .NET para su base de datos SQLite como System.Data.SQLite .

A partir de su comentario, creo que en efecto está utilizando el proveedor de ODBC de ADO .NET para todas las conexiones de base de datos (System.Data.Odbc). Si usted necesita para mantener el mismo esquema, a continuación, un proveedor ODBC personalizado es el camino a seguir (pero entonces es normal desarrollo nativo C, y más bien dolorosa creo).

Otro camino a seguir sería añadir un tercer parámetro a su base de datos (los dos primeros son el SQL y la cadena de conexión): el proveedor de ADO .NET para utilizar (como es supone que debe hacerse en archivos de configuración , consulte el atributo providerName). De esta manera se podría utilizar cualquier proveedor de ADO .NET disponible.

A continuación, puede envolver el proveedor de la SQLite en su propio, personalizado, proveedor de ADO .NET, que podría incluir la generación y la población de la base de datos SQLite. Ventaja de esta solución:. NET administrado pura

Otros consejos

La solicitud de cliente es impar. Siempre habrá archivos involucrados, que está leyendo desde un archivo.

Si quieren sus cosas en la memoria (de nuevo un cliente raro) poner las CSV a un disco RAM: http://members.fortunecity.com/ramdisk/RAMDisk/ramdriv001.htm

Construcción y unidad de ODBC es una tarea no trivial si se preocupan por el rendimiento y la estabilidad.

Creo que la solución es mucho tiempo. Puede encontrar las soluciones existentes para lo que está tratando de hacer. Aquí están algunos suplentes.

¿Por qué no tratar de LINQ to de texto Archivo / csv?

Ambas soluciones están en la memoria.

Otra idea es que, puede exportar el archivo XML en lugar de CSV o de texto (siempre prefiero la exportación a XML cuando tengo que procesar en mi código). De las que usa System.XML o LINQ to XML para realizar las operaciones.

Si sólo está limitado para no crear archivos temporales, puede intentar utilizar el modo en memoria de SQLite. He aquí una muestra de la cadena de conexión para que ( fuente ): 

Data Source=:memory:;Version=3;New=True;

A mi entender, esto es más simple que la construcción de proveedor en toda regla. $

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top