![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Продажа билетов несколькими кассирами [D7, MSSQL]
alabama01 © (2006-09-26 07:09:00)Здравствуйте.
Есть программа для продажи билетов в транспортные средства, с соответсвующей БД. При продаже билета на форме кассира обновляется combobox со списком свободных мест и автоматически подставляется первое свободное место. (сделано для скорости). При работе нескольких кассиров, у них у всех происходит то же самое. Поэтому приходится проверять не продал ли кто билет на это место, а если продал, то выводить предупреждение, чтобы выбирали другое место. Это очень неудобно. Обновление combobox'ов у всехкассиров происходит при оформлении чека любымиз кассиров Вопрос: как лучше организовать раздачу свободных мест при продаже на один и тот же рейс несколькими кассирами без малейшей возможности продажи двух и более билетов на одно место?
evvcom (2006-09-26 11:33:00) [61]> [15] Бугага © (26.09.06 10:47)
> в том то и фишка подобных систем что классика здесь вряд
> ли подойдет
Обоснуй, а лучше не гони. Придумаешь, что-то принципиально новое? Для этого должна быть поддержка СУБД.
> [8] пропустил, мне тоже понравилось
я не говорю, что понравилось, просто как вариант, далекий от идеального
dr Gonzo (2006-09-26 11:31:00) [62]Сам механизм блокировки реализовать как запись ID билета(номера) в спец-ю таблицу или что хуже простановка атрибута у записи.
Собственно блокировать(пытаться заблокировать) на время оформления по выходу из ComboBox'а. Или если это множественный выбор, то нужно сделать контейнер (типа TListBox'а) для "набивки" заказа билетами из другого списка и делать блокировку при добавлении каждого билета в этот контейнер.
Второй вариант более предпочтителен - т.к. тут более осмысленное действие для кассира.
Все делается за счет 1 ступени блокировки.
Делать сообщения о создании/снятии блокировки. Так же я предложу сделать сообщения более информативными - не просто что то поменялось, а поменялось то то и то то (в идеале снята/поставлена блокировка, ID объекта и т.д. - тогда не нужно будет все время делать Refresh из базы).
Сразу скажу какие минусы у этого способа. Тетя Маша выбрала для заявки 1 - NN билетов, клиент отказался, она ушла пить чай/курить/cпать при этом не закрыв заказ - заказ висит заблокированный, другие пользрователи не могут ничего с этими билетами делать.
atruhin (2006-09-26 11:26:00) [63]> atruhin предлагает, как я понял, лочить когда первый кассир
> выбрал место, но не оформляет билет. В таком случае, что
> делать если этот билет последний и второй кассир хочет его
> продать, а первый пошел покурить?
Во первых административные меры, во вторых для забывчивых, таймер на окно выписки билета, при неактивности кассира, закрывается запись разблокируется.
> Кроме того, у нас свободные билеты хранятся в одном числе
> по битам. Залочить запись проблематично.
А вот тут лучше поменять структуру базы, пока не поздно.
Виталий Панасенко (2006-09-26 11:26:00) [64]А у кассира есть возможность менять номер места ? Или всегда только первый из комбобокса берется ?
Бугага (2006-09-26 10:47:00) [65]в том то и фишка подобных систем что классика здесь вряд ли подойдет.
[8] пропустил, мне тоже понравилось
evvcom (2006-09-26 10:40:00) [66]> [12] Бугага © (26.09.06 10:32)
> т.е. один кассир занял это место, второй тоже, а там кто
> успеет?
Занял - это когда смог обновить запись в базе и распечатать билет. Все остальное - это только мысли занять. Я расписывал классику обновления записей, где вероятность ошибки должна быть сведена к 0. Если же интересует вопрос удобства работы кассиры, это уже другой вопрос. Например, [8] вроде неплохая идея (я тоже не писал такой задачи). А успеть на одно место всегда может только один. Ну прям горец получается :)
Ega23 (2006-09-26 10:35:00) [67]А я бы комбики обновлял не принудительно, а только тогда, когда данный кассир пытается что-то продать.
Бугага (2006-09-26 10:32:00) [68]понял про хранение билетов... а зачем такой гемор?
:)
> Вызываешь это, когда кассир уже покурил и нажал кнопку "Выдать
> билет".
т.е. один кассир занял это место, второй тоже, а там кто успеет?
ЮЮ (2006-09-26 10:31:00) [69]свободные билеты хранятся в одном числе по битам
Это что за средство передвижения такое: маловместимое и с большой конкуренцией на ресурсы? :)
evvcom (2006-09-26 10:30:00) [70]> [7] alabama01 (26.09.06 10:21)
Имеется оптимистический вариант блокирования и пессимистический. Поскольку
> у нас свободные билеты хранятся в одном числе по битам
тебе оптимизм не подойдет. А пессимистический делается так:
select ... from ... where ... for update
Вызываешь это, когда кассир уже покурил и нажал кнопку "Выдать билет". Следом за этим в программном блоке Delphi делаешь проверку, а не изменился ли уже нужный тебе бит, если не изменился, то меняешь и тут же update с коммитом, если изменился - rollback и соответствующее сообщение долго курящему кассиру выдаешь. И пофиг, какой кассир и как долго ходил курить, другим он не помешает.
Бугага (2006-09-26 10:29:00) [71]
> Вопрос когда лочить
Лочим при начале оформления.
Насчет
> если этот билет последний и второй кассир хочет его продать,
> а первый пошел покурить?
административные меры
> Кроме того, у нас свободные билеты хранятся в одном числе
> по битам. Залочить запись проблематично.
не понял. конец рабочего дня дает знать...
ЮЮ (2006-09-26 10:29:00) [72]Я бы разделил операции на
"забронировать для оформления" N мест
"выбрать N мест"
"оформление билетов на выбранные места"
Ибо, сначала покупатель говорит : Мне 3 билета на рейс ХХХ
Затем отдает документы, из когорых становится ясно, что нужен 1 бзрослый и 2 детских места, выясняется в каком вагоне(классе, ряду) нужно место
Вносится информация из документов, печатаются билеты, производится оплата.
Первая операция позволяет сразу сказать есть нужное количество мест или нет. Выполняется без блокировки. Может сказать "Извините", если мест "на лету" стало меньше. Не требует много времени кассира
Вторая выполняется в порядке поступления блокировок. Тоже не требует много времени у кассира. Но надо разлуривать "уснувшего" кассира.
Третья, самая длительная по времени, выполняется в уже комфортных условиях, когда никто тебя уже не торопит и все определились с местами.
З.Ы. Сам таких систем не писал. Как работают реально действующие - не представляю. Так что, извиняйте :)
alabama01 (2006-09-26 10:21:00) [73]
> Бугага © (26.09.06 07:15) [1]
Пока так и есть. Если запись залочена, то второму кассиру выводим сообщение, и он выбирает другое место. Вопрос когда лочить.
atruhin предлагает, как я понял, лочить когда первый кассир выбрал место, но не оформляет билет. В таком случае, что делать если этот билет последний и второй кассир хочет его продать, а первый пошел покурить?
Кроме того, у нас свободные билеты хранятся в одном числе по битам. Залочить запись проблематично.
Бугага (2006-09-26 09:59:00) [74]> И в каких только таких "терминов" нахватался? :)
Архангельский? :)
atruhin (2006-09-26 09:46:00) [75]С MSSQL не работал, а в FB можно при выборе места делать холостой апдейт, после чего данная запись будет заблокированна, для второго кассира, простым перебором ищем незаблокированные записи, + event на блокировку для синхронизации конецформыначалоформыcombobox'ов.
При закрытии пргораммы, обрыве коннекта, транзакция через некоторое время (настраивается) откатывается и запись разблокируется.
Думаю в MSSQL есть что то подобное.
evvcom (2006-09-26 09:05:00) [76]> [3] ЮЮ © (26.09.06 09:02)
Ну дай ему орлом себя почувствовать... :-o)
ЮЮ (2006-09-26 09:02:00) [77]
> vodvorezlaya (26.09.06 08:22) [2]
Уже книжек начитался, гляжу :) И в каких только таких "терминов" нахватался? :)
vodvorezlaya (2006-09-26 08:22:00) [78]1.Сделать столбик базы данных уникальным, и ловить исключение.
2.Сделать поле ключевым, и ловить исключение либо делать поиск FindKey;
Бугага (2006-09-26 07:15:00) [79]Первый выбирает место, лочит, пытается зарегистрировать билет. Пока он его регистрирует, место залочено. Регистрация успешна? -> место ушло, не успешна -> место разлочено