Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Добрый день!
Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном.
Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту.
Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.)
После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?
3 июн 19, 11:43    [21900247]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 780
NewBy52,

если не секрет, клиент на чём? В общем случае механизм корректировки данных нужно менять. Кто придумал такую логику работы, не спрашиваю.
3 июн 19, 12:09    [21900293]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48131

NewBy52
Вопрос: как синхронизировать такие коллизии?

Ответ: выяснить какого чёрта два оператора лезут в один и тот же объект и разнести его на
два разных.

Posted via ActualForum NNTP Server 1.5

3 июн 19, 12:58    [21900372]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
KreatorXXI
NewBy52,
если не секрет, клиент на чём? В общем случае механизм корректировки данных нужно менять.

Я понимаю, что надо менять. Вопрос - как менять. Если данные не загрузить в память, некоторые операции будут считаться о-чень долго. Придумать бы какой-нибудь семафор, говорящий о том, что объект занят. Но 100% надёжного придумать не могу.
3 июн 19, 13:08    [21900382]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48131

NewBy52
Вопрос - как менять.

Заведи поле "версия объекта". Перед попыткой сохранения - проверяй, что эта версия в базе
та же, что была при загрузке объекта. Если нет - грузи новую версию и проси пользователя
решить какая из них правильнее. Так работают все VCS.

Posted via ActualForum NNTP Server 1.5

3 июн 19, 13:10    [21900388]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
L_argo
Member

Откуда:
Сообщений: 889
NewBy52
Вопрос: как синхронизировать такие коллизии?
Не допускать их.

У вас очень странная работа с данными. Как один и тот же показатель может быть разным у двух юзеров ?
3 июн 19, 13:10    [21900389]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Dimitry Sibiryakov
Ответ: выяснить какого чёрта два оператора лезут в один и тот же объект и разнести его на
два разных.

Ну, право-то имеют. Но не одновременно. Выше написал, что семафор, говорящий: "занято для коррекции", устроил бы. Вопрос - как.
3 июн 19, 13:10    [21900390]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48131

NewBy52
Ну, право-то имеют. Но не одновременно.

Почему нет? Один-то всегда данные сохранит позже, он и будет прав.

Posted via ActualForum NNTP Server 1.5

3 июн 19, 13:13    [21900394]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
L_argo
У вас очень странная работа с данными. Как один и тот же показатель может быть разным у двух юзеров ?

Может.
автор
Есть многое на свете, друг Горацио...
3 июн 19, 13:15    [21900398]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Dimitry Sibiryakov
Почему нет? Один-то всегда данные сохранит позже, он и будет прав.

Не обязательно. Если юзер более высокого статуса (в плане знаний предмета) сохранит данные, а юзер более низкого статуса (находящийся порой за тысячи километров) сохранит их позже, и затрёт данные первого пользователя, это будет нехорошо. Поэтому, второй пользователь должен видеть, что сейчас стоит отказаться от сохранения данных.
3 июн 19, 13:20    [21900404]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Dimitry Sibiryakov
Заведи поле "версия объекта". Перед попыткой сохранения - проверяй, что эта версия в базе
та же, что была при загрузке объекта. Если нет - грузи новую версию и проси пользователя
решить какая из них правильнее. Так работают все VCS.

А вот это мысль очень полезная для меня. Спасибо, надо будет обдумать.
3 июн 19, 13:21    [21900408]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
NewBy52
Dimitry Sibiryakov
Заведи поле "версия объекта". Перед попыткой сохранения - проверяй, что эта версия в базе
та же, что была при загрузке объекта. Если нет - грузи новую версию и проси пользователя
решить какая из них правильнее. Так работают все VCS.

А вот это мысль очень полезная для меня. Спасибо, надо будет обдумать.

Да, это решит проблему. Ещё раз спасибо.
3 июн 19, 13:31    [21900423]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
L_argo
Member

Откуда:
Сообщений: 889
Нужно вообще пересмотреть схему работы с данными.
Текущая схема ущербна.
3 июн 19, 13:42    [21900445]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 780
NewBy52,

надо всё-таки исходить из того, что разные пользователи могут одновременно править разные данные одного объекта. Почему нет? Таблицы же разные. Вот когда два пользователя правят одну и ту же запись в одной и той же таблице, то тогда должно быть сообщение пользователям о проблеме. Но это стандартный механизм работы с БД. Почему я и спрашиваю о клиенте.
3 июн 19, 13:43    [21900449]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
KreatorXXI
NewBy52,
надо всё-таки исходить из того, что разные пользователи могут одновременно править разные данные одного объекта. Почему нет? Таблицы же разные. Вот когда два пользователя правят одну и ту же запись в одной и той же таблице, то тогда должно быть сообщение пользователям о проблеме. Но это стандартный механизм работы с БД. Почему я и спрашиваю о клиенте.

Я знаю стандартный механизм работы с БД. Но тут "правка" может подразумевать удаление 1000+ записей вспомогательной таблицы и заполнение её 2000+ других записей (или наоборот). И так по всем вспомогательным таблицам. Потому что многие записи расчетные. Но одновременно их можно и индивидуально править. Таково было ТЗ.
3 июн 19, 14:01    [21900485]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Компьютеры на Win7. СУБД пока не выбрана.
3 июн 19, 14:04    [21900493]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 780
NewBy52,

какое-то противоречивое ТЗ. Наверно рано говорить о практической реализации. Надо понять какие данные могут одновременно редактироваться. Можно пойти, например, таким путём. Один пользователь "взял" объект (в каком-нибудь поле главной таблицы появляется идентификатор "взявшего"). Всем остальным отлуп до тех пор пока "взявший" не внесёт все изменения.
3 июн 19, 14:09    [21900506]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
KreatorXXI
NewBy52,
Один пользователь "взял" объект (в каком-нибудь поле главной таблицы появляется идентификатор "взявшего"). Всем остальным отлуп до тех пор пока "взявший" не внесёт все изменения.

Это не сработает. Свет отключили у пользователя, и объект завис для всех.
3 июн 19, 14:11    [21900511]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
А вот схема, предложенная Дмитрием, проблему закрывает. Собственно, я уже получил ответ на вопрос.
3 июн 19, 14:17    [21900517]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48131

KreatorXXI
Почему нет?

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

Posted via ActualForum NNTP Server 1.5

3 июн 19, 14:22    [21900527]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 780
Dimitry Sibiryakov,

была бы одна/несколько таблиц, то с версионностью можно было бы жить. А если масса подчинённых таблиц, да ещё удаления/добавления тысячами, проверка перед записью будет занимать нехилое время. Ещё где-то "старые" данные нужно хранить. Я поэтому и говорю - может ТЗ чуть подправить?
3 июн 19, 14:38    [21900546]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7827
KreatorXXI
Ещё где-то "старые" данные нужно хранить

Зачем старые данные? Номера версии вполне достаточно

Банальное сравнение номера версии перед UPDATE'ом. Если не совпадает - ошибка и транзакция ROLLBACK.

IMHO Так обычно оптимистичная блокировка и работает.
3 июн 19, 14:41    [21900547]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7827
NewBy52
Это не сработает. Свет отключили у пользователя, и объект завис для всех.

Жесть какая. Блокировки обычно отслеживаются на уровне ОС (ну или СУБД).

Отключение света никак не мешает. Свет отключился, сетевая карта выключилась, сеанс прервался, блокировки снялись

p.s. SQLLite блокировками OS пользуется. AFAIK по гуглю.
3 июн 19, 14:46    [21900552]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Leonid Kudryavtsev
NewBy52
Это не сработает. Свет отключили у пользователя, и объект завис для всех.

Жесть какая. Блокировки обычно отслеживаются на уровне ОС (ну или СУБД).

Отключение света никак не мешает. Свет отключился, сетевая карта выключилась, сеанс прервался, блокировки снялись

Вы невнимательно прочитали цепочку ответов.
3 июн 19, 15:24    [21900605]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7827
Ну, право-то имеют. Но не одновременно. Выше написал, что семафор, говорящий: "занято для коррекции", устроил бы. Вопрос - как.

Семафор в нормальных SQL Server'ах обычно:
SELECT FOR UPDATE
но блокировать на долгое время не есть айс + некоторые СУБД блокируют не запись, а страницу AFAIK

Если не хочется стандартные семафоры, то 95% СУБД предоставляют возможность пользовательских семафоров (вроде, не точно: Oracle DBMS_LOCK, PostgreSQL - Advisory Locks, MS SQL не знаю).

Проблемы с "выключили питание" быть не должно

Если хранить дополнительную информацию, то наверное отдельная табличка + автономные транзакции

Но сначала стоит определится, что же хочется:

писсимистик блокировку - "семафор, говорящий: "занято для коррекции", устроил бы"
или ему писсимистичной не хватает, и хочется оптимистичную - версия
или какую-то помесь писсимистик + оптимистик
3 июн 19, 15:41    [21900621]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Arm79
Member

Откуда: МО, Раменское
Сообщений: 3669
Если MS SQL, то рассмотрите applock
3 июн 19, 15:45    [21900628]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
L_argo
Member

Откуда:
Сообщений: 889
фейспалм, блин..
Причем тут блокировки ??????

Речь про организацию работы с данными. Она изначально ущербна.
Видимо есть некие параметры, кот. нужны в разных местах.
И юзеры их зачитывают и потом меняют на свое усмотрение.
3 июн 19, 15:59    [21900649]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
L_argo
Видимо есть некие параметры, кот. нужны в разных местах.
И юзеры их зачитывают и потом меняют на свое усмотрение.

Нет.
3 июн 19, 16:11    [21900667]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7827
L_argo
Причем тут блокировки ??????

Мне кажется топик стартеру нужно почитать(поиграться руками) с Писсимистик и Оптимистик блокировками

L_argo
Речь про организацию работы с данными. Она изначально ущербна.
Видимо есть некие параметры, кот. нужны в разных местах.
И юзеры их зачитывают и потом меняют на свое усмотрение.

IMHO
Обычная "ущербная" организация работы a la ORM (Hibernate). Все затащили в память, а дальше for'ами, for'ами.... Но AFAIK, ORM (Hibernate) обычно как раз Optimistic блокировки и используют.

Для ИС, возможно, осмысленно использовать какой нибудь микс писсимистик + оптимистик. Например объекты "верхнего" уровня блокировать писсимистик, а объекты ниже уровнями - оптимистик.

Если тупо (!!!) реализовать предложение Dimitry Sibiryakov, то с оптимистик блокировкой много лулзов можно словить.

Например, бизнес процесс выставление счета за ком. услуги за нужный период
1. Для каждого клиента:
1.1. Считали данные
1.2. Сформировали новые данные
1.3. Старые данные НЕ менялись (т.ч. UPDATE не было, только INSERT'ы)
2. Го на пункт 1
3. Коммит
Java, Hibernate, Cobol, Optimistic блокировка по умолчанию (номер версии).... Модно, молодежно и считает минутами

Реалии:
1. Один пользователь запустил пакет из 100500 клиентов по каким-то условиям
2. Второй пользователь запустил пакет из 100500 клиентов, но по другим условиям
3. Некоторые клиенты вошли в оба списка
===>
Блокировок нет, зато счета за период у ряда клиентов банально ЗАДВОИЛИСЬ. Смотрим, радуемся, восторгаемся архитекторами Oracle Customer Care & Billing. Модно, молодежно и куча лулзов.
3 июн 19, 17:22    [21900737]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
vmag
Member

Откуда: MP
Сообщений: 3235
NewBy52
А вот схема, предложенная Дмитрием, проблему закрывает. Собственно, я уже получил ответ на вопрос.


да и не закрывает совсем...
ну получил я версию объекта после того как отдолбил 1000 параметров в течение двух часов и что?
- я должен понять и принять тот факт, что я два часа долбил зря, передо мной вроде как долбил крутой ?
- или я честно отработал день, а на утро увидел что вчера работал зря, мои труды потерли...
- а может у меня пусть 10 % но более правильная информация, которая ушла в никуда... ?
ИМХО тут блокировки и и всякие версии не сработают на все 100 ...

Не хватает организационных мер:
- например поделить параметры между регионами (ответственными), ну кому например нужно вводить показания счетчиков, как ни тому, кто сейчас смотрит на этот счетчик, или Иванову, который сидит хрен знает где от счетчика, но он круче по статусу...
- или поделить юзеров на две категории: администраторы и юзеры. Первые вносят изменения, вторые используют БД и готовят предложения по изменению... Например, юзер за 1000 км, готовит проект для изменения объекта, Администратор его рассматривает и принимает решение принять изменения полностью или в связи со своим статусом внести изменения (дополнения) и потом уже принять изменения...

Думаю если бы ТС выложил предметную область, хотя бы намеком, все было бы гораздо прозрачнее...
Трабл когда 1000 параметров и более правят все сразу, не лечится, его нужно устранять на уровне начальной логики
5 июн 19, 14:20    [21902542]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
vmag
да и не закрывает совсем...

Закрывает, закрывает...
vmag
ну получил я версию объекта после того как отдолбил 1000 параметров в течение двух часов и что?
- я должен понять и принять тот факт, что я два часа долбил зря, передо мной вроде как долбил крутой ?
- или я честно отработал день, а на утро увидел что вчера работал зря, мои труды потерли...
- а может у меня пусть 10 % но более правильная информация, которая ушла в никуда... ?

Не всё так страшно. Собственно, ручного ввода так немного. В основном, расчетные данные.
vmag
Не хватает организационных мер:

Кто сказал?
vmag
- например поделить параметры между регионами (ответственными), ну кому например нужно вводить показания счетчиков, как ни тому, кто сейчас смотрит на этот счетчик, или Иванову, который сидит хрен знает где от счетчика, но он круче по статусу...
- или поделить юзеров на две категории: администраторы и юзеры. Первые вносят изменения, вторые используют БД и готовят предложения по изменению... Например, юзер за 1000 км, готовит проект для изменения объекта, Администратор его рассматривает и принимает решение принять изменения полностью или в связи со своим статусом внести изменения (дополнения) и потом уже принять изменения...

Всё приблизительно так и организовано, за некоторыми нюансами. Зачем я буду грузить вас организационными проблемами, если меня интересует техническая?
vmag
Думаю если бы ТС выложил предметную область, хотя бы намеком, все было бы гораздо прозрачнее...

Изыскательские работы.
5 июн 19, 15:46    [21902672]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Мужики, я очень ценю то, что вы мне помогли найти устраивающее меня решение. Я даже уверен, что большинство из вас сможет придумать архитектуру базы данных эффективнее моей. Но для этого вам надо будет погрузиться на несколько месяцев в эту область, причём в постоянном контакте с опытными специалистами. Боюсь, это не реально, да и никому из вас не нужно.
5 июн 19, 16:04    [21902701]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
NewBy52
Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?


Делаете в табличке объекта поле - признак блокировки (ID юзера, время или просто битик-взависимотсти от потребностей).
При открытии функционала редактирования объекта - ставите этот признак. Если очередной пользователь пытается открыть окно редактирования залоченного объекта- ругаться и говорить что сейчас другой работает и посылать.
После сохранения данных признак обнулять. Обойтись просто средствами СУБД можно (SELECT FOR UPDATE), но не сможете показать инфу- какой именно юзер заблокировал объект.
6 июн 19, 12:02    [21903335]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Serguei
Делаете в табличке объекта поле - признак блокировки (ID юзера, время или просто битик-взависимотсти от потребностей).
При открытии функционала редактирования объекта - ставите этот признак.

Ну да, и в это время у вас вырубается свет, и всё повисает. Для всех.
Это простое, но неверное решение.
6 июн 19, 14:16    [21903517]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Более того, скажу, лет 30 назад, я, по неопытности, реализовал подобное решение. И, несмотря на то, что юзеров было всего 5, и располагались одни на одном этаже, ну я и помучился!
6 июн 19, 14:20    [21903529]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8927
NewBy52
Serguei
Делаете в табличке объекта поле - признак блокировки (ID юзера, время или просто битик-взависимотсти от потребностей).
При открытии функционала редактирования объекта - ставите этот признак.

Ну да, и в это время у вас вырубается свет, и всё повисает. Для всех.
Это простое, но неверное решение.

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

NewBy52
Более того, скажу, лет 30 назад, я, по неопытности, реализовал подобное решение.

30 лет назад (в 1989 году) Вы реализовывали многопользовательскую клиент-серверную систему? На какой платформе, если не секрет?
6 июн 19, 14:56    [21903600]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Самой большой проблемой было, когда юзер включал коррекцию, и уходил на обед, никого не предупредив.
6 июн 19, 14:57    [21903602]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
NewBy52
Member

Откуда: Воронеж
Сообщений: 24
Btrieve фирмы Novell
6 июн 19, 14:58    [21903604]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
experience
Member

Откуда: Новосибирск
Сообщений: 154
NewBy52
Мужики, я очень ценю то, что вы мне помогли найти устраивающее меня решение. Я даже уверен, что большинство из вас сможет придумать архитектуру базы данных эффективнее моей. Но для этого вам надо будет погрузиться на несколько месяцев в эту область, причём в постоянном контакте с опытными специалистами. Боюсь, это не реально(*), да и никому из вас не нужно(**).


(*) Обсуждая как то электронную историю болезни и мед статистику в ответ на сложно, сложно, очень сложно с улыбкой ответил: вы так считаете потому что не видели электронного уголовного дела и криминальную статистику.
Это я про опытный, но в каждом конкретном случае свежий не замыленный взгляд.

(**) Лето, с работой затишье, а вдруг в качестве маленького суб подряда, ... ???

Почта в профиле, если вдруг...

p.s. И да NetWareSql(Надстройку на упомянутым вами Btrieve) в 92-94 гг прошлого века я официально пару раз покупал и в красных коробках Novell и в серых у Btrieve Technologies.
6 июн 19, 18:49    [21903945]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
experience
Member

Откуда: Новосибирск
Сообщений: 154
Кот Матроскин
30 лет назад (в 1989 году) Вы реализовывали многопользовательскую клиент-серверную систему? На какой платформе, если не секрет?


Вы не поверите, но SQL не главное в клиент - сервер, вот например CICS + NATURAL + ADABAS вполне себе подойдёт.

Ну и проматерь протцов импортозамещения СУБД реляционного типа Рубин это вам не КАРАТ и РЕБУС какие то ))))

Знаком лично, в руках держал, зарплату получал и вполне себе клиент - серверно )))
6 июн 19, 19:18    [21903967]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8927
experience
Кот Матроскин
30 лет назад (в 1989 году) Вы реализовывали многопользовательскую клиент-серверную систему? На какой платформе, если не секрет?


Вы не поверите, но SQL не главное в клиент - сервер, вот например CICS + NATURAL + ADABAS вполне себе подойдёт.

Лучше не надо гадать, во что я поверю или не поверю (хотя бы потому что буковок SQL в моей цитате нет)
6 июн 19, 20:27    [21903998]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
experience
Member

Откуда: Новосибирск
Сообщений: 154
Кот Матроскин,

Автор темы упомянул Btrieve, история которого началась до покупкой Novell в районе 1987 года, так что 30 лет назад вполне себе были и клиенты и сервера и немножко пользователей в многопользовательском режиме.

Наши СМ-1425 Картинка с другого сайта.
под ДЕМОС рассыпались и было очень обидно терять INGRES(РУБИН), а на intel-386-e которые были доступны по деньгам что то UNIX-овое кусалось ценниками не гуманно и где то в районе 92-93 года попалась инфа по NetWare SQL на NetWare Runtime(дешевле существенно), т.е. с одним пользователем для традиционного доступа и много по SPX-SQL. И рантайм ещё и позволял грузить без дисковые 286 Dos машины клиенты.
6 июн 19, 21:11    [21904023]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
NewBy52
Ну да, и в это время у вас вырубается свет, и всё повисает. Для всех.
Это простое, но неверное решение.


Это сказал что зависает все? И почему оно зависает? Для пользователя который начал редактировать все чудесно работает (я обычно Id юзера ставлю в качестве битика). "залоченные" самим собой записи разрешается редактировать. Так что решение ещё какое рабочее.

А случай если есть непутевые юзеры, которые лочат объекты и уходят домой - должна быть админская функция разлочки. Можете аргументированно сказать что здесь не работает?
6 июн 19, 22:26    [21904066]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 780
Serguei
А случай если есть непутевые юзеры, которые лочат объекты и уходят домой - должна быть админская функция разлочки. Можете аргументированно сказать что здесь не работает?

Админов нет. Некому разлочкой заниматься. Предложите решение - при потере коннекта нужный битик сбрасывается в ноль.
7 июн 19, 10:44    [21904284]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
KreatorXXI

Админов нет. Некому разлочкой заниматься. Предложите решение - при потере коннекта нужный битик сбрасывается в ноль.


Ну у меня то в общем то так и есть. При прекращении сессии пользователя, эти все битики удаляются.
Без админов не обойтись в любом случае. Если пользователь залочил и сидит чай пьет... У меня админ рубит и все.
Вариант есть сделать ограничение по времени работы с объектом. Если больше положенного- тоже рубить этот битик. Все зависит от требований. Сделать можно все что угодно под потребности. И это не сложно.
7 июн 19, 12:42    [21904422]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7827
Serguei
Так что решение ещё какое рабочее.

Зачем?
Если 99% процентов СУБД (в том числе MS SQL) умеют команду SELECT FOR UPDATE
7 июн 19, 15:11    [21904614]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58418
Блог
NewBy52
Ну да, и в это время у вас вырубается свет, и всё повисает. Для всех.
Это простое, но неверное решение.

В качестве признака блокировки лично я использую audsid блокирующей сессии. Соответственно, нет никаких проблем с "выключили свет" и прочими страшилками.
7 июн 19, 15:40    [21904645]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
Leonid Kudryavtsev
Если 99% процентов СУБД (в том числе MS SQL) умеют команду SELECT FOR UPDATE

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

Leonid Kudryavtsev
Serguei
Так что решение ещё какое рабочее.

Зачем?
Если 99% процентов СУБД (в том числе MS SQL) умеют команду SELECT FOR UPDATE


В СУБД да есть такой механизм. Но от него можно огрести тоже проблем, когда будут залоченные записи и появится много желающих изменить эти записи.
Я не хотел такой жесткой блокировки, тем более что физически саму запись в таблице объекта я не меняю, а меняю таблицы связанные с ней. И при этом у меня нет Update никогда (исключительные случаи только), есть только insert и все это логгируется в БД. От select for update мы ушли давно. И преимуществ у select for update не вижу никаких.


softwarer
NewBy52
Ну да, и в это время у вас вырубается свет, и всё повисает. Для всех.
Это простое, но неверное решение.

В качестве признака блокировки лично я использую audsid блокирующей сессии. Соответственно, нет никаких проблем с "выключили свет" и прочими страшилками.


Да -такой способ тоже имеет право на жизнь.
7 июн 19, 21:06    [21904941]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 32129
Блог
1) сначала выбрать СУБД, причем выбор должен учитывать знания тех, кто будет реализовывать эту программу (как и цену лицензий и кучу других факторов)
2) выбрать механизм реализации изложенной логики в данной конкретной СУБД

А сейчас автор занимается какой-то фигней.
9 июн 19, 01:57    [21905283]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Gerros
Member

Откуда: Харьков
Сообщений: 429
NewBy52,
В БД у вас лежат некие объекты и связанные с ними результаты каких-то расчётов. Пользователь открывает объект, смотрит результаты расчётов и если не понравилось - меняет параметры расчёта (или объекта), пересчитывает и сохраняет.
Вариант: хранить все результаты расчётов вместе с параметрами для которых выполнялся расчёт.
При открытии объекта показывать пользователю список всех хранящихся результатов расчётов и дать пользователю возможность удалять ненужные.

Простой пример, расчёт массы топлива в баках сложной формы в зависимости от плотности топлива. Открываем объект "Бочка №12" и видим список:
2019-08-26мазут12.34
2019-08-26бензин11.00
2019-08-26мазут313.46
2019-02-25мазут214.00
2019-02-25мазут10.46
1 сен 19, 04:13    [21961372]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 1996
>NewBy52, 3 июн 19, 11:43 [21900247]
>… есть основная таблица r_objects … есть масса вспомогательных таблиц … Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память …
<Поддерживаю Dimitry Sibiryakov. Вопрос касается "широких" сущностей, много атрибутов, разумно растащить их по разным таблицам.
Имею MS SQL и поступаю так:
1. Формирую целостную сущность из многих её частей (у меня всего две) хранимой процедурой.
ALTER PROCEDURE [dbo].[au01_ОбъектыД_Sel] 
  @pk_Entity uniqueidentifier
AS
BEGIN
  SET NOCOUNT ON;
  SELECT TOP(1)
    -- ОбъектыД
    обд.pk_Entity,
    обд.tn_ЧастьОбъ,
    обд.str_Признак,
    обд.fk_ДокВкл,
    . . .
    обд.ts_Entity,

    -- Объекты
    об.pk_Entity,
    об.fk_Дог,
    об.fk_Гос,
    об.str_NameObj,
    об.str_НаимОбъ,
    . . .
    об.str_РегНом,
    об.str_AbbrObj,
    об.str_АббрОбъ,
    об.str_Del,
    об.ts_Entity
  FROM tbl01_ОбъектыД обд
       INNER JOIN tbl01_Документы дв ON обд.fk_ДокВкл=дв.pk_Entity
       INNER JOIN tbl01_Документы дл ON обд.fk_ДокЛик=дл.pk_Entity
       INNER JOIN tbl01_Документы дф ON обд.fk_ДокФакЛик=дл.pk_Entity,
    tbl01_Объекты об
	INNER JOIN tbl01_Государства го ON об.fk_Гос=го.pk_Entity
	INNER JOIN tbl01_Договоры до ON об.fk_Дог=до.pk_Entity 
  WHERE (обд.pk_Entity=@pk_Entity) and (обд.pk_Entity=об.pk_Entity);
END

2. Храню изменения сущности так:
ALTER PROCEDURE [dbo].[au01_ОбъектыД_Upd] 
    -- ОбъектыД
    @pk_EntityД	     uniqueidentifier,
    . . .    
    @ts_EntityД	     timestamp,
    
    -- Объекты
    @pk_Entity	     uniqueidentifier,
    . . .    
    @ts_Entity	     timestamp
AS
BEGIN
  DECLARE @ErrorVar INT;  
  SET NOCOUNT OFF
  BEGIN TRANSACTION
    UPDATE tbl01_ОбъектыД SET
      tn_ЧастьОбъ     = @tn_ЧастьОбъ,
      str_Признак     = @str_Признак,
      fk_ДокВкл       = @fk_ДокВкл,
      . . .
      str_Радиус      = @str_Радиус,
      fl_Площадь      = @fl_Площадь
	WHERE (pk_Entity=@pk_Entity) and (ts_Entity=@ts_Entity)
	SET @ErrorVar=@@error;
	IF (@ErrorVar <> 0) GOTO CORO; --Отменить транзакцию, если есть ошибки
	UPDATE tbl01_Объекты SET
      fk_Дог=@fk_Дог,
      . . .
      str_NameObj=@str_NameObj
	WHERE (pk_Entity=@pk_Entity) and (ts_Entity=@ts_Entity)
	SET @ErrorVar=@@error;

	CORO:
	IF (@ErrorVar <> 0) ROLLBACK; --Отменить транзакцию, если есть ошибки
	ELSE COMMIT;

  SELECT TOP(1)
    -- ОбъектыД
    обд.pk_Entity,
    . . .
    обд.ts_Entity,

    -- Объекты
    об.pk_Entity,
    . . .
    об.ts_Entity,
    @ErrorVar as rc
  FROM tbl01_ОбъектыД обд
    INNER JOIN tbl01_Документы дв ON обд.fk_ДокВкл=дв.pk_Entity
    INNER JOIN tbl01_Документы дл ON обд.fk_ДокЛик=дл.pk_Entity
    INNER JOIN tbl01_Документы дф ON обд.fk_ДокФакЛик=дл.pk_Entity,
    tbl01_Объекты об
	INNER JOIN tbl01_Государства го ON об.fk_Гос=го.pk_Entity
	INNER JOIN tbl01_Договоры до ON об.fk_Дог=до.pk_Entity 
  WHERE (обд.pk_Entity=@pk_Entity) and (обд.pk_Entity=об.pk_Entity);
END

При изменениях всегда получаю текущее состояние сущности в базе данных, если ок - свои изменения, иначе крайние изменения кого-то. Крайний параметр строки выборки @ErrorVar as rc - код ошибки

3. Относительно вопроса "грязного" чтения.
1 сен 19, 12:34    [21961437]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
NewBy52
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных.


В вашем случае проблема пока еще в технологической плоскости, а не в технической. Сначала нужно решить а как все это должно работать, а потом искать техническое решение.
1 сен 19, 12:55    [21961445]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48131

Что за нашествие некроспамеров?

Posted via ActualForum NNTP Server 1.5

1 сен 19, 13:06    [21961450]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
Dimitry Sibiryakov
Что за нашествие некроспамеров?

Поясните, пожалуйста, что вы имели ввиду?
1 сен 19, 13:44    [21961458]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48131

На даты сообщений в топике посмотри.

Posted via ActualForum NNTP Server 1.5

1 сен 19, 13:45    [21961459]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 680
Dimitry Sibiryakov
На даты сообщений в топике посмотри.

3 июн 19 не так уж и давно это было.

Просто для интереса: какой возраст записи для Вас не считается некроманским? 2 недели? )
1 сен 19, 14:56    [21961467]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 1996
>Serguei, сегодня, 14:56 [21961467]
>… какой возраст записи …
<Да не суть, не берите в голову.
Ответа на поставленный вопрос так и нет. В моём варианте пользователь (клиентское приложение) после UPDATE имеет две версии сущности - сущность в базе данных и локальную сущность + код ошибки.
И как далее поступать? И если много изменений?
В настоящее время тупо отражаю сущность базы данных в локальную сущность, отображаю атрибуты в компонентах графического интерфейса и при необходимости сигнализирую об ошибке.
1 сен 19, 15:18    [21961470]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 728
vmag
да и не закрывает совсем...
ну получил я версию объекта после того как отдолбил 1000 параметров в течение двух часов и что?
- я должен понять и принять тот факт, что я два часа долбил зря, передо мной вроде как долбил крутой ?
- или я честно отработал день, а на утро увидел что вчера работал зря, мои труды потерли...
- а может у меня пусть 10 % но более правильная информация, которая ушла в никуда... ?
ИМХО тут блокировки и и всякие версии не сработают на все 100 ...

посмотрите, как в википедии сделано
1 сен 19, 18:26    [21961515]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
L_argo
Member

Откуда:
Сообщений: 889
полудух
посмотрите, как в википедии сделано
А чо туда смотреть ?
Сабж необходимо реализовывать исходя из логики задачи.
Чтобы новые данные не пропадали - ввести понятие данных-кандидатов. Т.е. разновидность черновика. Если там есть непротиворечивые ценные данные - после верификации поместить их в продакшн-данные. Сразу или спустя некот. время - зависит только от Б/Л.
Это чисто бизнес-логический процесс, кот. можно реализовать хоть в DBF, хоть в тхт-файлах.

Непонятно, зачем постить сюда портянки кода и умно рассуждать о блокировках в БД.
1 сен 19, 21:14    [21961548]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 728
L_argo
А чо туда смотреть ?

чтобы увидеть там всё то, что вы ниже описали Картинка с другого сайта.
1 сен 19, 22:53    [21961572]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ldfanate
Member

Откуда:
Сообщений: 129
Кот Матроскин
NewBy52
Более того, скажу, лет 30 назад, я, по неопытности, реализовал подобное решение.

30 лет назад (в 1989 году) Вы реализовывали многопользовательскую клиент-серверную систему? На какой платформе, если не секрет?


А что смущает? Древние фокспро 2.6 и клиппер 5 (что ещё тогда модно было - Кларион какойто досовский емнип) вполне позволяли реализовывать совместный доступ к СУБД, представляющей собой набор файловых dbf и cdx файлов на общей сетевой шаре. Доводилось немного сопровождать такие решения, доставшиеся от старших товарищей. Вполне достойно работали по тем временам.

И кстати, кое в чём могли поспорить с современными графическими "интерфейсами", - темп ввода в экранные формы, несмотря на отсутствие мышки, был вцелом я бы сказалвыше. Т.к. выбор в поле ввода из справочника обычно вешали на F-клавиши, навигация по полям ввода - enter-ом (а не уродским Табом, который ну совсем в неудобном углу клавиатуры), выбор (выделение) позиций грида для массовой обработки - обычно пробелом или Ins (который сразу сдвигал курсор вниз на 1 запись). Никто эргономически-уродские решения с галочками, в которые нужно целиться мышью, махая клешнями то на мышь то на клавиатуру (и постраничным листанием гридов) не применял (и даже не снил себе в кошмарном сне :).
Так что всё норм было на рубеже 80-90ых. И даже встроенный интерпретатор с отладчиком прямо в откомпиленную софтину клиптцер по крайней мере умел прилепливать, очень помогало в отладке-трассировке тяжёлых случаев.
2 сен 19, 09:56    [21961653]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 1996
>NewBy52, 3 июн 19, 14:01 [21900485]
>...Потому что многие записи расчетные…
<Мне не приходилось хранить 2000+ расчетных данных в "лоб". Имею дело с географическими объектами (сущностями) не точечного размера. Граница сущности задаётся вершинами многоугольника, кругом, эллипсом, сегментом. Число точек границы не более 20(пока). Для пробы не стал записывать параметры границы по точечно в дополнительную таблицу базы данных - сериализовал значения в byte[] и записал одним полем в запись базовой таблицы сущности. Думаю, что тоже самое можно сделать и с 2000+.
Если данных очень много, то аппроксимация сплайнами, но это уже другая задача.
2 сен 19, 16:21    [21962022]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
L.Otujktd
Member

Откуда:
Сообщений: 63
NewBy52
Добрый день!
Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном.
Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту.
Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.)
После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?

Насколько это будет быстро работать? По сабжу я бы делал третью базу в которую бы хранил только изменения конкретных записей и конфликты, если они будут возникать на уровне строк. А что требуется получить на выходе-то?
2 сен 19, 21:59    [21962171]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ёёёёё
Member

Откуда:
Сообщений: 688
NewBy52
Добрый день!
Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном.
Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту.
Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.)
После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?

У меня есть что-то похожее.

Сделано следующим образом.
Дерево отображается так, как будто юзер работает один, не обращая внимания на других юзеров. Данные из базы в дерево грузятся не сразу, а через кэш. Кэш - небольшой, на пару экранов. Что это дает. При изменении данных одним из юзеров все заинтересованные получают извещение об изменении. Получив сообщение, клиентская часть сбрасывает кэш и выполняет команду перерисовать видимую часть дерева. В результате в кэш из базы подтягиваются свежие данные.
При этом, измененные элементы сразу отображаются. Удаленные элементы отображаются как пустые строки, поэтому на экране ничего не "прыгает". Добавленные элементы не видны, за исключением случая, когда они добавлены во вложенные свернутые уровни, при этом меняется иконка уровня (появляется "крестик" - значит, внутри что-то есть). А также подсвечивается кнопка "обновить", по которой можно заново перестроить дерево и увидеть все, что появилось.
Схема прижилась и работает уже больше 10 лет. Ничего не тормозит, но нагрузка не очень велика - до полутора сотни одновременно работающих юзеров.
Вот, на картинка синим подсвечена строчка, удаленная другим юзером.

К сообщению приложен файл. Размер - 16Kb
3 сен 19, 10:08    [21962266]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Проектирование БД Ответить