Modelling Time Slots in a Database

Question

I need to create a database that has the following requirements:
1. Locations need to have customizable timeslots, to which actions can be assigned.
2. Timeslots are 30 minute intervals
3. Multiple actions can be assigned to single timeslots
I have thought of the following design, but I am unsure if this is the best way to do this. It seems this method would give a lot of redundancy.
In this scheme, everything in caps is a table, * means many, 1 means 1, --- stands for a relationship.
"ACTION" \*---* "TIME_SLOT" ---1 "DAY" ---1 "LOCATION"
Example: A location may have the following timeslots: 25-08-12 8:00-20:00, 26-08-12 10:00-20:00, 28-08-2012 10:00-12:00, 28-08-2012 12:30-20:00
Using my design, this example would:
- give 3 records in DAY for this location.
- give 24 records in TIME_SLOT for the first day
- give 20 records in TIME_SLOT for the second day
- give 19 records in TIME_SLOT for the third day

Answer 1

>
Paulie wrote
>
See my post - one of the ideas I proposed - as it happens our posts overlapped.
>
Not sure what post you are referring to. I don't see ANY post that mentions 48 'columns' in
a table. And the only posts of yours that mention '48' come after mineWe appear to be in different time zones - I meant that our posts overlapped temporally (and conceptually)
After my first post on the 12th, I then went on to propose a Slot table (with the possibility of putting all the slots
for a 24 hour period in the table) - when I posted and refreshed the thread, your post was there - we seemed
to have the same idea at the same time - great minds &c. ;)
1. May 10, 2012 5:44 pm - If timeslots are 30 minutes long then there should be 48 per day.I missed that - or maybe thought that it was just a logical statement, rather than a suggestion of
what should/could be done - there probably should be 48 unless the OP can absolutely
guarantee that there will never be any slots outside the 08:00 - 20:00 window.
In response to my '2. Use Y/N to indicate if the slot is being used.' you ask
>
What is/are the advantage(s)/disadvantage(s) over using a CHECK constraint as I said?
>
A CHECK constraint is a good suggestion. It is easily implemented and understand and self-checking; an exception will be raised if it is violated.All part of the service...
My comments are trying to suggest alternative funtionality: 1) 48 different columns in one row
with a flag to indicate if the column is being used,Do you mean something like ?
CREATE TABLE Slot
  Slot1  Number(2, 1)
  Slot1_Desc  VARCHAR2(50)
  Slot1_Used Boolean
  Slot2
  Slot2_Desc
  Slot48
  Slot48_Desc
);A simplistic interpretation of Normalisation is that tables should
be tall and skinny (a bit like women ;) ) and not short and fat.
I would be very reticent to go down this road - if I've understood you correctly.
2) one varchar2(48) column that is just all 48 flags concatenated
together and 3) a separate 48 record lookup table for the timeslots.Could you provide CREATE TABLE defintions? I'm not sure that I'm grasping what you're getting at.
For #3 you would use a foreign key constraint but for the other two whether you need a
constraint or not depends on the business rule you want to implement.Definitions please - it's easier to visualise the solution with those.
A boolean flag can be implemented in a variety of ways. One way is to assign one value for TRUE
and allow anything else to be considered FALSE (or vice versa). That implements the needed flag
without a constraint and without needing to handle an exception.Yep - got that bit.
In many cases it is a decision about where the organization wants to implement the business rules: in
the database (constraint or trigger) or somewhere in the application code.The longer I'm in this game, the closer I think that any and all logic should be to the database.
Check out Billy's contribution here: Re: Install Questions
and anything by Toons Kopellar.
You said
>
Here I disagree - I think that the timeslot concept is central - as indeed are all of the tables I suggested. The whole
I think that the timeslot concept is central - as indeed are all of the tables I suggested. The whole
point about prototyping is that IMHO every table is important because initially every table has a large effect on
every other table and also, in the event of an upgrade/redesign, the already existing tables are critical - unless
one decides to completely bin the old design - not often an option in the real world unfortunately.
>
Well that is what design discussions are all about - presenting alternative ways of looking at things.Yep - again.
My point is that, as can be seen clearly by the actual table examples you have provided (thank you
for that), is that it is really fairly straightforward to create sample tables and prototypes to experiment
with and see how well they seem to match the requirements. In my experience far too many projects
don't do enough of this.Amen to that.
Considerations for upgrades and redesigns should primarily be considered when the development
team is selecting the final architecture after considering ALL of the viable alternatives.Again, agreed, but post your table definitons. There are some solutions which can be eliminated staight away.
The stage for the current thread is architecture and design. So IMHO it is appropriate to consider
several alternative implementations and create a prototype for each.Agreed yet again.
It is rather trivial to create some INSERT scripts to insert data into the tables you suggested and to
perform some simple update queries and select queries to mimic actual use.That would be the idea - as I think I mentioned in one of my posts to this thread, the OP should be prepared
for plenty of "Doh" moments.
As you indicate the final selection of architecture and implementation will constrain the ability to maintain
the application and add enhancements. That makes it even more important not to cut short the prototype
and analysis phase where alternative designs are considered.Boss: "You start coding, I'll give you the requirements later". I've come pretty close (real life) Boss: "We need a
flight pay system", me: "Ah..." - very much a requirements evolving as coding did - an extreme example of
the iterative model in action.
<balancing TOP-DOWN/BOTTOM-UP approaches snipped - agreed>
Those projects used an iterative process that would result in the least restrictive model that met the requirements.
So I think we are in basic agreement.Indeed, as to the general thrust as to how, ideally, one should design an app, yes.
As OP stated
>
3. Multiple actions can be assigned to single timeslots
>
keeing multiple timeslot indicators in a single record is not applicable for that use case. I was just
trying to illustrate, as you were also, that you need to jot down potential solutions when you think
of them and even do prototype implementations to see how they work.See my "Ooops" post - put multiple Actions into a Project and assign that "Project" a timeslot.
Paul...