数据库设计选择

Question

I'm trying to create a work schedule creator with multiple stores and each store with multiple employees. Each store can also access past schedule created, but only the current schedule is modifiable. The way I have my SQL database setup is that I have two tables, stores and employees. Each employee has a store they work for, and time for all the days of the week, so I saved employees from all the stores in one table and get them as necessary with queries.

My question is, should I add another column (week) to the employee table to designate which week that schedule is for, or create a new html file for each schedule for that store's past schedules? I like the second choice because it decreases the chances of my SQL database being corrupted. As past schedules are unmodifiable, I have no issues with it.

PS just to make sure: if i write to a file using php, say $name = "monir"; write("My name is $name") $name = "monir"; write("My name is $name") . Will the file say "My name is $name" or "My name is monir" ?

Answer 1

Following the concept of Database normalization you should add another table called eg schedule which contains a reference to an employee and a store. In addition to that you should put your week number in this schedule table to uniquely identity your table row.

Answer 2

My questions is should I add another column (week) to the employee table

I would suggest creating a schedules table. Employees would then belong to the schedule and the schedule would belong to a store. This provides more flexibility and allows you to better store past schedules.

I like the second choice because it decreases the chances of my SQL database being corrupted.

You don't want to avoid a dynamic solution (table) in favor of a static one (html page) simply to prevent users from updating information. You simply need to create access rules in your application.

Answer 3

You should have store, employee and a table that joins the stores and employees as stores and employees do NOT have a one-to_one relationship. Everyone I have ever known who worked in retail has had times when they were asked to work at other stores.

Schedule should be in a separate table with the employee id, the week and the scheduled hours. A trigger should be put on this table to prevent schedules from past dates from being updated. Alternatively you could have a view that exposes only the current schedule and future schedules and make all updates use the view but selects can use the whole table. This would allow a database admin to change the past schedules if need be but not the application since it only uses the view.

Answer 4

As the comments made by DA and the other solutions indicate, having a third table is the way to go. At a minimum, try having the following:

store: id | name | address | etc.

employee: id | first_name | last_name | etc.

schedule: id | store_id | employee_id | week | date | start_time | end_time

While week is redundant since date is stored, it allows you to query much faster. You don't need the archive/past bit because you can just query whether schedule.week is the current week or not.

Answer 5

I've actually just done something quite similar, but our system is a whole hell of a lot more complicated than this.

Personally, given your present structure, I'd choose to add the extra column. It's not too much more work, and will give you the ability to reproduce the HTML files after the fact. I know you don't want to be able to modify past schedules, but that's more what I'd call business logic - so just prevent it from being possible somewhere in your code.

I'd have otherwise suggested you add another extra table for "weeks". Give it an ID, the start date and the end date, then use that "week_id" elsewhere to save duplication. You could also separate out schedule entries from employee records, so each employee would have a unique ID and your "schedule" table would be: ID, employee_id, week_id, date, start_time, end_time.

It'd give you a lot more control over your queries and reduce the duplication in the database quite considerably for later on. Also, unless your database is really really unstable, corruption shouldn't be a problem.

For your PS - as long as you surround your output in double-quotes, PHP will interpolate your values. So you'll get "My name is monir", rather than "My name is $name".