Event Booking System: Database Design
When designing a new database, it's important to know before hand how it will be used.  Of course, it's difficult to have perfect knowledge of exactly how your database will be used before hand, because you may be prototyping, your business needs may change over time, etc.

I've found that a good rule of thumb for designing a relational database for a transaction processing system is to assume that each tangible thing your system tracks gets its own table.

Consider the following ERD for your situation:



In your case you have VENUEs that each have one or more STAGEs.  Each stage has many SEATs.  However, note that you want to keep track of PRICEs for seats, so for the sake of sanity in maintaining pricing data, your seats are arranged into SECTIONs.  The price is set at the section level instead of at the individual seat level.  The price also depends on the show time (EVENT) because you might have different prices for different days of the week or different times of day (week day matinee is cheaper than Saturday evening, for example).

You have multiple show times, but there is probably going to be many things common to an event with multiple show times, so you want an EVENT table and a child SHOW table.  This lets you keep show and event (show time) information in third normal form (3NF) which is always a good place to start with a transactional system database.

Assuming that you also want to keep track of who is actually in each seat, you need to have TICKETs and CUSTOMERs in your database as well.

To address your specific question about how to track seats, as rows or as columns, I strongly suggest you track seats as rows.  Relational database management systems like MySQL are built to easily handle rows of data.  If you handle seats as columns, you would probably need a different seat table for each stage, since the seats will be different for each one.  That would make your queries very awkward and complex.  If you are going to use a relational database for your data, then use it the relational way and put things in rows and facts about things in columns.  Your code will be simpler and your life will be better.