Любые ORM, которые работают с MS-Access (для прототипирования)?

Question

Я нахожусь на ранней стадии проекта, и пока не ясно, нужна ли нам «настоящая» база данных (то есть SQL Server и др.). Итак, я занимался прототипированием с использованием MS-Access, который до сих пор работал нормально. (развивается в C # / VS2008 / .Net 3.5 / MS-Access 2000).

Однако несоответствие объектно-реляционного импеданса уже становится раздражающим и будет только ухудшаться по мере развития проекта.

Мне не удалось найти ORM, который будет работать с MS-Access. Есть предложения?

Редактировать - следить В итоге мы использовали Fluent NHibernate, главным образом потому, что он автоматически сопоставляет нашу объектную модель с реляционной базой данных, что стало для нас огромной победой. Большинство примеров кода FNH, которые мы обнаружили, использовали SQLite, и это работало настолько хорошо, что мы намереваемся использовать его для нашей производственной базы данных. (Приложение представляет собой настольный пакет для сбора и анализа научных данных).

Answer 1

Файлы MSAccess можно настроить в качестве источника ODBC на компьютерах с Windows. Практически любой ORM позволит вам использовать ODBC. Здесь - это краткое руководство по настройке, оно описано для Win2k, но процесс для XP + такой же. Вам также необходимо установить MDAC на вашем устройстве.

Кажется, что NHibernate также имеет встроенную поддержку MSAccess, см. здесь . Я никогда не использовал это все же. Он также имеет драйвер ODBC. . Многие другие также поддерживают ODBC.

И снова, как говорят другие ... MSAccess не масштабируется ... period . Установить настоящий сервер базы данных довольно просто, поэтому я рекомендую SQL Server Express, как это делают другие, или даже MySQL или Postgre, что бы ни было проще в настройке.

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

Answer 2

Существует только один сценарий, когда выбор ядра базы данных Access является хорошим выбором: при создании автономного приложения Access с использованием форм доступа (хотя выбор использования Access в первую очередь сомнительный;)

Ядро базы данных, с которым VS2008 лучше всего работает, - это SQL Server, и у вас не будет проблем с поиском ORM, который хорошо работает с SQL Server.

Answer 3

Не могу дать вам ответ на свой вопрос, но вместо Access вы можете рассмотреть один из следующих вариантов:

• SQL Server Express: бесплатен и совместим с полным SQL Server
• SQL Server Compact : также бесплатно, не требует развертывания / установки, не поддерживает все функции (например, нет хранимых процедур).

Answer 4

Я рекомендую вам использовать что-то вроде Microsoft SQL Server или PostgreSQL для создания прототипов. Если вы не хотите изучать конкретный синтаксис SQL и устанавливать специальные инструменты для разработки схемы базы данных, вы можете использовать ORM, который автоматически генерирует схему базы данных из вашего объявления постоянных классов. В любом случае, этот подход очень эффективен для создания прототипов.

Answer 5

На этом этапе, если вы не уверены, нужна ли вам «настоящая» база данных или нет, я бы пропустил MS Access и сразу перешел к SQL Server Express. Это бесплатно и все еще позволяет вам делать все, что вам нужно.

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

Answer 6

Доступ это просто плохая, плохая идея. Я считаю, что MS включает в себя только доступ в Office, чтобы старые пользователи были довольны

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

См. Это сравнение между SQL Server Express и SQL Server Compact . В документе сравнения также упоминаются некоторые проблемы с другими хранилищами данных, включая Access.

Если вы ДЕЙСТВИТЕЛЬНО обеспокоены возможностью установки SQL Server Express, рассмотрите вариант SQL Server Compact:

• это может быть связано с вашим распространяемым приложением. Нет необходимости устанавливать сервис (для этого могут потребоваться права администратора во время установки вашего приложения); все позаботится, когда вы установите приложение. Это имеет смысл, если вам нужно, чтобы данные находились на компьютере пользователя, а не на сервере, и наиболее аналогично использованию Access.

• Он менее мощный, чем Express (не поддерживает представления, триггеры, хранимые процедуры, которые я считаю обязательными)

• Очень легко масштабируется до Express или других версий SQL Server

• Подходит для небольших установок, таких как планшеты, мобильные устройства и т. Д.

Всегда учитывайте масштабируемость при разработке любого приложения. Вы не хотите, чтобы вам пришлось писать компилятор PHP-> C ++, если / когда ваше приложение станет успешным только потому, что вы выбрали неправильный инструмент заранее.

Пока мы на этом:

Большая проблема с Access (или, в данном случае, движком Jet, который вы действительно используете при интеграции базы данных Access с приложением .NET) заключается в том, что не существует «сервера», который обрабатывает запросы данных. Движок, размещенный в вашем приложении, должен читать и записывать непосредственно в файл на диске, который содержит базу данных. Всякий раз, когда это происходит, файл должен быть заблокирован для предотвращения одновременной записи. Грязное чтение становится все более распространенным по мере роста числа пользователей, равно как и вероятность повреждения базы данных.

Представьте себе, что каждый клиент в большом ресторане пытается одновременно войти на кухню, чтобы записать свои заказы или забрать их еду. Хаос в результате. Там будет много разбитой посуды, на кухне будет беспорядок, вам повезет получить то, что вы заказали, в любых съедобных условиях. С одним клиентом это, вероятно, работает нормально. С 5, а, может быть. С 20,50,1000? Не так много.

Итак, ресторанная индустрия представила официантов и менеджеров, которые буферизируют IO на кухне. Приложение сервера базы данных делает нечто примерно аналогичное этому, ограничивая доступ к файлам на диске. Каждый получает то, что хочет, быстрее и намного надежнее, а хранилище данных защищено.

Answer 7

LLBLGen работает с Access