Создайте собственный драйвер для System.Data.Common - PullRequest
3 голосов
/ 07 октября 2009

Справочная информация:

Наше приложение C # генерирует и выполняет запросы к нескольким типам баз данных (Oracle, SQL Server, MySQL), но возникло требование также применить их к проприетарному формату файлов.

  1. Пространство имен, используемое до сих пор, - System.Data.Common.
  2. Запросы, которые нам нужно применить, являются нетривиальными (вложенные SELECT, псевдонимы FROM, методы подстрок и конкатенации строк)

Изначально мы преобразовали содержимое проприетарного файла в CSV, для которого существует драйвер {Microsoft Text Driver (* .txt; * .csv)} . Однако клиент требует, чтобы временные файлы не создавались, и все должно происходить в памяти.

Создание драйвера ODBC для непосредственного запроса файла кажется слишком трудоемким. Итак, мы рассматриваем создание драйвера (возможно, ODBC), в который мы будем «встраивать» драйвер ODBC для SQLITE. Внутри этого драйвера мы можем загрузить содержимое файлов CSV в базу данных «в памяти», а затем направить запрос во внутренний драйвер ODBC.

Мои вопросы:

  1. Это решение кажется возможным?
  2. С чего начать, чтобы создать драйвер ODBC с нуля?

Спасибо

Ответы [ 4 ]

2 голосов
/ 07 октября 2009

Запрос клиента нечетный. Всегда будут задействованы файлы, вы читаете из файла.

Если они хотят, чтобы их вещи были в памяти (опять же странный клиент), поместите файлы CSV на диск RAM: http://members.fortunecity.com/ramdisk/RAMDisk/ramdriv001.htm

Сборка и привод ODBC - непростое мероприятие, если вы заботитесь о производительности и стабильности.

1 голос
/ 07 октября 2009

Если возможно использование SQLite в качестве бэкэнда, я не могу понять, почему вы не можете использовать поставщика ADO .NET для своей базы данных SQLite, например System.Data.SQLite .


Из вашего комментария я думаю, что вы используете поставщика ODBC ADO .NET для всех соединений с базой данных (System.Data.Odbc). Если вам нужно придерживаться той же схемы, то вам стоит использовать собственный ODBC-провайдер (но тогда это простая разработка на C, и я считаю, что это довольно болезненно).

Другим способом было бы добавить третий параметр в вашу БД (первые два - SQL и строка подключения): использовать ADO .NET-провайдера (например, предполагается сделать в файлы конфигурации , см. атрибут providerName). Таким образом, вы можете использовать любого доступного поставщика ADO .NET.

Затем вы можете заключить поставщика SQLite в своего собственного, настраиваемого поставщика ADO .NET, который может включать создание и заполнение базы данных SQLite. Преимущество этого решения: чистый управляемый .NET.

1 голос
/ 07 октября 2009

Я думаю, что ваше решение отнимает много времени. Вы можете найти существующие решения для того, что вы пытаетесь сделать. Вот несколько альтернатив.

Почему бы не попробовать Linq to text / csv file?

Оба решения находятся в памяти.

Другая идея заключается в том, что вы можете экспортировать файл в xml вместо csv или text (я всегда предпочитаю экспортировать в xml, когда мне приходится обрабатывать код). Чем вы используете System.Xml или Linq to Xml для выполнения операций.

0 голосов
/ 07 октября 2009

Если вы не имеете права создавать временные файлы, вы можете попробовать использовать режим SQLite в памяти. Вот пример строки подключения для него ( source ):

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

На мой взгляд, это проще, чем создание полноценного провайдера. $

...