Плюсы и минусы механизма базы данных Access. Жизнь после SQLite

Question

Я спросил question некоторое время назад о том, какая локальная БД была подходящей для моей ситуации. Мне нужно было получить доступ к БД из кода .NET и VB6. Подавляющим ответом был SQLite. Тем не менее, я решил перейти на SQLite, потому что единственный поставщик OLE DB для него взимает роялти за каждую развернутую копию моего программного обеспечения. Он также требует, чтобы процедура активации запускалась на каждом отдельном ПК.

После оценки других параметров (выпуск SQL Server Compact - едва функциональный поставщик OLE DB, Firebird - не нужно платить за другой драйвер и т. Д.), Я пришел к выводу, что единственная жизнеспособная выбор использует .MDB-файлы, созданные Microsoft Access (или движок Jet).

Я не использовал его с конца 90-х годов, поэтому у меня есть следующие вопросы для тех, у кого есть опыт работы с ним.

1. Решили ли они проблему, когда база данных будет коррумпироваться время от времени.
2. Доступ к MDB из C# осуществляется через ADO.NET OLEDB Provider или есть собственное решение (я не могу найти его).
3. Есть ли жизнеспособная альтернатива действительно дерьмовому редактору SQL в Access?

Спасибо.

Answer 1

Скорее тогда происходит "назад" в Access, я бы придерживаться SQLite и использовать поставщик System.Data.SQLite для SQLite доступ к данным в коде .NET.

Тогда я бы просто создал простой COM-интерфейс .NET для использования VB6, который обертывает любые необходимые функции доступа к данным SQLite. Наконец, просто ссылайтесь и используйте его как стандартный COM-объект из ваших проектов VB6.

Мои знания о доступе, вероятно, немного устарели и предвзяты от плохих впечатлений, но в разумных пределах я попробую большинство других вариантов, прежде чем прибегать к маршруту доступа.

Answer 2

Вы считаете SQL Server 2008 Express Edition (как против SQL Server CE)?

1) Лично я обнаружил, что в большинстве случаев, когда Access DBs повреждались, это происходило из-за кода, который не очищался после него сам, или была задействована неисправная сетевая карта.

2)

string connectionString = @“Provider = Microsoft.Jet.OLEDB.4.0; " + 
          @"Data Source = C:\data\northwind.mdb; " + 
          @"User Id = guest; Password = abc123” 


using (OleDbConnection oleDbConnection = New OleDbConnection()) 
{ 
    oleDbConnection.ConnectionString = connectionString; 

    oleDbConnection.Open(); 

    ... 
} 

3) SQL Server 2008 Express Edition

Answer 3

Вы также можете попробовать SQL Anywhere, он работает на различных ОС и имеет небольшую площадь. Работает для меня :)

Answer 4

Поскольку формат MDB более или менее устарел, знания конца 90-х годов довольно актуальны. See this MSDN page

Answer 5

Повреждение MDB в основном связано с сбоями, возникающими в клиентских машинах, файловых серверах и сетях, когда база данных открыта. Если вы помещаете MDB в общий ресурс файла, это всегда является риском, если на локальном жестком диске и используется одним пользователем, проблемы намного реже.

Я бы не ожидал, что SQLite будет другим, и если что-нибудь еще хуже.

Периодически эксплуатирующийся JetComp.exe (загрузка Microsoft) устранит множество проблем и компактных индексных таблиц и тому подобное. Резервные копии важны независимо от того, что вы используете.

Вам не нужен MS Access для использования Jet MDB. Существуют некоторые сторонние инструменты для разработки схемы базы данных и выполнения интерактивных запросов, как командной строки, так и графического интерфейса.

Answer 6

AngryHacker спросил:

Q1. Решили ли они проблему, когда база данных будет коррумпироваться время от времени.

Er, что?

В правильно спроектированных приложениях, должным образом развернутых в надлежащим образом поддерживаемых средах, никогда не было проблем с коррупцией. Я не видел поврежденного MDB через 3 или 4 года, и у меня есть десятки моих приложений в режиме полного рабочего времени многими клиентами во многих различных типах операционных сред.

Я думаю, что большинство людей, которые испытывают коррупцию, - это те, кто пытается поделиться файлом MDB среди многих пользователей (будь то раскол или нерасщепленный). Поскольку вы не рассматриваете использование Access, это не проблема.

Q2. Является ли доступ к MDB из C#, выполненным через поставщика OLEDB ADO.NET, или есть собственное решение (я не могу найти его).

Нашим решением будет DAO, но это COM, поэтому вы, возможно, не захотите его использовать. С C# я бы сказал, что OLEDB - ваш лучший выбор, но это не моя область знаний, поэтому возьмите с собой соль. Я считаю, что Майкл Каплан сообщил, что поставщик Jet ADO/OLEDB был потокобезопасным, а DAO - нет. Это не означает, что он рекомендовал ADO/OLEDB над DAO, но его комментарии также пришли в контексте Access, а не в C#.

Q3. Есть ли жизнеспособная альтернатива действительно дрянной SQL Editor в Access?

Зачем использовать это, если вы фактически не используете Access? Вы можете использовать любой редактор SQL, который вам нравится, пока вы проверяете, что SQL, который вы пишете, совместим с диалектом SQL SQL.

Я, например, не вижу, что проблема с редактором SQL Access (кроме неспособности установить размер шрифта), но затем я пишу много моего SQL с помощью QBE и не даже взглянуть на представление SQL.

Answer 7

Чтобы ответить на ваш вопрос относительно действительно дрянного редактора SQL в Access - я полностью согласен. Шрифт воняет, MSAccess всегда плохо переформатирует запрос, он иногда добавляет в метасимволы, которые ломают мой SQL, и, наконец, но худший, если он не может разобрать SQL, он не позволит вам получить к нему доступ!

Моим решением является использование внешнего кода. Я использую DAO для создания экземпляра MSAccess и затем непосредственно редактирую запросы с помощью коллекции QueryDefs. Это позволяет делать большинство вещей - создавать, переименовывать, редактировать и т. Д. Есть несколько вещей, которые вы не можете сделать так, хотя, например, у вас нет доступа к метаданным запроса (описание, скрытие и т. Д.).

Внешний код также велик, потому что вы можете создать набор тестов, с указанием ожидаемых возвращаемых значений и т.д.