Какие-нибудь советы по запуску Rails с бэкэндом Access?

Question

Страшно спросить, но мой клиент может не предложить другого SQL (или SQL-подобного) решения. Я знаю, что в Access есть несколько хуков SQL; Достаточно ли их для базового ActiveRecord?

Позже:

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

Answer 1

Это длинный выстрел, но есть адаптер ODBC для ActiveRecord , который может работать.

Answer 2

Здесь, кажется, что-то есть адаптер подключения Access: http://svn.behindlogic.com/public/rails/activerecord/lib/active_record/connection_adapters/msaccess_adapter.rb

Файл database.yml будет выглядеть так:

development:
  adapter: msaccess
  database: C:\path\to\access_file.mdb

Я опубликую больше после того, как попробую с Rails 2.1

Answer 3

Модит написал:

Истинно в доступе = -1, а не 1

Не правильно. Истина определяется как не ложь. Итак, если вы хотите использовать True в предложении WHERE, используйте Not False. Это обеспечит полную кроссплатформенную совместимость со всеми механизмами SQL.

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

Модит писал:

Access обрабатывает даты иначе, чем обычный TSQL.

Опять же, это будет проблемой, только если вы не пройдете через драйверы ODBC или OLEDB, которые позаботятся о переводе Jet SQL в TSQL для вас.

Модит писал:

У вас могут возникнуть проблемы с установлением отношений.

Я не уверен, почему вы хотите, чтобы приложение Access изменяло схему вашего бэкенда, поэтому мне кажется, что это не проблема.

Answer 4

В Access есть несколько странных вещей, которые могут вызвать проблемы, и я не знаю, позаботится ли об этом ODBC. Если это произойдет, то @Джон Топли прав, ODBC будет вашим единственным отказом.

1. Истинно в доступе = -1, а не 1
2. Access обрабатывает даты иначе, чем обычный TSQL.
3. У вас могут возникнуть проблемы с установлением отношений.

Если вы воспользуетесь доступом, возможно, узнаете больше об отладке AcriveRecord, чем вам когда-либо хотелось (что может быть неплохо)

Answer 5

Другой вариант, который является более сложным, но может сработать, если вы были вынуждены это сделать, - это написать слой веб-сервисов RESTful, который будет предоставлять доступ к рельсам. Если вы осторожны в своем дизайне, эти веб-сервисы RESTful могут использоваться ActiveResoure напрямую, что даст вам большую функциональность ActiveRecord.

Answer 6

Во-первых, вы действительно хотите использовать sqlite.

По моему опыту, сам Access - это куча [отредактированных], но движок базы данных Jet, который он использует, на самом деле довольно быстрый и может обрабатывать некоторые довольно сложные запросы SQL. Если вы найдете адаптер рельсов, который действительно работает, я бы сказал, что все будет в порядке. Только не открывайте БД с помощью интерфейса доступа, пока работает ваше приложение rails: -)

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

Это может дать вам боеприпасы в вашем стремлении использовать реальную базу данных. Удачи

Answer 7

Вы действительно должны убедить их разрешить SQLite. Он очень прост в настройке и работает так же, как Access (как файл, расположенный рядом с приложением на том же сервере).