> Sergey13 ©   (22.08.11 10:10) [18]

кстати, совсем нет :)
Но в ТЗ было. Сначала так - сделал. Потом так сказали - тоже сделал.
А реально - ни разу похоже и не было таких случаев, судя по логам.


> Cobalt ©   (22.08.11 10:52) [19]

тоже за SELECT FOR UPDATE. И настроить на тайм-аут.
Смотреть - смотри, править - погоди пока поправят или до таймаута.

>Cobalt ©   (22.08.11 10:52) [19]
>Чтобы другой чел, если хочет изменить, знал - что уже кто-то что-то там изменяет (и, возможно, надо сначала томУ пользователю подойти, и попросить не заниматься фигнёй)

А вот с чего бы это двум операторам вздумалось менять одну и ту же запись в базе ? Один и тот же документ вводят (правят) ?

> А вот с чего бы это двум операторам вздумалось менять одну
> и ту же запись в базе ?

Рассчитываем на такое случай.
Приходят периодически N заявок. Сидит оператор и помечает их как принятые им.
Работа такая, принять, подумать в чей это власти сделать, переправить.
В то же время каждый сам может взять к исполнению.

Оператор открыл список поданных, ставит checkbox напротив тех, которые, как он думает, можно отправить одному человеку.
А тот человек не занят, тоже зашел, и берет первую же заявку. т.е. checkbox и принять.
Оператор в это время жмет принять(пока на себя).

Оператору должно выскочить
Заявка такая то уже взята тем-то. Что выбираешь, оставить как есть или взять себе?
Оставить как есть - он и так ему хотел отправить, можно и так.
а может взять себе и направить еще кому-то потом. Пусть 2 человека работают над ней, если ему кажется что тут один полностью не сможет выполнить. (как правило, доступ новому человеку отправляется админам сети и БД).

> А вот с чего бы это двум операторам вздумалось менять одну
> и ту же запись в базе ? Один и тот же документ вводят (правят)


Если вероятность этого существует, то надо закладываться. Практика показывает, что это лучше, чем потом всю логику менять.

> [22] OW ©   (22.08.11 13:02)
> а может взять себе и направить еще кому-то потом. Пусть 2 человека работают над ней

Как то ИМХО это плохо согласуется с одним checkbox-ом. Разве что у checkbox-а градации серого какие то реализованы. 8-)

> А тот человек не занят, тоже зашел, и берет первую же заявку. т.е. checkbox и принять.
> Оператор в это время жмет принять(пока на себя).
Почему бы эту исключительную ситуацию и не обрабатывать как исключительную ситуацию, т.е. по мере возникновения? Зачем кому-то что-то ПОСТОЯННО рассылать, а другому что-то ПОСТОЯННО принимать и анализировать присланное?

>Ega23 ©   (22.08.11 13:04) [23]
>Если вероятность этого существует, то надо закладываться. Практика показывает, что это лучше, чем потом всю логику менять.

Практика показывает, что логику менять все равно приходится. Как не "закладывайся". Ибо нет приема от лома, а защиты от дурака :)
Это к тому, что надо комбинировать алгоритмические методы с административными.

> Практика показывает, что логику менять все равно приходится.


если подложить соломки в потенциально-опасном месте, то переделывать приходится мало. если не подстелить - то много.

Когда-то очень давно, когда я был юн и неопытен, делал одну халтурку. Ну там цены считало, то-сё.
Так вот. Был НДС. В ТЗ был указан. Всё замечательно. Но вот потом выяснилось, что есть ещё и НСП. Который у товара может быть, а может и не быть. И вот в этом магазине (внутри МКАД-а) он 6%, а в ста метрах от него (снаружи МКАДа) - уже 5.5%.
И надо это всё "быстренько" поменять, "ну чё там, ещё один налог добавить".

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

я ничего не понимаю, я делаю заявку - "не могу подключится к БД"

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

Как это выглядит: Табличка
checkbox[1] Текст1
checkbox[2] Текст2
checkbox[3] Текст3

Кнопка "принять"
выбрал пункты, нажал.

> надо комбинировать алгоритмические методы с административными.

это правда. Так дешевле и быстрее. И как-то быстро дисциплинирует :)
но базовую логику как-то выдержать алгоритмическими методами все же надо.

> [27] OW ©   (22.08.11 15:31)
Судя по описанию - это служба поддержки какая то, а это уже маленький документооборотик получается. А это все равно сложнее трех (и даже пяти) чекбоксов. Тут иногда надо документ (заявку) несколько раз туда-сюда пересылать. Я бы и сделал как документ и его пересылки.
И вовсе тут информирования в реальном времени не требуется.
ИМХО.

> Sergey13 ©   (22.08.11 15:55) [29]

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

Второй пункт - тоже самое с номерами телефонов. Выкатывается список, оператор нащелкивает те, которые надо провести, как исправленные. (Есть такое понятие)

Второй оператор нащелкивает другие, как неисправленные,
Третий нащелкивает как требуют перепроверки.

Список с утра у них, под 1 000 строк, получается в результате анализа скриптом формальных параметров
А все люди (хотя иногда сомнения есть :)), могут один и тот же выбрать и там, и там (и там)..
Потому, надо предупредить.

>OW ©   (22.08.11 11:30) [20]
>тоже за SELECT FOR UPDATE. И настроить на тайм-аут.
для этого используются пользовательские блокировки, но никак не приемы, делающие БД однопользовательской

> Кщд   (23.08.11 07:55) [31]

какие это, например?

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

>OW ©   (23.08.11 08:30) [32]
>какие это, например?
какие примеры? for update
какие блокировки? так, пользовательские же)

> sniknik ©   (23.08.11 10:23) [33]

да, так правильно, конечно, наверное..
но как есть - быстрее и проще в реализации.  (торопили, когда дописывалось - уже начали работать вовсю)
Теперь вторую версию будем писать - надо будет подумать над этим.


Кщд   (23.08.11 11:53) [34]

аа..что-то я не о том, наерное туплю.

половина в отпусках, а двое увольняются.. Кто был на месте при этом, на тех и раскидали от них все
6 проектов на 3х разных СУБД..   Ничего не помнишь уже

таблицу искал, которую в другом месте, в другом проекте, другой базе завел - вот был испуг, что все куда-то исчезло вдруг и, причем, совсем без следов :)