Синхронизация

[Redjik]

@grigori, поддерживаю, можно прямой доступ и туннелем по ssh настроить кстати, вот это как раз денек займет у ТС, зато секьюрно =)

 

[grigori]

@Redjik mysql и без туннелей поддерживает ssl-соединения

правда, придется разбираться с openssl, и танцевать самоподписанными сертификатами в связке с mysql, но совсем простого решения нет вообще

 

[Redjik]

да, я в курсе, тоже норм вариант, чтобы в будущем это перепилить на какой-нить api

 

[Adelf]

Помоему, сделать так, как я посоветовал, не намного сложнее, чем напрямую в базу лезть.

И да. Желаю вам в отместку за ваши посты поработать на таком проекте, где одна подсистема без проблем лезет в базу другой и делает там, что хочет :-P
И таких подсистем куча.

 

[Redjik]

@Adelf, чур тебя, злой ты

 

[WMix]

Все правильно говоришь, но только боюсь первая версия не будет обладать преимуществами выборочного изменения и по сути будет напрямую делать инзерты делиты что не лучше прямого доступа

 

[Adelf]

лучше

 

[grigori]

лучше

Религиозный фанатизм восхищает, но компьютеры работают по законам науки, а научный подход требует обоснования.

Я работал и с совместным использованием одной базы, и rest/rpc-протоколы создавал, и с кривым API месяцами мучался.

Совместное использование одной базы несколькими приложениями - это штатная ситуация, на которую все клиент-серверные СУБД данных рассчитаны изначально.

Приведи хоть одну ссылку на любой труд, статью, документацию, любое обоснование, где бы рекомендовалось ограничить доступ к базе данных только одним приложением. Тема использования БД в распределенных системах за 30 лет проработана вдоль и поперек, и все проблемы, какие есть - описаны. Проблем с использованием одной базы, даже размером более 100 гб с пачкой реплик, разными приложениями, написанными разными командами разработчиков, я не видел.
С крупными базами есть проблемы масштаба - большой объем дампа, сложность структуры, spof, и вот они решаются микросервисной архитектурой, в которую ты предлагаешь выруливать, но масштабирование - это проблема другого порядка, в данной теме - явный overengineering.
Маленькая общая база - отличная связка для приложений с общей логикой.

 

[WMix]

у меня сейчас такой жучек крутится синхронизируется, и пока появились правила изменения выравнивал протокол общения. там много камней, к примеру если одна и таже запись со времени последней синхронизации на различных серверах изменилась, какой доверять? причем эта ситуация не такая уж и редкая - очень часто менется то "что сейчас актуально" с обоих сторон.
ну те сейчас я думаю о неком кью и желательно зокет, чтоб лайф реагировать

 

[grigori]

@WMix, синхронизацию при совместном редактировании можно и на websocket реализовать - broadcast-ить каждое нажатие, как в google docks

 

[WMix]

изучаю, рисую тестики, не могу сообразить как красиво нарисовать так, чтоб автоматом измененные поля подсвечивались с жирным ахтунгом, ну и чтоб писать мало-мало)

 

[Adelf]

@grigori, я вижу прямую аналогию того, что вы сейчас хотите взять и использовать приватные поля(базу) класса(сайта), без его ведома. В краткосрочной перспективе - это круто. Сделали то, что надо без лишних "ненужных" действий. В долгосрочной - сложно-поддерживаемый говнопроект. Ты все больше о физических возможностях. А я о логичности данных действий. Ежу понятно, что юзать базу можно из кучи мест.

Никто вообще не дал вам инфу о том, что структура таблиц в базах одинаковая. Если сайт1 будет работать напрямую с базой сайта2 - это куча лишней инфы о структуре таблиц внешней базы в коде сайта1. Появятся сайт3, сайт4 и начнется кавардак. И вместо сравнительно простых вызовов сервисов будет сложная каша "синхронизации" напрямую в базах. Специй в эту кашу добавят ситуации, когда структура баз у других сайтов будет меняться.

По уму, сайт2 должен сам лезть к сайту1 и узнавать у него все новинки. Тут проскакивал такой совет. Сайт1 максимум может оповестить сайт2 о том, что появились изменения и надо бы обновиться. Но вот такое новичку реально сложно было бы. И я не стал советовать.

 

[AnrDaemon]

http://dhtmlx.com/docs/products/dhtmlxSpreadsheet/

 

[Активист]

@Redjik mysql и без туннелей поддерживает ssl-соединения

правда, придется разбираться с openssl, и танцевать самоподписанными сертификатами в связке с mysql, но совсем простого решения нет вообще

У меня собственный удостоверяющий центр, на серверах / клиентах / Active Directory установлены сертификаты CA (это на всякие *.localhost и *.web.dev и так чисто на офис). А также имеется wildwide сертификат от start ssl com и возможность выпускать их неограниченное количество (для public доменов), вообще очень удобно. Это я такой как бы Тензор для себя ))

 

[grigori]

@Adelf, прости, но аналогия между доступом к базе данных извне и доступом к полям объекта в процессе исполнения называется "логической ошибкой".
"Появятся сайт3, сайт4" - тоже формальная ошибка.

Еще есть взаимоисключающая фраза "Никто вообще не дал вам инфу" и "это куча лишней инфы". Никто не дал же - может быть, хватит одной таблицы.

Ладно. Я с твоими утверждениями не согласен. Я открыт для спора, давай закончим.

 

[Adelf]

Ну вероятно. Не умею я красиво выразить свои мысли. Особенно когда они, действительно, основаны больше на личных убеждениях.
Все серьезные сайты не предоставляют доступ к своим базам напрямую. У них для этого АПИ есть всегда. И причина не столько даже в секьюрности. А в том, что так правильно. В этом случае реальные данные трогает только код этой системы. Значит работают все правила, все бизнес-требования и т.д. и т.п. Нельзя лезть из другой системы в базу и точка. Тут я догматик и не стыжусь этого

 

[hell0w0rd]

Ну вероятно. Не умею я красиво выразить свои мысли. Особенно когда они, действительно, основаны больше на личных убеждениях.
Все серьезные сайты не предоставляют доступ к своим базам напрямую. У них для этого АПИ есть всегда. И причина не столько даже в секьюрности. А в том, что так правильно. В этом случае реальные данные трогает только код этой системы. Значит работают все правила, все бизнес-требования и т.д. и т.п. Нельзя лезть из другой системы в базу и точка. Тут я догматик и не стыжусь этого

апи можно реализовать просто библиотечкой расшаренной. Одна и та же будет использоваться на двух проектах. Мне кажется это самое простое решение в этой ситуации. Причем если сделать все красиво, эту библиотеку можно будет перевести на удаленные вызовы, то есть именно то апи, которое ты имеешь ввиду.

 

[Adelf]

@hell0w0rd, можно и так. Тут выполнится важное для меня условие, что с данными будет работать родственный им код.

 

[AmdY]

А чего вы упёрлись в базу данных, при синхронизации она не единственная проблема. нужно же ещё файлы передавать, фото товара, картинки к статье и т.д. нужно синкать javascript, css и т.д.

 

[Adelf]

нужно синкать javascript, css и т.д.

А это зачем?