Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
к примеру есть накладные в таблице orders Есть много людей, они их меняют, кто как решает эту проблему? у меня только две идеи, первая, для каждого пользователя есть своя таблица рабочая с помощью процедуры выкачивается заказ из order - правится и закачивается назад + быстрое изменение и набитие накладных, минус если он что то изменил то другие не видят пока он не записал изменненую версию в orders, 2 оя - напрямую редактируется orders, что наверное не есть хорошо из за блокировок и безопастности.. кто как выходил из этой проблемы?
7 окт 04, 19:44    [1017312]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Оптимистические блокировки
7 окт 04, 19:49    [1017322]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
на таблицу orders??
8 окт 04, 08:13    [1017630]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
ADO & SQL Server , блокировка записей
8 окт 04, 09:28    [1017748]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
Как блокировка то делается я понимаю, т.е. дать пользователю доступ напрямую править orders???? как то это нехорошо с точки зрения что не всем пользователям не во все дыры лазить нада, или пускай правят вьюхи?
9 окт 04, 11:06    [1021220]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Crimean
Member

Откуда:
Сообщений: 13148
При простом разделении доступа вьюхи - отличный вариант.
Работали бы UDF вменяемо можно было бы вообще с вьюхами и работать.
А так по мере усложнения задачи приходится на хранимки переходить.
9 окт 04, 14:51    [1021331]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
т.е. получается если кто то изменил какую то строчку то придется у всех пользователей re Select делать??
9 окт 04, 17:55    [1021441]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Crimean
Member

Откуда:
Сообщений: 13148
В итоге в любом случае все сделают реселект. Если интересуют вопросы минимизации трафика при этом - это одно. Если интересуют вопросы уведомления операторов о добавлении "интересных" записей - это второе. Если, все же, блокировки - это третье.
Вы бы определились, чего хочется...
9 окт 04, 18:20    [1021449]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
2ое, т.к. к примеру если если заказиков много и селект делается 3 секунды то если добавлять запись и на каждое добавление терять по 3 секудны, как то не очень получается :(
9 окт 04, 19:42    [1021468]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Crimean
Member

Откуда:
Сообщений: 13148
А как связано добавление записей с селектами?
Перечитку можно не делать после каждой вставки.
А можно "дочитывать" только вставленную запись - после удачной вставки ты должен получить с сервера ее Ид...
9 окт 04, 20:09    [1021474]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
к примеру есть таблица Остатки и таблица Заказы, у пользователя на экране есть таблица свободные остатки (склад-заказы), если один резервирует то второй соответственно не должен ее уже видеть!
10 окт 04, 01:04    [1021568]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
к примеру есть таблица Остатки и таблица Заказы, у пользователя на экране есть таблица свободные остатки (склад-заказы), если один резервирует то второй соответственно не должен ее уже видеть!
10 окт 04, 01:04    [1021569]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
к примеру есть таблица Остатки и таблица Заказы, у пользователя на экране есть таблица свободные остатки (склад-заказы), если один резервирует то второй соответственно не должен ее уже видеть!
10 окт 04, 01:04    [1021570]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Константин Заровный
Member

Откуда: Волгодонск
Сообщений: 954
Andrey Filatow

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


Для безопасности можно использовать view и тригера, Через этиже view и редактировать, блокировки можно обойти - так что лучше тот вариант, который ты умееш делать.
10 окт 04, 23:31    [1021934]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
хотелось бы если один сделал заказ то все остальные сразу бы видели что этот товар уже зарезервирован
11 окт 04, 00:03    [1021946]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Константин Заровный
Member

Откуда: Волгодонск
Сообщений: 954
Andrey Filatow
хотелось бы если один сделал заказ то все остальные сразу бы видели что этот товар уже зарезервирован

Так а кто тебе мешает?
Редактируя ORDERS - сразу редактируй статиеские остатки - и будет все так, как ты хочеш.
А реальное положение дел на какой то момент прийдется считать динамически, но это не такая уж и проблемма.

Или я чегото не понимаю?
11 окт 04, 09:47    [1022193]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Latuk
Member

Откуда: N 54°38', E 037°35'
Сообщений: 7312
>то все остальные сразу бы видели что этот товар уже зарезервирован
Для начала необходимо разделить
Первичный документ как таковой
и его действие на учетную систему
Обычно этого добиваются вводя состояния документа
Причем в вашем случае лучше сделать
две первички заявка и накладная
сначала юзер заполняет заявку которая после ее актуализации
(нажатие кнопки зарезервировать) влияет на заполнение других заявок/накладных
А при заполнении накладной может создать ее на основе уже созданной заявки
но только после актуализации накладной (отгружено)
она начинает влиять на складские остатки.
11 окт 04, 09:56    [1022215]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
/ Редактируя ORDERS - сразу редактируй статиеские остатки - и будет все так, как ты хочеш.
А реальное положение дел на какой то момент прийдется считать динамически, но это не такая уж и проблемма.

согласен, в теории все ок, только если к примеру 200 менеджеров, каждый одновременно может делать заказ на одни и те же позиции, ассортимент около 2000 позиций на складе, в средней накладной 4 листа по 40 позиций, если на складе 30 шт какого то наименования и лезут 5 менеджеров и хотят по 20 шт и каждый пообещает их своему клиенту, то в итоге там сума сойти можно. Если при добавлении каждой позиции делать reSELECT по 1-2 сек каждый то чтобы набить накладную в 200 позициий придется минут пять только на reSelect тратить каждому, и в итоге 200 человек по 200 секунд (3.3 минуты) получается что теряется 667 человекоминут (что более 10 человекочасов) только если каждый менеджер по одному заказу сделает, а их на каждого до 20 в день может быть, вот и задачка :)
11 окт 04, 19:39    [1024919]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
trayal
Member

Откуда: Пенза
Сообщений: 471
автор
к примеру есть таблица Остатки и таблица Заказы, у пользователя на экране есть таблица свободные остатки (склад-заказы), если один резервирует то второй соответственно не должен ее уже видеть!

Во-первых, поддерживаю Latuk, что необходимо разделить понятия "заявка" и "накладная".
Во-вторых. У Вас есть поле "остаток товара", который корректируется при работе с товаром в накладных. Есть? Сделайте еще одно поле "свободно", которое будет отражать свободные остатки, и корректируйте это поле при работе с товаром в заявках. Наложите ограничение, что это поле не может быть меньше 0. Тогда при попытке добавить в заявку товара больше, чем свободно, у Вас хотя бы ошибка сгенерится.
Согласен, это не выход. Тогда идем дальше. При добавлении / изменении кол-ва товара в заявке читайте из базы, сколько этого товара свободно, и показывайте юзеру. Таким образом Вы покажете ему свежую информацию о нужном ему товаре, и не будет необходимости делать каждый раз re Select по всем товарам (ему, может, бОльшая часть этой информации и не нужна вовсе).
А если уж юзеру надо, пусть сам инициирует re Select.
Вот, собственно, и все.

С другой стороны, возможно, Вам просто надо оптимизировать выборку свободных остатков. Тогда можно будет и рефрешить после каждой записи.
12 окт 04, 09:19    [1025302]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Константин Заровный
Member

Откуда: Волгодонск
Сообщений: 954
Andrey Filatow
/ Редактируя ORDERS - сразу редактируй статиеские остатки - и будет все так, как ты хочеш.
А реальное положение дел на какой то момент прийдется считать динамически, но это не такая уж и проблемма.

согласен, в теории все ок, только если к примеру 200 менеджеров, каждый одновременно может делать заказ на одни и те же позиции, ассортимент около 2000 позиций на складе, в средней накладной 4 листа по 40 позиций, если на складе 30 шт какого то наименования и лезут 5 менеджеров и хотят по 20 шт и каждый пообещает их своему клиенту, то в итоге там сума сойти можно. Если при добавлении каждой позиции делать reSELECT по 1-2 сек каждый то чтобы набить накладную в 200 позициий придется минут пять только на reSelect тратить каждому, и в итоге 200 человек по 200 секунд (3.3 минуты) получается что теряется 667 человекоминут (что более 10 человекочасов) только если каждый менеджер по одному заказу сделает, а их на каждого до 20 в день может быть, вот и задачка :)


Ладно, допустим это плохо. Тогда как ты предлогаеш?

(А еще если 200 менеджеров то покупай сервер с 200 процами и пусть сервер отдает данные не за 1-2 сек а за 0.1 сек, ну или оптимизируй запрос да и полный Reselect - необязателен)
12 окт 04, 09:47    [1025400]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
ilnev
Member

Откуда:
Сообщений: 52
считывать не остатки,а остатки - заказано
- при входе в редактировании
- при сохранении (+проверка на клиенте)
в заказе(заявке) при сохранении изменять заказано (напр тригером)
Остатки изменять при формировании хранимкой накладной(ых), которая не снизит остатки ниже нуля. При массовой формировке накладных возможно заложить механизмы нарезку дефицита по приоритету заказчика, взаимозаменяемые товары и тп
12 окт 04, 11:32    [1025839]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Andrey Filatow
Member

Откуда:
Сообщений: 399
/Ладно, допустим это плохо. Тогда как ты предлогаеш?

(А еще если 200 менеджеров то покупай сервер с 200 процами и пусть сервер отдает данные не за 1-2 сек а за 0.1 сек, ну или оптимизируй запрос да и полный Reselect - необязателен)


крутой ответ, вообще-то я как раз эту тему то и начал что особых предложений нет :)
12 окт 04, 22:27    [1028225]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
bantik
Member

Откуда:
Сообщений: 288
Ну вообще-то писать систему для 200 пользователей - это уже высокая квалификация. Банковские системы на этом валятся ..
Решения классические
1) Рефакторинг базы данных - например расшивка таблицы Order на несколько объектов - заявка, заказ, позиции и пр. И многостадийная (Workflow обработка)
2) Кеширование наиболее медленно изменяемых справочников на клиенте - текущая дата, пользователь, курсы валют и пр..
3) По иному считать остаток - не Update поля qty в таблице товара, а таблица с приходом/расходом и подсчетом разницы - в таком случае блокировок будет меньше.
4) Зависит от клиента - как делать notification об изменении важных данных - обычно открывается 2-канал на SQL и обратную связь - или TCP/IP на какой нибудь менеджер сообщений.
5) Есть еще проблема семафоров - т.е. сказать пользователю что данная заявка уже обрабатывается - это делается через SELECT ... for UPDATE
6) И еще прикол - лицензионный - на сколько коннектов нужно покупать SQL - для 200 пользователей и нескольких коннектов очень кругленькая сумма получается....

Удачи !
13 окт 04, 09:13    [1028522]     Ответить | Цитировать Сообщить модератору
 Re: вопрос о системах со многими пользователями  [new]
Petr Chulkov
Member

Откуда: Донецк
Сообщений: 540
bantik

6) И еще прикол - лицензионный - на сколько коннектов нужно покупать SQL - для 200 пользователей и нескольких коннектов очень кругленькая сумма получается....


ИМХО на такое кол-во клиентов выгоднее брать для MSSQL не CAL, а per processor лицензии.... хотя согласен, что сумма не маленькая.. хотя если в фирме работает только на оформлении заказа около 200 чел, то для фирмы сумма и не такая уж и большая...
13 окт 04, 11:20    [1029152]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить