Hotel Management System Source Code Using Python Tkinter And MySQL Database
This project uses Python, CustomTkinter/Tkinter, and a MySQL database to create a desktop-based hotel system that handles authentication, customer records, room management, and reservations in a clean, modern interface.
The application starts from a simple main.py entry point, launches a login form, and then opens the full hotel dashboard after successful authentication.
Watch This Full Demo
1. Application startup and architecture
The application begins in main.py, where a LoginForm object is created and run. The login form is the gateway into the rest of the system. Once the user is authenticated, the login window hides itself and launches a combined application class that merges the dashboard shell with the customer, room, and reservation management modules. That means the final running app is one integrated interface built from multiple mixins instead of several unrelated programs.
Behind the scenes, the architecture is split into clear layers. The DatabaseManager handles connections and queries, the Customer, Room, and Reservation classes represent business entities, and the GUI modules focus on user interaction. This separation is important because it keeps UI logic, database logic, and business logic easier to maintain.
2. Login form
The first form users see is the Login Form. It is built with CustomTkinter and designed as a modern card-style window centered on the screen. The form includes a branded header with the title HOTEL MANAGEMENT, a subtitle System Login, a username field, a password field, a SHOW/HIDE password toggle button, a LOGIN button, and a status label for feedback messages.
From a functionality point of view, the login form validates that both username and password are entered before attempting authentication. If one is missing, it shows an error message. If both are present, it displays a temporary “Logging in.” message, disables the login button, and verifies the credentials through the database manager. On success, it shows “Login successful!” and opens the main hotel system. On failure, it shows “Invalid username or password” and re-enables the button. The form also supports keyboard shortcuts: pressing Enter triggers login, while Ctrl+H toggles password visibility.
An interesting detail is that the file contains a commented-out info panel for default credentials. That means the developer considered exposing starter login information in the UI, but left it disabled in the current version.
3. Database connection and authentication
As soon as the login form is initialized, it creates a DatabaseManager. This class connects to MySQL using the values from the configuration file. If the connection succeeds, it prints a success message and ensures the users table exists. If the table is empty, it automatically inserts a default admin user from configuration.
For security, passwords are not compared as plain text. The system hashes passwords using SHA-256, then checks the username and hashed password against the database. Query execution uses parameterized SQL, which is important for preventing SQL injection. The same manager class also provides helper methods to execute write queries and fetch records as dictionaries, making database interaction much easier throughout the project.
4. Main application shell
After login, the user enters the main application window. This is the core frame that holds the entire hotel system. It includes a top header area, a horizontal navigation bar, and a content area that switches between different pages. The header shows the app name, a subtitle listing the main modules, a signed-in user chip, and a Logout button. The navigation uses pill-style buttons for Dashboard, Customers, Rooms, and Reservations, with active-page highlighting for a more polished experience.
When switching sections, the application clears the old content frame and rebuilds the page for the selected module. This keeps navigation simple and makes the app feel like a single coherent desktop system rather than separate windows glued together.
5. Dashboard
The Dashboard is the first page shown after login. Its role is to provide a quick summary of hotel activity. It displays a title, a subtitle explaining that it offers an overview of rooms, customers, and reservations, and then shows statistics cards. These cards calculate and display values such as Total Rooms, Available Rooms, Occupied Rooms, Customers, and Active Reservations. The values are computed directly from the in-memory room, customer, and reservation objects loaded from the database.
This is a useful design choice because it gives hotel staff an immediate snapshot of system status without requiring them to open each management module individually. Even though the dashboard is visually simple, it acts as the operational summary of the whole application.
6. Customer Management page
The Customer Management module is responsible for maintaining guest records. According to the code, this page supports viewing customers in a table, searching through customer data, adding new customers, editing existing customers, and deleting records. It also preserves the current search text between page changes, which improves usability for staff who are repeatedly moving between modules.
The customer page contains a search area, a results count label, and a scrollable table. The table uses six columns: ID, Name, Email, Phone, Address, and Actions. Search works across all customer fields in a case-insensitive way, and the UI rebuilds the table only after the text actually changes, using a debounced update pattern to avoid refreshing on every keystroke. If no records match, the page shows a clear empty-state message: No customers found.
Add Customer form
Edit Customer form
The Edit Customer form uses the same dialog layout, but it is pre-filled with the selected customer’s information. On submission, the code updates the customer’s name, email, phone, and address in the database, then updates the in-memory object to keep the UI synchronized. After that, it shows a success message and refreshes the table.
Delete Customer confirmation
Deleting a customer is handled through a confirmation dialog titled Delete Customer. The dialog displays the selected customer’s name and ID before removal. This is a good usability feature because it reduces accidental deletions and makes the action explicit.
7. Room Management page
The Room Management page is one of the strongest modules in the project because it combines search, filters, status display, and CRUD operations in one screen. The code explicitly states that this page can display rooms in a searchable and filterable table, add new rooms, edit room details, delete selected rooms, toggle room availability status, filter by status and type, and search by room number, type, status, or price.
The page layout is divided into three main cards: a header card, a filter card, and a table card. The header contains the page title plus action buttons. The filter area lets the user filter by All, Available, or Occupied, choose a room type, and use a search box. The table itself is scrollable and uses the columns Room Number, Type, Price, Status, and Actions. The status column is styled as a colored badge, making it easy to distinguish available rooms from occupied ones at a glance.
The search system is also well thought out. It is debounced, meaning the interface waits briefly before refreshing results while the user types. Filtering can be stacked, so a user can view only occupied suites, or all doubles matching a certain search term, for example. If the filter returns no results, the page shows an empty-state message instead of leaving the table blank.
Add Room form
The Add Room dialog includes fields for Room Number, Room Type, and Price. Validation ensures that the room number is present, unique, that a room type has been selected, and that the price is numeric and greater than zero. If everything is valid, the system inserts the new room into the database with a default status of Available, updates the in-memory room dictionary, shows a success message, and refreshes the room list.
Edit Room form
The Edit Room dialog preloads the room’s current values. Unlike the add form, the room number field is disabled, meaning the room’s identifier cannot be changed after creation. The user can update the room type and price, which is a sensible restriction because room numbers often act as stable keys in hotel systems.
Delete Room confirmation
The Delete Room action opens a confirmation modal showing the room number and room type before deleting it. Once confirmed, the room is removed from MySQL, removed from the in-memory dictionary, the current selection is cleared, and the room list is refreshed.
8. Reservation Management page
The Reservation Management module handles booking logic, which is the most business-critical part of the application. The code lists its major features clearly: viewing reservations in a modern table, filtering by status, sorting by check-in or check-out date, creating new reservations with overlap prevention, cancelling active reservations, deleting cancelled reservations, and automatically updating room status for the current day only.
When the page opens, it defaults to showing All reservations, sorted by Check In in ascending order. The page includes a header card titled Reservation Management, a subtitle explaining that users can create, review, cancel, or delete reservations, and a New Reservation button. Below that is a filter/sort area and then the reservation table.
The reservation table displays the reservation ID, customer name, room number, check-in date, check-out date, total amount, status, and actions. The status is rendered as a colored badge: active reservations appear in a success style, cancelled ones in a danger style, and other states use a neutral look. The actions column is also status-aware: Active reservations show a Cancel button, Cancelled reservations show a Delete button, and other statuses show a dash.
New Reservation form
The New Reservation dialog asks for Reservation ID, Customer, Room, Check In Date, and Check Out Date. The save logic is careful and realistic. It validates that the reservation ID is present and unique, confirms that a customer and room have been selected, ensures the room exists, checks that both dates are provided in YYYY-MM-DD format, and requires the check-out date to be later than the check-in date. It then checks whether the selected room already has an overlapping active reservation. Only if all of those conditions pass will the reservation be created.
The overlap logic is especially important. The code compares date ranges and treats checkout day as non-overlapping, which is correct for hotel bookings because a room can usually be reused on the checkout date after the guest leaves. It only checks active reservations, so cancelled bookings do not block future reservations.
After validation, the system calculates total_amount as the number of nights multiplied by the selected room’s nightly price, inserts the reservation into the database with the status Active, stores it in memory, and updates the room status to Occupied only if the reservation actually includes the current date. That last part is a strong design choice because it separates future bookings from rooms that are physically occupied today.
Cancel Reservation confirmation
Cancelling a reservation opens a confirmation dialog. If confirmed, the database record is updated to Cancelled, the in-memory reservation object is updated too, and the system recalculates whether the room should still be marked Occupied today. If no other active reservation covers the current date, the room becomes Available; otherwise, it stays occupied. This prevents incorrect room status changes when multiple reservation situations exist.
Delete Reservation confirmation
Deleting a reservation is restricted to reservations already marked Cancelled. If the user tries to delete any other status, the system shows an error. For cancelled reservations, it opens a confirmation dialog showing the reservation ID and customer name, warns that the action cannot be undone, then removes the record from both the database and memory before refreshing the page.
9. Data models
The project also uses simple but effective data model classes for Customer, Room, and Reservation. These classes act as in-memory representations of database rows and also provide small helper methods. For example, Room exposes availability helpers, while Reservation provides methods like is_active(), cancel(), and complete(). These model classes make the rest of the application easier to read because the GUI code works with meaningful objects instead of raw tuples or dictionaries everywhere.
10. Database schema
The MySQL schema supports the application cleanly. The customers table stores guest identity and contact fields, the rooms table stores room number, room type, price, and current status, and the reservations table links customers to rooms with dates, amount, and status. Foreign key constraints connect reservations to both customers and rooms, which helps preserve referential integrity. The SQL dump also includes sample records, showing how the application can be preloaded with demo hotel data.
Get the Full Project Source Code
If you enjoyed this project and would like to get the full source code, you can support us by purchasing it for just $5. Your support truly means a lot to us and helps us continue creating more useful, creative, and inspiring projects like this one. Every small contribution helps us keep building, improving, and sharing more with you.
