Синхронизация таблиц

[Soru]

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

 

[Горбушка]

почему бы не впихнуть ее в крон, например, раз в час?

Потому что очень быстро приведёт к коллизии...
Я зашёл на сайт А, прописал себе статус "Один", зашёл на сайт Б, прописал статус "Два"...

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

К авторизации тоже привязывать нет смысла - надо привязывать к любой (читать "каждой") операции UPDATE/INSERT.

 

[Soru]

Потому что очень быстро приведёт к коллизии...
Я зашёл на сайт А, прописал себе статус "Один", зашёл на сайт Б, прописал статус "Два"...

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

К авторизации тоже привязывать нет смысла - надо привязывать к любой (читать "каждой") операции UPDATE/INSERT.

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

 

[Горбушка]

Soru, кажись, приличные проектировщики ещё только учатся в школе... Ибо НИ В ОДНОЙ CMS МИРА этого не заложено! В лучшем случае есть дата обновления профиля, но чтобы каждого профиля...
Joomla - нет, WP - нет, DLE - нет, phpBB - нет, Drupal - нет, e-107 - нет, MODx - нет... И т.д.

Вариант с датой обновления профиля...
На сайте А я прописал статус "Один", через месяц на сайте Б я прописал статус "Два", на сайте А я добавил аватарку... Итог - на сайте Б статус "Один" и новая аватарка... Смену статуса опять профукали из-за даты обновления профиля - на сайте А она "новее".
Да, я привожу маловероятные, но тем не менее реальные причины коллизий в БД.

ИМХО, решение тут только одно и я его написал - переписать плагины чтобы они использовали 1 таблицу...
Это самое простое с точки зрения реализации и самое эффективное с точки зрения потребления ресурсов решение.

 

[Soru]

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

и здесь мой мозг взорвался.

НИ В ОДНОЙ CMS МИРА

а при чем здесь CMS, если речь идет о кастомном продукте? и зачем и сразу же первыми 4 пунктами перечислить образцы говнокода. причем, 2 и 4 пункты - это совсем адский ад. да, популярные, но популярность не равно качество.

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

 

[sunray]

ИМХО, решение тут только одно и я его написал - переписать плагины чтобы они использовали 1 таблицу...
Это самое простое с точки зрения реализации и самое эффективное с точки зрения потребления ресурсов решение.

шел 16 год 21 века...и никто не мог сделать простую синхронизацию маленьких таблиц в ненагруженных сайтах на MYSQL, это казалось чем-то немыслимым ))

 

[Soru]

шел 16 год 21 века...и никто не мог сделать простую синхронизацию маленьких таблиц в ненагруженных сайтах на MYSQL, это казалось чем-то немыслимым ))

это не немыслимое, это - костыль костыльный для неправильно изначально спроектированной системы.

 

[Горбушка]

и здесь мой мозг взорвался.

пропущено слово "поля"... дата изменения каждого поля профиля...

если речь идет о кастомном продукте?

Если речь о кастомном продукте, то надо делать правильно (описано мной 2 раза), а не костыли делать...

и никто не мог сделать простую синхронизацию

Простая синхронизация 8 разных таблиц с разными данными? Это как?
Тебе уже ответили... Твоя простая синхронизация положит сервер в тот же момент, как ты её запустишь, ибо вместо каждого UPDATE-запроса у тебя будет их 8!

Объединяй таблицы...

 

[sunray]

пропущено слово "поля"... дата изменения каждого поля профиля...

Если речь о кастомном продукте, то надо делать правильно (описано мной 2 раза), а не костыли делать...

Простая синхронизация 8 разных таблиц с разными данными? Это как?
Тебе уже ответили... Твоя простая синхронизация положит сервер в тот же момент, как ты её запустишь, ибо вместо каждого UPDATE-запроса у тебя будет их 8!

Объединяй таблицы...

3-х таблиц... у 8 сайтов

 

[Горбушка]

Ок, 24 таблиц... Какая разница?

Структуру приводи к 1 виду и используй 3 таблицы в 1 БД вместо 8 БД... По-другому - это увеличить нагрузку на БД в 8 раз...