Форум сайта python.su
pymind
Я имею в виду, что обмениваться “новостями” между базами придётся на уровне приложения, а не на уровне базы данных, т.е. встроенные механизмы движков базы не подойдут по критериям задачи.
Не понятно почему нельзя пользоваться одной базой из всех клиентов. Тем не менее, я бы делал сравнением данных, если нужна надёжность, или журналом изменений, если нужна скорость.
Офлайн
FerromanПочему ты так думаешь? Вроде ничего не мешает.
встроенные механизмы движков базы не подойдут по критериям задачи.
Офлайн
Репликация должна быть обоюдной, отложенной и частичной. Стандратный механизм MySQL все вместе, вроде как, не поддерживает.
Можно взглянуть на PostgreSQL, я там что-то встречал такое. Ну и это все можно сэмулировать хранимыми процедурами/тригеррами на уровне базы.
Офлайн
FerromanУглубился в тему немного. Таки есть проблемы с мастер-мастер. Согласен.
Репликация должна быть обоюдной, отложенной и частичной. Стандратный механизм MySQL все вместе, вроде как, не поддерживает.
FerromanЯ бы даже на этом варианте и остановился. Но автор сам себе хозяин.
Можно взглянуть на PostgreSQL
FerromanА вот этого я бы не делал по ряду причин. По крайней мере для Постри при наличии существующих инструментов.
Ну и это все можно сэмулировать хранимыми процедурами/тригеррами на уровне базы.
Офлайн
Я бы даже на этом варианте и остановился.Там есть какие-то более продвинутые инструменты для репликаций?
А вот этого я бы не делал по ряду причин. По крайней мере для Постри при наличии существующих инструментовПочему?
Офлайн
FerromanДело в том, что на складе есть проблемы с интернетом. Есть большая вероятность, что его могут на продолжительное время отключить. Это происходит время от времени. И при наличии только одной БД, мы бы имели риск лишиться доступа к данным в нужный момент и не смогли бы вести учет заказов со склада.
Не понятно почему нельзя пользоваться одной базой из всех клиентов.
Отредактировано (Сен. 19, 2009 12:38:23)
Офлайн
А обратная связь тогда зачем? Не проще просто синхронизировать время от времени онлайн базу с основной?
Офлайн
FerromanДа, особенно, если учитывать возраст СУБД по сравнению с Мускулом.
Там есть какие-то более продвинутые инструменты для репликаций?
Ferroman1. Асинхронная (ключевое слово, из-за которого и возникает основная проблема) мастер-мастер репликация - штука сложная и при разработке будет много подводных камней. Учитывая планируемый автором интервал 20 минут, велика вероятность конфликтов при операциях: вставка (уникальность), обновление, удаление. А значит, нужен механизм разрешения конфликтов, сам знаешь, штука непростая в реализации (хотя должен делать вещи вполне простые).
Почему?
pymindменя наталкивают на мысль: либо автор слишком кратко описал требуемый функционал системы, либо он будет забивать гвозди микроскопом.
Иными словами складская БД является основной. Онлайн же БД предназначена преимущественно для сбора заказов и отображения актуальной информации о товарах для клиентов (доступное кол-во и др.)
В данном случае складская БД для нас как правило служит локальной БД для программы учета. И нужна возможность забирать (синхронизировать) данные с онлайн БД, когда это возможно.
Офлайн
Ну, раз есть готовые решения с PostgreSQL, то действительно огород городить не стоит. А детальнее задачу тоже бы не помешало рассмотреть, может там просто мелкие изменения слать надо, и игратся с репликациями слать нет смысла. И кросс-базовость останется…
Офлайн
LexanderСпасибо за желание помочь. Итак подробнее:
если бы вы подробнее изложили задачу и выбор инструмента не окончательный, можно было бы подумать над ее решением.
Отредактировано (Сен. 19, 2009 18:24:10)
Офлайн