Какой метод C # манипулирования ms-доступом должен использовать опытный администратор баз данных?

Question

Я хочу написать приложение Windows Form для взаимодействия с БД ms-Access. Я довольно хорошо разбираюсь в SQL (DB2 и T-SQL) и в C # - но не вместе.

Должен ли я использовать поддержку в VS-2019 для адаптеров таблиц и привязок данных? Или я должен кодировать свои собственные команды SQLC через соединение OLEDB? Что сделает меня быстрее? Что вызовет у меня меньше разочарований?

Я часто расстраиваюсь из-за WYSIWYG, и в прошлом у меня были проблемы с использованием некоторых встроенных интерфейсов типа DataSet (восемьдесят лет назад). На данный момент я делаю ввод / извлечение в ms-access изначально - но это стареет. Но я редко использую это WYSIWYG - обычно я просто пишу свой собственный запрос.

Я достаточно хорошо нормализовал базу данных ms-access - хорошую разбивку первичных и внешних ключей и т. Д. Большие таблицы содержат до 1000 строк - и некоторое время будут оставаться там - некоторое замедление роста. Данные отслеживают наших клиентов и занятия, которые они и их дети посещают. Данные имеют личную демографию, а также список предложений классов и количество зарегистрированных в каждой из них - как текущих, так и исторических.

В какой-то момент я надеюсь перевести приложение в веб-реализацию, вместо этого перейдя на размещенную базу данных SQL - чтобы мы могли взаимодействовать с ней где угодно. Но это слишком много, чтобы учиться прямо сейчас.

Answer 1

Я не вижу разницы, если вы используете провайдер oleDB для сервера SQL, Oracle или ms-access.

Эти провайдеры, выбранные однажды, одинаково хорошо переносят данные в набор данных, набор данных и почтивсе .net ojbects.Другими словами, это не большая проблема, что вы используете драйвер ODBC для SQL-сервера или сейчас (и не рекомендуется выбирать oleDB).Или вы используете sqlprovder.

Все эти провайдеры, как я уже отмечал, будут работать и извлекать данные в стандартный набор объектов (sqlcommand, datatable и т. Д.).

Таким образом, выбор провайдера довольно нейтрален.Конечно, для настольного приложения (автономного) выбор Access в качестве движка данных вполне удобен.Конечно, для многопользовательского режима предпочтительнее использовать бесплатную версию SQL Express.

Преимущество Access заключается в дополнительной интеграции, скажем, с Excel (механизм JET / ACE может читать и экспортировать в Excel.

Однако, если Access является инструментом отчетности или каким-либо существующим настольным приложением, с которым вам нужно взаимодействовать - тогда, конечно, использование JET / ACE имеет смысл.

Однако, если вы НЕ используете AccessПользовательский интерфейс и просто механизм обработки данных? Итак, вы просто выбираете механизм обработки данных X вместо механизма обработки данных Y. Итак, sqlLite также является хорошим «незавершенным» механизмом обработки данных и основан на файлах, как msaccess. Итак, как файлна основе автономного «в процессе», тогда JET / ACE или sqlLite являются отличным выбором.

Имейте в виду, что еще одна веская причина для использования механизма данных JET / ACE заключается в том, что копия устанавливается по умолчанию на всекопии окон (так было со времен Windows 98SE).

Однако, если вы выбрали встроенный движок, вы можете использовать только mdb (более старый формат)файлы.Если вам требуется интеграция, скажем, с каким-либо существующим приложением Access (и вам нужен не просто механизм обработки данных), то вам придется использовать более новый механизм обработки данных ACE для работы с форматами файлов accDB.Таким образом, если взаимодействие с MSAccess в качестве настольного приложения не требуется, и вам просто необходим механизм обработки данных, то JET отлично подходит для ACE (ACE является более новым механизмом данных Access и по умолчанию не устанавливается в Windows, ноустанавливается вместе с Access или как отдельная загрузка)

Другое соображение заключается в том, что JET доступен только в 32-разрядной версии.Таким образом, ваше приложение .net будет работать «в процессе» как x32, а не как x64.Если ваш код .net должен взаимодействовать с другими x64 (неуправляемыми кодами) системами, вы НЕ МОЖЕТЕ использовать JET, но есть доступная x64-битная версия ACE).

Итак, используя Access или Oracleне имеет значения здесь, вы используете .net провайдеров (oleDB, ODBC).Но, как уже отмечалось, после того, как вы выбрали этих провайдеров, все они работают с результирующими объектами .net, такими как таблицы, наборы данных и т. Д.

Можно привести случай, когда в будущем рассмотрим вопрос sql server, тогда можно иследует рассмотреть SQL Express.Тем не менее, автоматическая установка и настройка SQL Express - это целый проект, и это боль.Где, поскольку JET уже установлен в Windows - вам не нужно ничего делать, чтобы использовать его - (даже не нужно его устанавливать).

Я использовал как oleDB provder для Access, так и ODBCпровайдер - ничего страшного.

Answer 2

Должен ли я использовать поддержку в VS-2019 для адаптеров таблиц и привязок данных?Или я должен кодировать свои собственные команды SQLC через соединение OLEDB?Что сделает меня быстрее?Что вызовет у меня меньше разочарований?

Я начал использовать DatabaseTableAdapters в VS2005 и не оглядывался назад.Приятно работать со строго типизированными таблицами данных и разбирать SQL.

Но вы найдете много мнений по этому поводу, и это очень вопрос предпочтений и опыта.

Answer 3

С точки зрения «Что вызовет у меня меньше разочарования», учитывая опыт, который вы перечислили, и конечное желание перейти на размещенную базу данных SQL, такую ​​как база данных Azure SQL (по сути, SQL Server в облаке), я бы сказал, Предложите время, которое лучше всего использовать, исследуя возможность перехода непосредственно из Windows Forms в базу данных SQL в Azure.

Ваши технологии доступа к данным, по сути, ADO.net, и, похоже, у вас есть некоторый опыт в этом, который, вероятно, будет включать ваши различные технологии подключения OLEDB и, конечно, EF или Entity Framework.

Я был несколько раз в вашей ситуации с клиентскими базами данных Access в качестве хранилища данных, адаптерами WYSIWYG или таблиц и «легким связыванием данных», которые, кажется, всегда становятся камнем преткновения, который пожирает время и не может быть отменен. вперед при переходе из Access.

Только мои мысли, основанные на ряде вопросов и информации, которую вы предоставили.