Бронирование мест в театре и структура данных?

Question

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

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

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

300 + в пользовательской среде компании, для которой требуется общедоступный веб-сайт для самостоятельного бронирования.

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

Сценарий

Таким образом, клиент звонит агенту, загружает план рассадки.Страница получает информацию из базы данных, а затем рисует состояние каждого места в соответствии с планом на экране.После некоторого обсуждения того, что доступно, клиент просит забронировать и заплатить за j56, j57, j58.

Похоже, какая-то форма массива из байтов, если нарисована каждый раз.?Будет ли это эффективным?

В качестве альтернативы можно посмотреть статическое приложение WPF с уже рассмотренным планом рассадки и заполнить его данными.

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

Правила.

• Основной план - 26 рядов по 100 мест
• Каждыйстрока в алфавитном порядке
• Каждый набор последовательный от 1 до 100
• Место имеет следующие состояния
  • Пусто
  • Зарезервировано Не оплачено
  • Зарезервирован Не оплачен участником
  • Оплачен
  • Оплачен член

Answer 1

Вы имеете дело только с 2600 местами?

Кажется мне бесполезной тратой времени на заботу о сохранении в памяти стольких байтов.Не похоже, что вы представляете стадион на 100 000 мест.

Почему бы просто не представить каждое место с классом и выполнить работу?

public class Seat
{
    public char SeatRow { get; set; }
    public byte SeatNum { get; set; }
    public SeatState State { get; set; }

    public Seat(char row, byte seat, SeatState state)
    {
        this.SeatRow = row;
        this.SeatNum = seat;
        this.State = state;
    }
}
public enum SeatState
{
    Empty,
    ReservedNotPaid,
    ReservedNotPaidMember,
    Paid,
    PaidMemberRate
}

Answer 2

Принимая ответ Тома и немного расширяя его. Может быть, два массива, поскольку мы делаем две работы здесь.

Используйте битовый массив для доступности и десятичный массив для платежей. Битовый массив может быть вычислен на лету из массива платежей и стандартного макета.

Вы также можете суммировать массив платежей, чтобы получить общее количество поступлений.

BOOL? IsAvailable

• ноль : для скрытого (здесь не место)
• false : для недоступных
• true : доступно

Отдельный массив для платежей

• ноль : нет платежей / резервирования
• 0 : зарезервировано, но не оплачено
• 29,99 : сумма, уплаченная в фунтах стерлингов / $ (стандартный курс)
• 9.99 : сумма выплачивается в £ / $ (членство)

Answer 3

Просто есть массив, где каждая ячейка представляет место.

Например, вы можете иметь массив 26x100.

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

Простой пример:

0 = hidden
1 = empty
2 = reserved
3 = paid

Пустой макет:

    FRONT
0 0 1 1 1 0 0
0 1 1 1 1 1 0
1 1 1 1 1 1 1
1 1 1 1 1 1 1
    BACK

Частично полный макет:

    FRONT
0 0 1 1 1 0 0
0 1 2 2 2 3 0
3 3 1 2 2 3 3
1 1 3 3 1 2 2
    BACK

Если вы хотите сохранить это в базе данных, у вас будет три таблицы:

tbl_Theatre
tbl_Shows
tbl_TheatreShowSeats