Мы переходим к установке MySQL «главный / много подчиненный», и меня беспокоит, как можно решить проблему целостности данных, не меняя слишком много кода приложения.
Наше приложение использует ORM (Doctrine PHP), и теоретически мы могли бы расширить его, чтобы просто отправлять операторы SELECT одному из подчиненных или ведущему устройству, а запросы UPDATE / DELETE - ведущему.
, где это не получится из-за природы ORM:
- Выполнение записи на основе устаревших данных от подчиненного устройства, например, прочитать запись от ведомого устройства, у которого недавно был изменен столбец Y на ведущем устройстве, но еще не на ведомом устройстве, а затем сохранить изменения в столбце X вместе с устаревшими данными столбца Y на ведущем устройстве, перезаписав тем самым предыдущее изменение в столбце Y.
- Выполнение чтения из ведомого сразу после недавней записи на мастер (сценарий, когда пользователь только что опубликовал форму - скажем, комментарий на форуме - и перезагрузил страницу и не увидел свой комментарий)
Я думаю, что мы должны построить логику на наших контроллерах приложений, которая должна сообщать уровню данных, есть ли допуск для получения устаревших данных, а когда нет (например, когда есть намерение написать), и когда нет, чтобы однако уровень данных может подключаться к ведущему или подчиненному соответственно; это кажется против хороших методов разработки программного обеспечения. Например. контроллеры должны реализовывать бизнес-логику, не имея дело с тем, должны ли данные поступать от подчиненного или ведущего устройства.
Я уверен, что это было сделано в прошлом. Может быть, не с Doctrine PHP, а с Hibernate или другими решениями ORM?
Есть ли какие-либо общие передовые практики или рекомендации, которыми можно поделиться?