Separate catalog, capability, and schedule data
A conceptual schema often includes a business, service, staff member, staff-service relationship, schedule rule, schedule exception, customer, and appointment. Keep service descriptions and default duration separate from appointment records. When history matters, snapshot the booked service name and duration so a later catalog edit does not rewrite what was agreed.
The staff-service join represents eligibility: which staff can deliver a service. Schedule rules describe recurring working windows; exceptions capture holidays, breaks, leave, or one-off changes. These are separate concerns, even if a small application stores them in fewer tables.
Example conceptual SQL sketch
The following is illustrative only. It is not the BDS product's schema, and its exact constraints depend on the application and database:
- services(id, business_id, name, duration_minutes, active)
- staff(id, business_id, display_name, active)
- staff_services(staff_id, service_id) — composite key prevents duplicate eligibility rows
- schedule_rules(id, staff_id, weekday, starts_at_local, ends_at_local, timezone)
- schedule_exceptions(id, staff_id, starts_at, ends_at, kind)
- appointments(id, business_id, service_id, staff_id, customer_id, starts_at_utc, ends_at_utc, status)
Availability is derived; the appointment is the reservation
Compute candidate times from opening hours, staff or room schedules, exceptions, service duration, buffers, and existing active appointments. State which resource the booking consumes. Some businesses require both a staff member and a room or piece of equipment to be free.
A browser can display candidate times but must not decide the final write. Revalidate on the trusted server and protect the reservation against simultaneous requests. Fixed non-overlapping slots can use different constraints from variable-length appointments, where interval-overlap checks or serialized writes may be needed.
Model lifecycle, time, and access deliberately
Define appointment state transitions such as requested, confirmed, cancelled, rescheduled, or completed. Decide whether rescheduling is atomic and how the previous slot is released. Keep an audit history if operations require it.
Store instants consistently, commonly as UTC, and retain the business's IANA time-zone identifier for local schedules and display. Test daylight-saving gaps and repeated times. Model customer, staff, and administrator permissions explicitly; authorization belongs in trusted server logic and database policy, not only in the UI.
Turn the model into a project plan
Use the architecture planner to outline entities and requirements, then review the booking software checklist for security, testing, and deployment work. These tools provide planning prompts rather than a substitute for schema review, threat analysis, or requirements validation.
BDS's public product materials describe included services, staff, availability, appointments, administration, and calendar workflows. This conceptual example does not assert that BDS uses these exact table names, constraints, or internal schema. Inspect the delivered source and documentation for those specifics.