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

Question

Arrière-plan:

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'à maintenant est System.Data.Common.
2. Les requêtes dont nous avons besoin d'appliquer ne sont pas négligeables (SELECTs imbriquées, alias à partir, méthodes et substring concaténations string)

Nous avons converti d'abord le contenu du fichier propriétaire au format CSV, pour lequel il existe le pilote {Microsoft Text Driver (* .txt; * .csv)} . Toutefois, le client nécessaire qu'aucun fichier temporaire sont générés, et tout devrait se produire en mémoire.

Création d'un pilote ODBC pour interroger le fichier semble directement trop de temps exigeant. Donc, nous envisageons la création d'un pilote (éventuellement ODBC), dans lequel nous « intégrer » le pilote ODBC SQLite. 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 intérieur.

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 vois vraiment pas pourquoi vous ne pouvez utiliser un fournisseur .NET ADO à votre base de données SQLite comme System.Data.SQLite .

---

De votre commentaire, je pense que vous êtes en fait à 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, puis un fournisseur ODBC personnalisé est le chemin à parcourir (mais il est C le développement natif plaine, et assez pénible, je crois).

Une autre façon d'aller serait d'ajouter un troisième paramètre à votre DB (les deux premiers étant le SQL et la chaîne de connexion): le fournisseur .NET ADO à utiliser (comme il est censé faire dans les fichiers de configuration , voir l'attribut providerName). De cette façon, vous pouvez utiliser un fournisseur .NET ADO disponible.

Ensuite, vous pouvez envelopper le fournisseur de SQLite dans vos propres, coutume, fournisseur ADO .NET, qui pourrait inclure la génération et la population de la SQLite DB. Avantage de cette solution:. NET pur géré

Answer 2

La demande du client est impair. Il y aura toujours des fichiers impliqués, vous lisez à partir 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

Building et le lecteur ODBC est une entreprise non trival si vous vous souciez de la performance et la stabilité.

Answer 3

Je pense que votre solution est temps. Vous pouvez trouver des solutions existantes pour ce que vous essayez de faire. Voici quelques remplaçants.

Pourquoi ne pas essayer LINQ to text / 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 le fichier au format XML au lieu de csv ou texte (je préfère toujours exporter en xml quand je dois traiter dans mon code). Que vous utilisez System.XML ou à Xml LINQ pour effectuer des opérations.

Answer 4

Si vous ne sont pas limités créer des 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;

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