приветы всем!
вобщем столкнулся с такой дикостью. Заказчик заказал сайт интернет-магазин. Шаблон совершенно одинаков только имеет разные цвета. в нем имеется 3 больших категории, которые являются что-то вроде независимыми частями сайта и теперь заказчик хочет разделить все 3 этих части на 3 разных домена со своим хостингом и БД. Проблем в принципе нет ни каких за исключением меню, в которое подставляются данные со всех 3-х категорий.
Вот собственно и стоит задача как объединить данные с 3 баз данных на разных доменах, чтобы высветить агрегированную информацию в блоке меню? Как все мы знаем аякс кросдоменно не работает. Вот прошу совета и помощи. Может у когото есть идеи как всё это правильно организовать?
1. Panoptik - 13 Декабря, 2011 - 10:25:45 - перейти к сообщению
2. snikers987 - 13 Декабря, 2011 - 11:49:20 - перейти к сообщению
А что мешает хранить все меню полностью в каждой базе?
3. Panoptik - 13 Декабря, 2011 - 11:51:40 - перейти к сообщению
проблема в том, что изменения в одной базе не отображаются в другой. делать репликации для столь мелких проектов как-то не логично.
пока нашел выход такой: при выводе меню будем коннектиться в разные базы и извлекать из каждой базы часть нужной информации
пока нашел выход такой: при выводе меню будем коннектиться в разные базы и извлекать из каждой базы часть нужной информации
4. Zuldek - 13 Декабря, 2011 - 12:00:31 - перейти к сообщению
А в чем проблема хранить модуль меню на одном проекте, который при генерации меню собирает его с всех трех баз, а с других его подгружать при загрузке страницы?
Это криво и неправильно. Поэтому просто пишем простой сценарий и ставим на крон, который генерирует меню товаров, раз в n-часов собирая его со всех трех баз и записывая в свою.
Это криво и неправильно. Поэтому просто пишем простой сценарий и ставим на крон, который генерирует меню товаров, раз в n-часов собирая его со всех трех баз и записывая в свою.
5. DlTA - 13 Декабря, 2011 - 12:01:40 - перейти к сообщению
если есть доступ к остальным база из любого магазина, то можно
раз в какой то промежуток времени опрашивать остальные базы на предмет изменений
изменения вносить в каждую из баз, тем самым избаветесь от долгих запросов к удаленным базам, но целостность (с поправкой на время перезапроса) останется
раз в какой то промежуток времени опрашивать остальные базы на предмет изменений
изменения вносить в каждую из баз, тем самым избаветесь от долгих запросов к удаленным базам, но целостность (с поправкой на время перезапроса) останется
6. snikers987 - 13 Декабря, 2011 - 12:02:04 - перейти к сообщению
Panoptik пишет:
проблема в том, что изменения в одной базе не отображаются в другой. делать репликации для столь мелких проектов как-то не логично.
пока нашел выход такой: при выводе меню будем коннектиться в разные базы и извлекать из каждой базы часть нужной информации
пока нашел выход такой: при выводе меню будем коннектиться в разные базы и извлекать из каждой базы часть нужной информации
Хотел это предложить, но удаленные соединения не очень хорошо, ляжет один сайт, а тупить будут все. Можно сделать что при апдейте к примеру в админке, апдейдт затрагивает по очередно все три базы.
И внешнее подключение к бд вообще не есть гуд.
7. Panoptik - 13 Декабря, 2011 - 12:11:32 - перейти к сообщению
в данном случае пока все 3 базы на локалхосте находятся. а после если на хостинге будет удаленное подключение, то тут уже ничего не поделаешь
8. snikers987 - 13 Декабря, 2011 - 12:23:51 - перейти к сообщению
Можно вообще изменения записывать в фаил (готовый sql запрос) и кроном забирать его содержимое и выполнять. Так вообще удастся избежать внешних коннектов к бд