Créer pilote personnalisé pour System.Data.Common

Question

Contexte:

Notre application C# génère et exécute des requêtes à plusieurs types de bases de données (Oracle, SQL Server, MySQL), mais une exigence est venu de les appliquer aussi à un format de fichier propriétaire.

1. L'espace de noms utilisé jusqu'à présent est System.Data.Common.
2. Les requêtes dont nous avons besoin d'appliquer ne sont pas négligeables (SELECTs imbriquées, alias dans FROM, substring méthodes et concaténations de chaînes)

Nous avons converti d'abord le contenu du fichier propriétaire au format CSV, pour lesquelles il existe la Pilote {Microsoft Text Driver (* .txt; * .csv)}. Cependant, le client exigeait qu'aucun fichier temporaire ne soit généré et tout devait se passer en mémoire.

La création d'un pilote ODBC pour interroger directement le fichier semble trop longue. Nous envisageons donc de créer un pilote (éventuellement ODBC), dans lequel nous allons "incorporer" le pilote SQLITE ODBC. À l'intérieur de ce pilote, nous pouvons charger le contenu des fichiers CSV dans la base de données "en mémoire", puis transmettre la requête au pilote ODBC interne.

Mes questions:

1. Est-ce que cette solution semble possible?
2. Où devrions-nous commencer afin de créer un pilote ODBC à partir de zéro?

Merci

Answer 1

Si vous utilisez SQLite comme backend est une possibilité, je ne peux pas. vraiment voir pourquoi vous ne pouviez pas utiliser un fournisseur ADO .NET à votre base de données SQLite comme System.Data.SQLite.

---

De votre commentaire, je pense que vous êtes en effet à l'aide du fournisseur .NET ODBC ADO pour toutes les connexions de base de données (System.Data.Odbc).Si vous avez besoin de garder le même schéma, alors un fournisseur ODBC personnalisé est le chemin à parcourir (mais alors c'est un développement natif en langage C, et plutôt douloureux je crois). Une autre façon d'aller serait d'ajouter un troisième paramètre à votre base de données (les deux premiers étant le SQL et la chaîne de connexion): le fournisseur ADO .NET à utiliser (comme supposed to be done in configuration files, voir l'attribut providerName) . De cette façon, vous pouvez utiliser n'importe quel fournisseur ADO .NET disponible.

Ensuite, vous pourriez intégrer le fournisseur SQLite dans votre propre fournisseur ADO .NET personnalisé, ce qui pourrait inclure la génération et la population de la base de données SQLite. Avantage de cette solution: pure .NET géré.

Answer 2

Je pense que votre solution est temps. Vous pouvez trouver des solutions existantes pour ce que vous essayez de faire. Voici quelques alternatives. Pourquoi ne pas essayer Linq en fichier texte/csv?

• http://www.codeproject.com/KB/linq/LINQtoCSV.aspx
• http://blogs.msdn.com/ericwhite/archive/2008/09/30/linq-to-text-and-linq-to-csv.aspx

Les deux solutions sont en mémoire. Une autre idée est que vous pouvez exporter un fichier en XML au lieu de csv ou de texte (je préfère toujours exporter en XML quand je dois traiter dans mon code). Que vous utilisez System.Xml ou Linq to Xml pour effectuer des opérations.

Answer 3

Si vous êtes uniquement limité à la création de fichiers temporaires, vous pouvez essayer d'utiliser le mode en mémoire de SQLite. Voici un exemple de chaîne de connexion pour elle (source):

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

À mon avis, cela est plus simple que la construction de fournisseur à part entière

$

Answer 4

La demande du client est étrange. Il y aura toujours des fichiers impliqués, vous lisez d'un fichier.

S'ils veulent leurs trucs en mémoire (encore une fois un client bizarre) mettre les CSVs sur un disque RAM: http://members.fortunecity.com/ramdisk/RAMDisk/ramdriv001.htm

disque de construction et ODBC est une entreprise non trival si vous vous souciez de la performance et la stabilité.