Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Продажа билетов несколькими кассирами [D7, MSSQL]

Страницы: < 1 2 3 4 >
alabama01 © (2006-09-26 07:09:00)
Здравствуйте.
Есть программа для продажи билетов в транспортные средства, с соответсвующей БД. При продаже билета на форме кассира обновляется combobox со списком свободных мест и автоматически подставляется первое свободное место. (сделано для скорости). При работе нескольких кассиров, у них у всех происходит то же самое. Поэтому приходится проверять не продал ли кто билет на это место, а если продал, то выводить предупреждение, чтобы выбирали другое место. Это очень неудобно. Обновление combobox'ов у всехкассиров происходит при оформлении чека любымиз кассиров Вопрос: как лучше организовать раздачу свободных мест при продаже на один и тот же рейс несколькими кассирами без малейшей возможности продажи двух и более билетов на одно место?

Desdechado (2006-09-27 15:48:00) [41]
> В числе хранятся только свободные места. При продаже все атрибуты,
> включая номер места, id рейсов, кассиров, дата и время продажи, скидки,
> накидки, суммы, фамилии, номера документов и т.д пишутся в таблицу продаж.
Зачем тогда дублировать информацию? Это же лишние проблемы.

MsGuns (2006-09-27 13:26:00) [42]
Все эти "лочания" незаметно превращаются в "глючения".
Прежде чем решать подобные проблемы неплохо хотя б в общих чертах познакомиться с подобными системами. Хотя бы просто поинтересовавшись как функционирует бронирование в гостинницах например у администратора. Или в тех же ж/д кассах.
Ключевое слово - "резервирование" или его варианты.

evvcom (2006-09-27 08:28:00) [43]
> [33] alabama01 (27.09.06 02:28)
> > Если кассиров много будет выдавать билеты на автобус/поезд
> > id, то с битовым подходом занятости мест mesta очень часто
> > не будут совпадать с :old_mesta. Решать, конечно, барину.
> >
>
> Обновление combobox'ов у всех кассиров происходит при
> оформлении чека любым из кассиров

Т.е. сервер асинхронно извещает всех своих подписчиков (кассиров) о проданном месте? Хорошая фича.

Sergey13 (2006-09-27 08:28:00) [44]
> [33] alabama01 (27.09.06 02:28)

> Если писать в таблицу все продажи (одна запись - одна продажа)
> , через год (если не удалять продажи) поиск свободного места
> будет занимать довольно приличное время особенно на слабеньком
> сервере

Придумываешь ты. 100 автобусов в день по 60 человек 365 дней в году = 2190000 записей. Детский лепет при наличии индексов.

alabama01 (2006-09-27 07:42:00) [45]

> atruhin © (27.09.06 05:48) [34]

К сожалению, выбор места требует заказчик. Если бы автоматом, проблем бы не было.

atruhin (2006-09-27 05:48:00) [46]
Во первых сколько ездил на автобусах, ни когда не предлагали выбрать место, т.е. кассир дает билет в нем написано место. Можно основным режимом программы сделать автоматический выбор места, т.е. кассир его вообще не задает и оно на экране не отображается. При нажатии кнопки оплатить, хранимка не сервере ищет первое свободное место и оформляет билет на него. Плюс можно реализовать, что автоматический поиск свободного места будет производится от "хвоста" автобуса, а ручной от "начала" если операция ручного выбора станет очень редкой, можно обойтись оптимистичной блокировкой, т.е. почти ни чего не менять.

alabama01 (2006-09-27 02:28:00) [47]
> ЮЮ © (26.09.06 10:29) [8]

Идея неплохая. Надо обмозговать.

> evvcom © (26.09.06 10:30) [10]

> тебе оптимизм не подойдет. А пессимистический делается так:
>
> select ... from ... where ... for update
> Вызываешь это, когда кассир уже покурил и нажал кнопку "Выдать
> билет". Следом за этим в программном блоке Delphi делаешь
> проверку, а не изменился ли уже нужный тебе бит, если не
> изменился, то меняешь и тут же update с коммитом, если изменился
> - rollback и соответствующее сообщение долго курящему кассиру
> выдаешь. И пофиг, какой кассир и как долго ходил курить,
> другим он не помешает.

Так и так сейчас делается. И, в данном случае, не имеет значения "уснул" ли кассир или он колотит билеты один за другим!

> ЮЮ © (26.09.06 10:31) [11]
> свободные билеты хранятся в одном числе по битам
>
> Это что за средство передвижения такое: маловместимое и
> с большой конкуренцией на ресурсы? :)

Автобусы пригородных сообщений, максимум 60 мест.

> Бугага © (26.09.06 10:32) [12]
> понял про хранение билетов... а зачем такой гемор?

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

> Ega23 © (26.09.06 10:35) [13]
> А я бы комбики обновлял не принудительно, а только тогда,
> когда данный кассир пытается что-то продать

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

> Виталий Панасенко (26.09.06 11:26) [16]
> А у кассира есть возможность менять номер места ? Или всегда
> только первый из комбобокса берется ?

Конечно. Кассир может выбрать любое место из всего диапазона свободных.

> atruhin © (26.09.06 11:26) [17]
> > что делать если этот билет последний и второй кассир хочет
> его продать, а первый пошел покурить?
>
> Во первых административные меры, во вторых для забывчивых,
> таймер на окно выписки билета, при неактивности кассира,
> закрывается запись разблокируется.

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

> dr Gonzo © (26.09.06 11:31) [18]

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

> Desdechado © (26.09.06 11:45) [20]
> хранение в битах - глупость, которая не дает нормально развернуться
> методам реляционной алгебры
> ведь БД - это все-таки реляционный механизм

Думаю, если этого достаточно, почему бы и нет?

>
> ЗЫ кстати, как в таком случае разруливается ситуация с разным
> количеством мест в разных транспортных средствах?

Заполнением нулями соответствующих битов.

> evvcom © (26.09.06 11:56) [23]
> > [21] Val © (26.09.06 11:47)
> Оптимистическая:
> update tab set mesta = :mesta where id = :id and mesta =
> :old_mesta
>
> Если кассиров много будет выдавать билеты на автобус/поезд
> id, то с битовым подходом занятости мест mesta очень часто
> не будут совпадать с :old_mesta. Решать, конечно, барину.
>

> Обновление combobox'ов у всехкассиров происходит при оформлении
> чека любымиз кассиров

> Виталий Панасенко (26.09.06 12:37) [26]
> А нельзя ли кассирам дать диапазон №№ ?

Нельзя. Все продают всё.

> Desdechado © (26.09.06 12:03) [24]

Естественно, такой вариант рассматривался как самый простой и в первую очередь.

> Desdechado © (26.09.06 15:16) [30]

В числе хранятся только свободные места. При продаже все атрибуты, включая номер места, id рейсов, кассиров, дата и время продажи, скидки, накидки, суммы, фамилии, номера документов и т.д пишутся в таблицу продаж.

> ANB © (26.09.06 15:27) [31]
>
> > кстати, если транспортное средство не со сквозной нумерацией
>
> > мест (например, в поезде вагон-место), то биты идут лесом,
>
> > т.к. кол-во вагонов произвольное, да и их номера не всегда
>
> > подряд
>
> дамс. видимо на одной автостанции подобная прога уже стоит.
> Продали мне билет на место номер 7. залезаю в автобус -
> а места с таким номером нету :) Пришлось согнать нафиг
> кондуктора и ехать на ее месте.

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

Sergey13 (2006-09-26 15:28:00) [48]
> [31] ANB © (26.09.06 15:27)

7 - счастливый номер. На нем водитель сидит. 8-)

ANB (2006-09-26 15:27:00) [49]

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

дамс. видимо на одной автостанции подобная прога уже стоит. Продали мне билет на место номер 7. залезаю в автобус - а места с таким номером нету :) Пришлось согнать нафиг кондуктора и ехать на ее месте.

Desdechado (2006-09-26 15:16:00) [50]
в продолжение Desdechado © (26.09.06 12:03) [24]
если нужно будет к проданному билету (месту) прилепить еще что (например, льготу или фамилию), то это как раз очень удобно делается таким подходом
а вот к биту прилепить только перректально
кстати, если транспортное средство не со сквозной нумерацией мест (например, в поезде вагон-место), то биты идут лесом, т.к. кол-во вагонов произвольное, да и их номера не всегда подряд

clickmaker (2006-09-26 14:57:00) [51]

> у нас свободные билеты хранятся в одном числе по битам

32, ну максимум 64 места? Что за транспорт?

Val (2006-09-26 12:46:00) [52]
>[27] evvcom © (26.09.06 12:41)
> Есть, конечно.

спасибо.

evvcom (2006-09-26 12:41:00) [53]
> [24] Desdechado © (26.09.06 12:03)

Ну да, в общем-то согласен. Но если кроме флага "продано/не продано" больше ничего хранить не надо, я бы все ж не стал делать доп.табличку. Имхо.

> [25] Val © (26.09.06 12:16)

Да, так согласен. Кстати,

> [21] Val © (26.09.06 11:47)
> for update - разве есть в MSSQL?

Есть, конечно.

Виталий Панасенко (2006-09-26 12:37:00) [54]
А нельзя ли кассирам дать диапазон №№ ?

Val (2006-09-26 12:16:00) [55]
>[23] evvcom © (26.09.06 11:56)
можно использовать and mesta = :old_mesta не напрямую, а и через функцию, которая возвращает признак что данное место свободно.

Desdechado (2006-09-26 12:03:00) [56]
> А реляционная алгебра... а что из нее здесь нужно? Для количества можно
> использовать, что угодно, поддерживающее достаточную длину
Главное преимущество реляционного подхода - это возможность складировать в столбик то, что часто просится складироваться в отдельных полях строки (или в битах чиста, или в блобе).
Т.е. проданные билеты просто появляются в таблице отдельными строками, а в справочнике транспортного средства хранится его емкость. Непроданные записывать смысла нет. Количество свободных легко считается, их номера тоже легко (про занятые уже не говорю).

evvcom (2006-09-26 11:56:00) [57]
> [21] Val © (26.09.06 11:47)
Оптимистическая:
update tab set mesta = :mesta where id = :id and mesta = :old_mesta
Если кассиров много будет выдавать билеты на автобус/поезд id, то с битовым подходом занятости мест mesta очень часто не будут совпадать с :old_mesta. Решать, конечно, барину.

evvcom (2006-09-26 11:51:00) [58]
> [20] Desdechado © (26.09.06 11:45)

Если достаточно только признака продано/не продано, то вполне нормально, имхо. А реляционная алгебра... а что из нее здесь нужно? Для количества можно использовать, что угодно, поддерживающее достаточную длину, в том числе нуль-байты. Если писать нечто универсальное, а не для автобуса на 30 мест, то кроме блоба что-то больше ничего не приходит в голову.

Val (2006-09-26 11:47:00) [59]
>[10] evvcom © (26.09.06 10:30)
мне кажется - все-таки в данном случае воспользоваться оптимистической блокировкой. чем мешает это поле, поясните?
пока первый кассир курит - место считается свободным, поскольку транзакция не завершена. при оптимистическом подходе у второго кассира получится вставить запись без проблем. первый вернется из курилки попробует закончить операцию - получит отказ и откат, поскольку запись с таким местом в базе уже будет.
for update - разве есть в MSSQL?

Desdechado (2006-09-26 11:45:00) [60]
хранение в битах - глупость, которая не дает нормально развернуться методам реляционной алгебры
ведь БД - это все-таки реляционный механизм

ЗЫ кстати, как в таком случае разруливается ситуация с разным количеством мест в разных транспортных средствах?

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »