Совместное использование одной таблицы

← →
clickmaker © (2006-11-23 11:30) [40]

> когда вводишь строку с товаром, запрошенное количество от
> отстатка минусуется и переводится в резерв (есть несколько
> способов реализации - тута можно поспорить). Далее готовую
> накладную можно либо провести, либо откатить нафиг. В первом
> случае резерв просто минусуется, во втором - резерв приплюсовывается
> обратно к остатку

а как в данном случае разруливается эта ситуация:

> В случае сваливания клиента/сервера "блокированные" записи
> так такими и остануться

← →
Anatoly Podgoretsky © (2006-11-23 11:44) [41]

> clickmaker (23.11.2006 11:30:40) [40]

С трудом разруливается.

← →
clickmaker © (2006-11-23 11:49) [42]

> [41] Anatoly Podgoretsky © (23.11.06 11:44)
> > clickmaker (23.11.2006 11:30:40) [40]
>
> С трудом разруливается.

в таком случае, не понимаю, чем предложенный мной вариант резервирования хуже?
И что все-таки вы имеете в виду под "резервированием"?

← →
ANB © (2006-11-23 12:08) [43]

> в таком случае, не понимаю, чем предложенный мной вариант
> резервирования хуже?

Резервирование несколько глючнее родных блокировок. К тому же я не въезжаю - зачем оно в данном случае нужно - задача стоит :
а) не давать редактировать одну запись одновременно двум юзерам
б) перед редактированием иметь свежие данные.
Это легче и надежнее всего таки на серверных блокировках разрулить.
Случай с резервированием требует наличия "служебных" кнопок для аварийного разрезервирования, что не очень кузяво. (В одной конторе на этой кнопке скорая помощь на иконке была :) )

← →
clickmaker © (2006-11-23 12:11) [44]

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

достаточно некоего сервиса, который сам за этим следить будет

> Это легче и надежнее всего таки на серверных блокировках
> разрулить

а как узнать, кто именно взял запись и держит?

← →
Anatoly Podgoretsky © (2006-11-23 12:12) [45]

> clickmaker (23.11.2006 11:49:42) [42]

Подразумевается только резервирование и ничего больше.

← →
Anatoly Podgoretsky © (2006-11-23 12:45) [46]

> ANB (23.11.2006 12:08:43) [43]

> а) не давать редактировать одну запись одновременно двум юзерам

Не давать расходовать в отрицательную сторону. А не про монопольное использование записи.

← →
ANB © (2006-11-23 13:13) [47]

> а как узнать, кто именно взял запись и держит?

+ юзеровая блокировка - туда можно всю инфу класть. а в простейшем случае эта инфа и не нужна.

← →
Anatoly Podgoretsky © (2006-11-23 13:37) [48]

> ANB © (23.11.06 13:13) [47]

Не пытайся переносить методы и правила Оракла на другие базы.

← →
clickmaker © (2006-11-23 13:39) [49]

> [48] Anatoly Podgoretsky © (23.11.06 13:37)
> > ANB © (23.11.06 13:13) [47]
>
> Не пытайся переносить методы и правила Оракла на другие
> базы

вот и я про то же.
Когда я подобную байду делал, у меня был сначала Sybase, а потом MS SQL. Поэтому хочется как можно более независимых решений

← →
Anatoly Podgoretsky © (2006-11-23 13:43) [50]

> clickmaker (23.11.2006 13:39:49) [49]

Надо бы сначала разобраться с предметной областью, а то мы тут копья ломаем.
Тем более вопрос несколько раз менялся и в первоначальной постановке давно решен.

← →
ANB © (2006-11-23 13:48) [51]

> Поэтому хочется как можно более независимых решений

ИМХО - независимое решение будет одинаково криво для всех серверов. Лучше использовать возможности конкретного сервера.

ИМХО еще имхестее :) Выкинь на фиг мс скл, поставь оракл и наслаждайся :)

← →
Anatoly Podgoretsky © (2006-11-23 13:52) [52]

> ANB (23.11.2006 13:48:51) [51]

А может, ну его нафиг этот Оракл, нам пальцы крутить ни к чему :)

← →
clickmaker © (2006-11-23 14:01) [53]

> [50] Anatoly Podgoretsky © (23.11.06 13:43)
> > clickmaker (23.11.2006 13:39:49) [49]
>
> Надо бы сначала разобраться с предметной областью, а то
> мы тут копья ломаем.

да меня возмутил просто наезд г-на MsGuns.
Ничем не обоснованный, кстати. И без любого намека на конструктивизм. Дескать, "я не знаю, как делать, но так - неправильно"

← →
ANB © (2006-11-23 14:01) [54]

> А может, ну его нафиг этот Оракл, нам пальцы крутить ни
> к чему :)

Не, оракл - это кусок хлеба с маслом. С тех пор, как я на него сел, еще ни разу больше месяца, при необходимости, работу не искал :) И каждый раз находил с повышением зарплаты :)

← →
Anatoly Podgoretsky © (2006-11-23 14:06) [55]

> ANB (23.11.2006 14:01:54) [54]

С этой стороны, я с тобой полностью согласен, но тогда есть еще более масляные куски, например R/2

← →
ANB © (2006-11-23 14:15) [56]

> например R/2

Во, млин. Я такого не слышал даже - чего это ?

← →
MsGuns © (2006-11-23 14:32) [57]

>clickmaker © (23.11.06 14:01) [53]
>да меня возмутил просто наезд г-на MsGuns.
Ничем не обоснованный, кстати. И без любого намека на конструктивизм. Дескать, "я не знаю, как делать, но так - неправильно"

Чем же возмутил ? Если новичок несет ерунду из-за непонимания єлементарных вещей, то "наезды" на него наездами не считаюстя, а если непонимание механизма обмена данными в технологии "клиент-сервер" денонстрирует Мастер, то всем "стоять бояться" ?

Да, знаю. Как и многие здесь. Которые пытаются Вам объяснить, но Вы упорно стоИте на своих "блокировках". И не хотите признать всю чудовищную неуклюжесть своих приемов. Случай с кассирами далеко не самый сложный конфликт, который приходится решать в конкурентных технологиях. Та же система "Опердень" для банков или резервирование в транспорте или гостинницах куда похитрее будет. Однако никаких блокировок в них нет, да и нормальные сиквель-сервера "не знают" ни про какие "блокировки" - это термин из позавчераших локальных технологий.

Если все же обидел, готов принести извинение. Хотя мастерства Вам это вряд ли добавит

← →
clickmaker © (2006-11-23 14:36) [58]

> [57] MsGuns © (23.11.06 14:32)

да что вы прицепились к мастерству. Я значок не просил, могу вернуть.
Мне интересно, чем не устраивает мое решение проблемы? И какие оные есть в "нормальныx сиквель-сервера". И что такое "нормальный сиквель-сервер". Оракл? Ну тогда я правда пас, извините...

← →
ANB © (2006-11-23 14:49) [59]

> система "Опердень" для банков

Да, эт точно. С августа на ней сижу и еще толком не разобрался, как она работает.

← →
clickmaker © (2006-11-23 14:50) [60]

> [59] ANB © (23.11.06 14:49)
>
> > система "Опердень" для банков
>
> Да, эт точно. С августа на ней сижу

а она реально так и называется?

← →
Jeer © (2006-11-23 14:51) [61]

clickmaker © (23.11.06 14:36) [58]

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

И приходится отделять "мух от котлет" - есть вещи связанные с логико-физическим или бизнес-взаимодействием пользователей.
Когда это раскладывается по полочкам - многое проясняется.

Кроме того, сервера СУБД тоже накладывают свое видение этих процессов: есть блокировочники, есть многоверсионники..

← →
Jeer © (2006-11-23 14:52) [62]

> clickmaker © (23.11.06 14:50) [60]

Так и называется:)

Я ее "прошел" в Сбербанке - 5 лет:)

← →
clickmaker © (2006-11-23 15:01) [63]

> [61] Jeer © (23.11.06 14:51)
> clickmaker © (23.11.06 14:36) [58]
>
> Ты не горячись.
> Переход с файл-серверных технологий (а многие из тутошних
> через них прошли) на клиент-серверные технологии не должен
> вслепую сопровождаться переносом таковых из первых во вторые
> - разные это миры, разные

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

← →
Anatoly Podgoretsky © (2006-11-23 15:05) [64]

> ANB (23.11.2006 14:15:56) [56]

Может R3 по памяти говорю, а она иногда подводит.
Мощная система, сталкивался с ней, Оракл в ней на нижнем звене. Зарплаты по Норвегии начинаются с 6000 для свежеиспеченого выпускника ВУЗА, если он хотя умеет в ней формы делать. Система очень известная, одна из мировых систем, для построения многозвенных приложений по низкоскоростным сетям.

← →
Jeer © (2006-11-23 15:20) [65]

R3 у Ingres, DB2 у IBM, кстати за Oracle и MS тоже выпустила бесплатную версию
DB2 Express-C.

← →
Anatoly Podgoretsky © (2006-11-23 15:47) [66]

> Jeer (23.11.2006 15:20:05) [65]

Я не про базу R3, а про систему, базу как раз любую можно использовать, да и базу R3 они не так давно разработали. Я работал (как пользователь) с этой системой, сервер расположен в Копенгагене, канал 64/128 кб, печатать можно на любой принтер, хоть в Китае.
На месте только SDK (200 mb) даже формы на сервере. Время реакции типовое 0,5 секунды от запроса до появление формы. Формы кривые, смотреть страшно. Но интересно сделал один запрос одна форма, делаешь запрос повторно, уже другая форма.
Заведение учетной записи 1000 долларов, изменение формы значительно больше. Каждый филиал должен самостоятельно все оплачивать. Оттуда и информация об зарплате.

← →
Павел Калугин © (2006-11-23 15:58) [67]

> [66] Anatoly Podgoretsky © (23.11.06 15:47)

это про SAP R3?
ну да, это флаг....

← →
Jeer © (2006-11-23 16:32) [68]

> Anatoly Podgoretsky © (23.11.06 15:47) [66]

Я в свое время пытался в Сбербанке что-то подобное внедрить.
Сервера Motorola, OC AIX, у клиента только X Terminal под Windows.
Формы выглядят по разному в зависимости от допуска рабочего места.
Безопасность по максимуму:)

> Павел Калугин (23.11.2006 15:58:07) [67]

Ну вот, как только назвал это, так я и тоже вспомнил. У них есть и своя БД для него SAP DB
Но они не привязаны а БД, чаще всего используется Оракл.
Так если они такие деньги платят разработчику форм, то сколько же они платят тому кто работает с Оракл в этой системе.

Вот тут уже точно масла для хлеба хватит.

> Jeer (23.11.2006 16:32:08) [68]

Не только безопасности, но и разработка делается в одном месте, а сопровождение на местах сводится к нулю, Сумей только установить систему. Часто забывают сообщить ИП адреса серверов, как в моем случае.

>clickmaker © (23.11.06 15:01) [63]
>Вполне рабочий вариант. И он реально работает.

У меня есть несколько систем на парадоксе 3.5 в ДОСе. Все работают до сих пор. И что ?

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

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

НИ ОДИН СЕРВЕР НИКОГДА НИКОГО И НИ О ЧЕМ НЕ ОБЯЗАН УВЕДОМЛЯТЬ.
Ну не для этого он создан ! Это все равно, что если автодорожники задумают ремонт в районе, допустим, Невского, и озадачатся оповестить всех владельцев авто, гостей города, транзитников, а кроме того всех, кто может в это время проехать по этой части города на общественном или ином транспорте как пассажир.
Просто поставьте себя на место автодорожников и Вам примерно будет понятна логика сервера, которому "до фени" проблемы одного конкретного клиента, как бы "крут" он ни был.
Лично для меня очень большую ясность в этом вопросе в свое время внесли книги Востикова и Ковязина. Хотя там речь идет об Interbase, однако соль клиент-серверного подхода к решению конфликтов в "базовых" проблемах изложена ясно и доступно. Советую Вам почитать. Ключевое слово "транзакция".

>Вот MsGuns пришел и разнес меня.

;) Это разве "разнес" ? Видели бы Вы, какую котлету тут делали из меня аксакалы лет 5 назад, когда я с пеной у рта доказывал всем какие они "дураки", что недооценивают парадокс, дибэйз и т.д. ;)))

>Правда, взамен ничего не предложил.

Что можно предложить человеку, упорно мастерящему крылья из песка и алебастра ?

Ох.... Не думал, что такой вопрос может вызвать подобный резонанс.
Читаю вас тут с удовольствием. Как я сказал, я новичек, а тут более-менее опыту прибавляется.
Пришел к выводу, что в данном конкретном случае есть два "простых" выхода. Делать подкачку, обновляя только видимую часть записей с запасом (без кеширования) и обновлять запись перед редактированием. Т.е. когда пользователь открыл запись на редактирование, в форме уже обновленная информация (кстати, а почему "Это ничего Вам не даст в плане актуальности этой самой записи" ? [21]). Ну, а второй выход - не делать вообще ничего. Просто не отображать изменения. Это из простых вариантов.
Осталось решить с чуть более сложными.
Резервирование говорите....
Вообщем если я правильно понял, то все проблемы опять сводятся к одной. Обновить инфу с сервера. Следовательно, нужно решить как это сделать более оптимальным способом.

> DeadMeat (24.11.2006 09:03:12) [72]

> а почему "Это ничего Вам не даст в плане актуальности этой самой записи" ?

Уже пока информация едет с сервера к тебе на компьютер, она может стать неактуальный

> [72] DeadMeat © (24.11.06 09:03)
> Вообщем если я правильно понял, то все проблемы опять сводятся к одной. Обновить инфу с сервера.
Проблема - сделать нормальную реакцию клиентской программы на отлуп сервера по нарушению правил целостности (которые должны быть). Любое обновление теряет актуальность сразу по получении оного. Т.е. снимается только часть (хоть и не малая) проблемы.

> [71] MsGuns © (23.11.06 21:08)

не, ну в упор не понимаю, причем тут транзакция?
У нас есть набор неких объектов (места в зале, список товаров etc).
Мне нужно, что если один человек зарезервировал объект для потенциально длительной операции, другой, с другого рабочего места ДАЖЕ НЕ пытался бы его использовать. А как он может этого не делать, если он не видит текущего статуса объекта? Может попытаться, да, получить отлуп. Но почему бы не упредить его действия? Ведь это лишняя работа, а системы такие, как правило, работают в довольно жестком темпе.
Хорошо, термин "блокировка" я употребил неправильно, потому что он слишком пахнет спецификой СУБД. Ну пусть будет резервирование.
Ну хоть котлету из меня сделайте - не понимаю: каким боком тут транзакции, и в чем именно у меня "непонимание механизма обмена данными в технологии "клиент-сервер"?

> Обновить инфу с сервера.

Сначала обновляешь вместе с блокировкой. И тогда, несмотря на мнение уважаемого Sergey13 © ты можешь быть уверен, что пока юзер чешет репу и пьет чай, глядя на форму редактирования, а потом одним пальцем с длинным ногтем печатаем там изменения - никто эту запись уже не заменит - она блокирована. А если клиентская программа навернется - блокировка снимется сама.

> clickmaker (24.11.2006 10:05:15) [75]

Как раз ты говоришь о блокировке, а не о резервировании. Никто другой не может редактировать и даже читать (термин использовать). А резервирование немного другое, например у на складе есть 10 единиц товара, количество товара не может переходить в минус.
Например первый оператор резервирует за собой 7 единиц, то другие могут получть только 3 и не более, по окончанию операции делается или проводка списания, или возрат резерва.
Оператор должен знать кто зарезервировал и когда.
Операция возврата штатная и может выполняться любым допущеным человеком, в отличии от блокировок она не мешает работе других пользователей, поскольку ничего ни физически, ни логически не блокируется.

> ANB (24.11.2006 10:54:16) [76]

А если клиентская программа навернется - блокировка снимется сама.

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

> [77] Anatoly Podgoretsky © (24.11.06 11:24)

так. Рассмотрим пример. Я кассир. продаю билеты на концерт. У меня на мониторе схема зала с местами. Свободные - белые, проданные черные. Другой кассир выделил, допустим, 3 места и оформляет заказ. Это может занять некоторое время. Это разве не резервирование с его стороны?

Вопрос: как мне узнать на этот период времени, что именно ЭТИ 3 места заняты, и мне даже не стоит щелкать по ним мышкой, чтобы отложить в другой заказ?

Все зависит от того, что считать под блокировкой.

Блокировка сервером кортежа во время транзакции совершенно нормальна, именно так и работают блокировочники.
Если сдохнет приложение, то блокировка автоматически снимется.

Если под блокировкой понимать резервирование некоторого кортежа через изменение спец.поля для длительной работы с этими данными, то это тоже нормальный подход, блокировка (резервирование) снимается оператором в случает отката ( сторнирование) операции.

Короче говоря, надо уточнять какой уровень процессов обсуждается - уровень СУБД или уровень бизнес-процессов.

Пример.
Менеджер работает с клиентом (заказом клиента) и "ведет" его в течение м.б. нескольких дней, месяцев.
В этом случае должно выполняться резервирование (закрепление) клиента за конкретным менеджером. Это можно назвать блокировкой клиента для других менеджеров. Разумеется, здесь нет никакой транзакции в смысле СУБД, а может быть только откат (сторнирование) операции тем же менеджером или главным менеджером.

Как реально выполняется резервирование ?
У клиента X есть метка (поле IDM) - ID менеджера.
Например ID=0 - клиент ни за кем не закреплен и далее по номерам менеджеров.
Менеджер, обрадовавшись клиенту спешит закрепить его за собой.
Открывает форму с клиентами и ищет такового.
В зависимости от реализации процесса могут быть показаны все клиенты или только свободные клиенты.
Предположим реализация такова, что показаны все клиенты и не визуализированы признаки закрепленности.
Менеджер выбирает клиента X и нажимает кнопочку "Закрепить".
Приложение выполняет операцию с SQL командой:
UPDATE CLIENTS SET IDM = 1 WHERE ( ID = X ) AND ( IDM = 0 );

В данном случае, если клиент не занят, то происходит перезапись IDM с 0 на 1, если нет - то и не перезапишет.
По DBErrors приложение извещает менеджера о неудаче, т.е. о занятости клиента.

Прблема зависших блокировок клиента в данном случае может быть решена только административными и логическими методами.

Совместное использование одной таблицы Найти похожие ветки