|
|
|
Синхронизация таблицы (в памяти) между приложениями по сети
|
|||
|---|---|---|---|
|
#18+
Dima T Это оно и есть, я сразу предложил ее поизучать 22188155, хотя бы в части теории, а дальше отталкиваться от нее при постройке своего велосипеда. это уж поизучали и в теории, и накушались на практике, про mssql могу судить, серебренной пули там нет Dima T А если у обоих записи правильные? Допустим в двух разъединенных БД изменили одну и туже запись, что делать когда связь восстановится? в моем случае проще чем с БД которая должна любые конфликты разруливать. я могу подняться с уровня таблиц на уровень документов, также есть дополнительная информация и допущения. сейчас - правильная та что на "главном" сервере. планируется - правильная на том сервере который owner документа. также, вот только дошло... документ со временем обрастает доп данными, и в принципе можно понять с каким из них больше работали, который из них более полный Dima T Автоматически невозможно разрешить все конфликты, точнее можно, но с потерей данных в некоторых случаях. в абсолютном значении слова "потеря" - да, к сожалению но интуиция подсказывает какой-то компромисс нащупать возможно. к примеру условия выше + хранить ChangeLog чтоб если у пользователя что-то перетерлось, он мог посмотреть что раньше вводил руками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2020, 08:59 |
|
||
|
Синхронизация таблицы (в памяти) между приложениями по сети
|
|||
|---|---|---|---|
|
#18+
Dima T Гугли "Репликация БД", это теория по твоей задаче. Первоисточник списка где находится? Если все узлы могут менять список, то возможны конфликты. Зря умерла тема репликации. Надо поднять. С каким-то внятным ТЗ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2020, 11:22 |
|
||
|
Синхронизация таблицы (в памяти) между приложениями по сети
|
|||
|---|---|---|---|
|
#18+
Кифирчик в моем случае проще чем с БД которая должна любые конфликты разруливать. я могу подняться с уровня таблиц на уровень документов, также есть дополнительная информация и допущения. сейчас - правильная та что на "главном" сервере. планируется - правильная на том сервере который owner документа. Если документ меняет только владелец, то проблем нет - мастер для документа тот сервер, к которому владелец приписан. Но думаю кроме документов еще есть общие таблицы: справочники и т.д. Например решили два юзера с разных серверов внести одно и тоже в справочник, в итоге получили задвоение сущностей. Это не критично, можно полечить объединением. Хуже, например, если при оформлении билета прошло бронирование одного и того же места с разных серверов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2020, 15:10 |
|
||
|
|
start [/forum/topic.php?fid=20&msg=39995117&tid=1398476]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 17ms |
| total: | 157ms |
| 0 / 0 |
