Страшно спросить, но мой клиент может не предложить другого решения SQL (или подобного SQL). Я знаю, что в Access есть несколько хуков SQL; Достаточно ли их для базового ActiveRecord?
Позже:
Я ценю все предложения по использованию других баз данных, но поверьте мне: я попытался убедить их. Существует «утвержденный» список, и в нем нет баз данных SQL. Попадание чего-либо в список может занять больше года, и этот проект будет завершен через три недели.
Это длинный путь, но есть адаптер ODBC для ActiveRecord, который может работать.
Другой вариант, который является более сложным, но может сработать, если вы были вынуждены это сделать, - написать слой веб-сервисов RESTful, который предоставит доступ к рельсам. Если вы осторожны в своем дизайне, эти веб-сервисы RESTful могут использоваться ActiveResoure напрямую, что даст вам большую функциональность ActiveRecord.
В Access есть несколько странных вещей, которые могут вызвать проблемы, и я не знаю, позаботится ли об этом ODBC. Если это произойдет, @Джон Топли прав, ODBC будет вашим единственным отказом.
- Правда в доступе = -1 не 1
- Access обрабатывает даты иначе, чем обычный TSQL.
- Вы можете столкнуться с проблемами при создании отношений.
Если вы зайдете с доступом, возможно, узнаете больше об отладке AcriveRecord, чем вам когда-либо хотелось (что может быть не плохо)
Кажется, здесь есть что-то вроде адаптера подключения 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
set_table_nameв модели. Вы действительно должны убедить их разрешить использование SQLite. Он очень прост в настройке и работает как Access (как файл, расположенный рядом с приложением на том же сервере).
Во-первых, вы действительно хотите использовать sqlite.
По моему опыту, сам Access - это куча [отредактированных], но движок базы данных Jet, который он использует, на самом деле довольно быстрый и может обрабатывать некоторые довольно сложные запросы SQL. Если вы можете найти адаптер рельсов, который действительно работает, я бы сказал, что у вас все будет хорошо. Только не открывайте БД с помощью интерфейса доступа, пока работает ваше приложение rails :-)
Если ваш клиент достаточно анальный, чтобы позволить вам разрабатывать только с утвержденным списком баз данных, он может быть более обеспокоен тем, что Jet устарел и больше не будет получать поддержку от MS.
Это может дать вам боеприпасы в вашем стремлении использовать реальную базу данных. Удачи
Модит пишет:
Правда в доступе = -1 не 1
Не верно. Истина определяется как не ложь. Итак, если вы хотите использовать True в предложении WHERE, используйте Not False. Это обеспечит полную кроссплатформенную совместимость со всеми механизмами SQL.
Все это говорит о том, что это вряд ли проблема, поскольку любой драйвер, который вы используете для подключения к своему бэкэнду, будет правильно переводить предложения True в WHERE в соответствующее значение. Единственное исключение может быть в сквозных запросах, но в этом случае вы должны писать SQL вне Access, тестировать его на своем бэкэнде и просто вставлять рабочий SQL в представление SQL вашего сквозного запроса в Access.
Модит пишет:
Access обрабатывает даты иначе, чем обычный TSQL.
Опять же, это будет проблемой, только если вы не пройдете через драйверы ODBC или OLEDB, которые позаботятся о переводе Jet SQL в TSQL для вас.
Модит пишет:
Вы можете столкнуться с проблемами при создании отношений.
Я не уверен, почему вы хотите, чтобы приложение Access изменяло схему вашего бэкенда, поэтому мне кажется, что это не проблема.