Вы определенно не хотите иметь несколько сайтов все говорят с одной и той же базе данных. Это рецепт беспорядка. Вот несколько примеров вещей, которые могут пойти не так ...
- Сайт 1 обновляет таблицу одновременно с сайтом 2, и возникает конфликт относительно того, какие данные должны быть сохранены.
- Вы обновляете код на сайте 1, чтобы добавить новый столбец в таблицу. Вы делаете то же самое для сайта 2, но обновление сайта 2 происходит из-за того, что новый столбец уже добавлен (по сайту 1).
- Один сайт пытается прочитать запись сразу после того, как другой удалил ее, и есть конфликт.
- и т.д. (есть еще много случаев, я уверен, что вы можете думать)
Но не все потеряно !!!
Что вам нужно сделать, так это создать единый сервер, который является API для других сайтов. Все ваши сайты будут вызывать этот единственный сервер для всех обновлений, и единственный сервер будет единственным, что говорит с базой данных.
Ваш API будет иметь несколько основных действий: один для создания новой записи, один для записи, один для обновления записи и один для удаления записи.
Вы можете начать с проверки документации по ресурсам Rails по адресу http://guides.rubyonrails.org/routing.html#resource-routing-the-rails-default - в ней описано, как вы можете автоматически генерировать базовый CRUD API. CRUD btw означает создание, чтение, обновление и удаление - основные функции, которые вы хотите сделать.
Позже вы можете получить более творческий подход к API и расширить его, чтобы добавить дополнительные функции. Предположим, что каждый раз, когда вы создаете заказ, вы должны предпринять несколько шагов.Что вы можете сделать, это сделать один маршрут в вашем API, который вы вызываете, а контроллер для этого маршрута делает все необходимые обновления. В принципе, каждый раз, когда вы обнаруживаете, что пишете код для одного из ваших сайтов, каждый раз каждый раз вызывающий один и тот же набор вызовов API, вам следует подумать о создании нового маршрута в API, который делает этот вызов.
Другим преимуществом API является то, что он позволяет вам хорошо подумать о том, что вы хотите получить от своей базы данных и действий.
Вы можете сначала создать базовый API, а затем написать только один из своих сайтов. Получите его работу, затем добавьте еще один. Подумайте о Googling для «Rails restful API» для некоторых хороших ссылок и удачи!
Это рецепт для * ужасающего * исполнения, хотя и много повторной реализации логической стороны приложения, которая должна быть выражена в виде запросов. Это быстрый путь к n + 1 территории SELECT. Конечно, есть место для такого подхода - но его редко следует строить на простом API стиля «CRUD». –
Не во ВСЕХ рецепт плохой производительности. Вот для чего предназначены API-интерфейсы - позволяя нескольким приложениям обращаться к общей системе данных и бизнес-логике. –
Я действительно смущен - вы говорите, что даже базовый CRUD API - это плохой подход? –