Forum Moderators: open
Each day's events require 12 shifts to be covered per location (currently 2). That's 372 fields (times at least two), month after month. Currently the company employs less than 100 employees, so we're not talking about a huge volume of transactions, but they will be checking and rearranging their shifts often throughout the month. Shift times are set in stone, and to indicate that a shift is taken, the employee's 5 digit employeeid will be entered into that slot.
So here's my question. Is it better to have that many fields in each table or is it better to have, say 31 fields (one for each day of the monthy) and have shifts for each day separated by a comma, and use PHP to split and read each separate shift.
Btw, mods, if you think this is a question better suited for the PHP section, say so, or move it. Thanks.
Gus
separated by a comma, and use PHP to split and read each separate shift- Don't do it!
No that we go that thought out of the way...
It sounds like you just need to have a few relational tables since it looks like you are trying to keep everything in just one table. At a minimum split up the days, shifts and employees (I'm guessing employees is already) into separate tables and relate them. So each day would have an id that each shift can relate to and each shift can have an id that each employee relates to. That'll keep it small and fast.
JAG
BTW, I never saw a table which would have 3xx fields. Would advise to think over your database structure. Maybe it would be better to split this into few tables.
