- Introduction
- Important Instructions
- Requirements
- Database
- Tables
- change_log
- data_absence
- data_booking
- data_custom_shift
- data_employee
- data_employee_access
- data_employment_period
- data_fixed_shift
- data_group
- data_group_access
- data_holiday
- data_individual_working_time
- data_leave_ban
- data_leave_entitlement
- data_leave_type
- data_membership
- data_modified_shift
- data_note
- data_overtime
- data_shift_cycle
- data_shift_cycle_assignment
- data_shift_cycle_element
- data_shift_cycle_exception
- data_shift_requirement
- data_shift_type
- data_shift_type_restriction
- data_special_period
- data_special_shift_requirement
- data_special_weekday_requirement
- data_surcharge_type
- data_user_setting
- data_user_specification
- data_working_time_model
- data_workplace
- Tables
Important Instructions
If you are hosting a schedule database yourself, please be sure to note the following:
General Information
Make sure that all current security updates are always installed on your database server.
You are responsible for data backups.
Regularly create a backup of the database and store it in a secure location outside the database server.
You are also responsible for protecting the schedule database from unauthorized access (e.g., through appropriate settings in the database server's firewall).
Migration from the Schichtplaner Cloud
If a schedule was initially created in the Schichtplaner cloud, you cannot directly move the associated database to your own database server.
To move, you must proceed as follows:
- In the Schichtplaner Windows application (currently available in German only), open the shift schedule you want to move and create a data backup.
- Create a new, self-hosted schedule.
- Open the self-hosted schedule and restore the data backup you created in step 1.
- If the restore was successful, you can delete your previous schedule in the Schichtplaner cloud.
Changes to the Schedule Database
For performance reasons, the Schichtplaner application uses special techniques for data querying.
To prevent users from working with inconsistent data, you should therefore only perform the following actions in exceptional cases:
- Deleting records: Instead, mark a record as deleted by entering the value 1 in the deleted column (and the value NULL in any set_null_on_delete column).
- To change a foreign key in a record (for example, for a shift exchange): Instead, mark the record as deleted and create a new record with the changed foreign key.
If you still wish to perform the aforementioned actions, for example to reduce the size of the database, the following procedure is recommended:
Deactivate the schedule.
This prevents any user from opening the schedule or making changes.
Make deletions or changes.
Mark the schedule as purged.
Reactivate the schedule.
Users who had the schedule open must then reopen it.