Theatre Seat booking and Data Structure?

Question

Was wondering what would be the most effcient in memory data strucuture would be for a Theater seating plan and rendering that in a graphical form on screen for the user.

This came up as a converstation at work as we are looking at booking systems and there is a type of booking that we need to cater for that is outside of the rest of the type of booking that we need to do.

So - take for granted that the data is a database and that is the persitant store. The discussion is based on the need to efficient display this on screen as a coherant seating plan and record the state of the seat after payment for that seat within the organisation.

300+ in company user environment with the need for Public webSite for self booking.

Concurrency would be catered for in the website side - like checking the current state and timeout if reservation not continued or payment failed.

Scenario

So a customer calls the agent loads the seating plan. The page gets the information form the database and then draws the state of each seat according to the plan on screen. After some discussion about what is available the customer askes to book and pay for j56,j57,j58.

Looks like some form of Array made of Bytes, if drawn each time. ? Would this be efficient?

Alternatives looking at is static WPF app with these seating plan already and populating that from the data.

But thought that I would ask here just for sanity.

Rules.

• The main plan is 26 rows of 100 seats
• Each row is alphabetical
• Each set is sequential from 1 through to 100
• The seat has the following states
  • Empty
  • Reserved Not paid
  • Reserved Not paid by member
  • Paid
  • Paid member rate

Answer 1

Just have an array, where each cell represents a seat.

For example, you could have a 26x100 array.

Then simply have each cell value of the array set to the status of the seat, you can even add in your own type for a 'hidden' seat (IE a seat that cannot be booked, so you can have a jagged arrangement of seats).

Simple example:

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

Empty layout:

    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

Partially full layout:

    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

If you are wanting to store this in a database, you would have three tables:

tbl_Theatre
tbl_Shows
tbl_TheatreShowSeats

Answer 2

Taking Tom's answer and extending it a bit. Maybe two arrays as we are doing two jobs here.

Use a bit array for availablity and a decimal array for payments. The bit array can be computed on the fly from the payment array and the standard layout.

You can sum the payment array to get total takings as well.

bool? IsAvailable

• null: for hidden (not a seat here)
• false: for unavailable
• true: for available

Separate array for payments

• null: no payments/reservations
• 0: reserved but not paid for
• 29.99 : amount paid in £/$ (std rate)
• 9.99 : amount paid in £/$ (memberrate)

Answer 3

You are only dealing with 2600 seats?

Seems to me like a waste of time worrying about saving so few bytes in memory. It's not like you are representing a stadium with 100k seats.

Why not just represent every seat with a class, and get the job done?

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
}