Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Проектирование БД Ответить