#c# #ms-access
#c# #ms-access
Вопрос:
Я хочу написать приложение Windows Form для взаимодействия с базой данных ms-Access. Я довольно хорошо разбираюсь в SQL (DB2 и T-SQL) и в C # — но не вместе.
Должен ли я использовать поддержку в VS-2019 для табличных адаптеров и привязок данных? Или я должен кодировать свои собственные SqlCommands через OLEDB-соединение? Что поможет мне сделать быстрее? Что вызовет у меня меньше разочарований?
Я часто разочаровываюсь в WYSIWYG, и в прошлом (8 лет назад) у меня были проблемы с использованием некоторых встроенных интерфейсов типа DataSet. На данный момент я выполняю ввод / извлечение в ms-access изначально, но это устарело. Но я редко использую его WYSIWYG — я обычно просто пишу свой собственный запрос.
У меня достаточно хорошо нормализована база данных ms-access — хорошая разбивка первичных и внешних ключей и т. Д. Большие таблицы содержат до 1000 строк и будут оставаться примерно там некоторое время — некоторый медленный рост. Данные отслеживают наших клиентов и занятия, которые они и их дети посещают. Данные содержат личные демографические данные, а также список предлагаемых классов и данные о зачислении в каждый из них — как текущие, так и исторические.
В какой-то момент я надеюсь перенести приложение в веб-реализацию, вместо этого перейдя к размещенной базе данных SQL, чтобы мы могли взаимодействовать с ней где угодно. Но это слишком много, чтобы учиться прямо сейчас.
Ответ №1:
Я не вижу разницы, используете ли вы поставщика oleDB для SQL server, Oracle или ms-access.
Эти поставщики, однажды выбранные, одинаково хорошо извлекают данные в datatable, dataset и почти все объекты .net. Другими словами, не имеет большого значения, используете ли вы драйвер ODBC для SQL server или now (и обесценивается выбор oleDB). Или вы используете sqlprovder.
Все эти поставщики, как я уже отмечал, будут работать и извлекать данные в стандартный набор объектов (sqlcommand, datatable и т. Д.).
Итак, выбор поставщика довольно нейтрален. Конечно, для настольного приложения (автономного) выбор Access в качестве механизма обработки данных довольно хорош. Для многопользовательских пользователей, конечно, предпочтительнее бесплатная версия SQL express.
Преимуществом Access является некоторая дополнительная интеграция, скажем, с Excel (движок JET / ACE может читать и экспортировать в Excel.
Однако, если Access используется в качестве инструмента отчетности или какого-либо существующего настольного приложения, с которым вам нужно взаимодействовать, тогда, конечно, имеет смысл использовать JET / ACE.
Однако, если вы НЕ используете пользовательский интерфейс Access, а ТОЛЬКО механизм обработки данных? Ну, тогда вы просто выбираете X data engine вместо Y data engine. Итак, SQLLite также является хорошим автономным механизмом обработки данных «в процессе» и основан на файлах, как msaccess. Итак, в качестве автономного «в процессе», основанного на файлах, JET / ACE или SQLLite являются отличным выбором.
Имейте в виду, что еще одна веская причина для использования JET / ACE data engie заключается в том, что копия устанавливается по умолчанию на все копии Windows (так было со времен Windows 98SE).).
Однако, если вы выберете встроенный движок, вы сможете использовать только файлы mdb (более старого формата). Если вам нужна некоторая интеграция, скажем, с каким-либо существующим приложением Access (и вам нужен не просто механизм обработки данных), тогда вам нужно использовать более новый механизм обработки данных ACE для работы с форматами файлов accDB. Итак, если взаимодействие с MSAccess в качестве настольного приложения не требуется, и вам ПРОСТО нужен механизм обработки данных, тогда JET подойдет, в отличие от ACE (ACE — это более новый механизм обработки данных Access, и он не установлен в Windows по умолчанию, а устанавливается с Access или как автономныйскачать)
Другое соображение заключается в том, что JET доступен только в виде x32-разрядной версии. Итак, ваше .net-приложение будет запускаться «в процессе» как x32, а не как x64. Если ваш .net-код должен взаимодействовать с другими системами x64 (неуправляемый код), то вы НЕ можете использовать JET, но доступна 64-разрядная версия ACE).
Итак, использование Access или Oracle здесь не имеет значения, вы используете поставщиков .net (oleDB, ODBC). Но, как уже отмечалось, после выбора этих поставщиков все они работают с результирующими объектами .net, такими как таблицы, наборы данных и т. Д.
Можно предположить, что если будущие соображения касаются sql server, то можно и нужно рассмотреть SQL express. Однако автоматическая установка и настройка SQL express — это отдельный проект, и это боль. Где as JET уже установлен в Windows — вам не нужно ничего делать, чтобы использовать его — (даже не нужно его устанавливать).
Я использовал как oleDB provder для доступа, так и поставщика ODBC — не имеет большого значения.
Комментарии:
1. Я пытаюсь изучить не конкретную базу данных — я пытаюсь решить, какой метод доступа к C # использовать. — Я могу использовать материал WYSIWYG от Visual Studio — с довольно приятными диаграммами связей и привязками данных — но тогда SQL скрыт от меня. — Я могу написать свой собственный SQL, используя собственные объекты, но тогда мне придется отслеживать весь SQL и самостоятельно заполнять свои окна. Я не уверен, что будет быстрее и проще в долгосрочной перспективе. Я не могу найти ничего, перечисляющего параллельное сравнение.
2. Я не знаю, что VS будет выполнять взаимосвязи и диаграммы для Access. Вы можете использовать конструктор таблиц в VS, но кроме этого, я не знаю, что VS может это сделать. Вы, конечно, можете создать модель сущности — и вы можете использовать ее для любой базы данных. Однако в большинстве случаев вы, вероятно, просто используете объект connection . Инструменты разработки таблиц будут находиться в Access, SQL server или любой другой системе, которую вы используете (в этих других системах вы создаете таблицы, устанавливаете отношения и т. Д.). Если бы я сказал, используя Access, а затем хотел тот же код для SQL server? Я бы использовал oleDB или ODBC.
3. Возможно, вы имеете в виду конструктор для создания набора данных. SQL для таких наборов данных доступен для просмотра и может быть изменен. Итак, ваш вопрос не в том, какую систему поставщика данных вы должны использовать (поскольку все они работают одинаково), а в том, должен ли я использовать внутренний конструктор наборов данных при работе с формами или просто выписывать sql «in-line». Что ж, выбор действительно за вами. Для простого оператора sql я просто ввожу sql «in-line» прямо в коде. Если sql сложный, или я хочу использовать, скажем, элемент управления связанными формами (или сетку), то вы можете использовать мастер набора данных, если хотите.
Ответ №2:
С точки зрения «что вызовет у меня меньше разочарований», с учетом перечисленного вами опыта и окончательного желания перейти на размещенную базу данных SQL, такую как база данных SQL Azure (по сути, SQL Server в облаке) Я бы посоветовал вам потратить время на изучение возможности перехода непосредственно из Windows Forms в базу данных SQL в Azure.
Ваши технологии доступа к данным по существу ADO.net , в котором, похоже, у вас есть некоторый опыт, который, вероятно, будет включать в себя различные технологии подключения OLEDB и, конечно же, EF или Entity Framework.
По сути, я несколько раз оказывался в вашей ситуации с клиентскими базами данных Access в качестве хранилища данных, адаптеров WYSIWYG или таблиц и «простого связывания данных», похоже, всегда становятся камнем преткновения, который отнимает время и не может быть перенесен при переходе из Access.
Просто мои мысли, основанные на ряде вопросов и информации, которые вы предоставили.
Комментарии:
1. Итак, я должен просто перейти от Access к размещенной БД сейчас? Это неплохая идея.
2. Вы просите дать общий совет по дизайну, на который трудно дать однозначный ответ. Вы задали широкий вопрос, вам придется принять широкий ответ, если вы не получите более конкретного. Основываясь на ваших данных, я бы перешел к размещенному SQL, поскольку вы указали, что это ваш конечный путь. Есть много способов скинуть эту кошку, как сказал Густав выше, многое зависит от предпочтений и опыта.
3. Я не думаю, что я прошу «общего дизайна» — просто должен ли я использовать встроенный материал WYSIWYG или кодировать свой собственный SQL. Я пытался найти что-то, что сравнивает плюсы и минусы между ними (или, если есть что-то еще) — и ничего.
Ответ №3:
Должен ли я использовать поддержку в VS-2019 для табличных адаптеров и привязок данных? Или я должен кодировать свои собственные SqlCommands через OLEDB-соединение? Что поможет мне сделать быстрее? Что вызовет у меня меньше разочарований?
Я начал использовать DatabaseTableAdapters в VS2005 и не оглядывался назад. Приятно работать со строго типизированными таблицами данных и избавляться от SQL.
Но вы найдете много мнений по этому поводу, и это в значительной степени зависит от предпочтений и опыта.