| 00:04.35 | *** join/#uphpu bbankes (~bbankes@67-2-207-40.slkc.qwest.net) |
| 00:05.02 | *** join/#uphpu stevecoug (~stevecoug@oalug/member/stevecoug) |
| 00:05.02 | *** mode/#UPHPU [+v stevecoug] by ChanServ |
| 00:05.21 | *** join/#uphpu UtahDave (~boucha@208.186.233.100) |
| 00:05.21 | *** mode/#UPHPU [+o UtahDave] by ChanServ |
| 00:58.22 | *** join/#uphpu clintberry (~clintberr@38.73.150.199) |
| 00:58.22 | *** mode/#UPHPU [+v clintberry] by ChanServ |
| 01:45.43 | *** join/#uphpu itimber (~Adium@ip72-209-186-65.ks.ks.cox.net) |
| 01:45.43 | *** mode/#UPHPU [+v itimber] by ChanServ |
| 01:46.29 | *** join/#uphpu itimber1 (~Adium@ip72-209-186-65.ks.ks.cox.net) |
| 01:48.58 | *** join/#uphpu itimber (~Adium@ip72-209-186-65.ks.ks.cox.net) |
| 01:48.59 | *** mode/#UPHPU [+v itimber] by ChanServ |
| 02:46.08 | *** join/#uphpu zz_cro (~cro@204.228.149.217) |
| 04:15.14 | *** join/#uphpu mgeary_ (~mgeary@107.188.169.107) |
| 04:15.14 | *** mode/#UPHPU [+v mgeary_] by ChanServ |
| 04:33.02 | *** join/#uphpu TuxToaster|work (sid48515@gateway/web/irccloud.com/x-gtuuxgdkabinbiil) |
| 04:49.13 | *** join/#uphpu eggyknap (~jtolley@unaffiliated/eggyknap) |
| 04:49.13 | *** mode/#UPHPU [+v eggyknap] by ChanServ |
| 04:53.14 | *** join/#uphpu mgeary_ (~mgeary@107.188.169.107) |
| 04:53.14 | *** mode/#UPHPU [+v mgeary_] by ChanServ |
| 05:09.45 | *** join/#uphpu mgeary_ (~mgeary@107.188.169.107) |
| 05:09.45 | *** mode/#UPHPU [+v mgeary_] by ChanServ |
| 05:52.19 | *** join/#uphpu stevecoug (~stevecoug@oalug/member/stevecoug) |
| 05:52.19 | *** mode/#UPHPU [+v stevecoug] by ChanServ |
| 06:56.11 | *** join/#uphpu stevecoug (~stevecoug@oalug/member/stevecoug) |
| 06:56.11 | *** mode/#UPHPU [+v stevecoug] by ChanServ |
| 08:05.08 | *** join/#uphpu Tod-Autojoined (Tod@50-198-177-186-static.hfc.comcastbusiness.net) |
| 08:09.56 | *** join/#uphpu Heartsbane_ (tsharpe@unaffiliated/heartsbane) |
| 08:09.56 | *** mode/#UPHPU [+v Heartsbane_] by ChanServ |
| 09:48.40 | *** join/#uphpu kim27 (~kim27@184-155-223-24.cpe.cableone.net) |
| 09:48.40 | *** join/#uphpu kim27 (~kim27@unaffiliated/kim27) |
| 11:24.15 | *** join/#uphpu clintberry (~clintberr@38.73.150.199) |
| 11:24.16 | *** mode/#UPHPU [+v clintberry] by ChanServ |
| 13:49.22 | *** join/#uphpu eggyknap (~jtolley@unaffiliated/eggyknap) |
| 13:49.22 | *** mode/#UPHPU [+v eggyknap] by ChanServ |
| 13:55.00 | *** join/#uphpu josephscott (~josephsco@192.0.65.252) |
| 13:55.00 | *** mode/#UPHPU [+o josephscott] by ChanServ |
| 14:37.59 | *** join/#uphpu bbankes (~bbankes@50-200-100-242-static.hfc.comcastbusiness.net) |
| 15:43.20 | *** join/#uphpu T4rku5 (~T4rku5@unaffiliated/shunkydave) |
| 15:43.37 | *** join/#uphpu supernovia (~Adium@107.188.227.63) |
| 15:51.23 | *** join/#uphpu stevecoug (~stevecoug@oalug/member/stevecoug) |
| 15:51.23 | *** mode/#UPHPU [+v stevecoug] by ChanServ |
| 15:55.52 | *** join/#uphpu eggyknap (~jtolley@unaffiliated/eggyknap) |
| 15:55.52 | *** mode/#UPHPU [+v eggyknap] by ChanServ |
| 16:13.44 | *** join/#uphpu _carbohydrate (~textual@192.150.9.200) |
| 16:28.51 | *** join/#uphpu Heartsbane (tsharpe@unaffiliated/heartsbane) |
| 16:28.51 | *** mode/#UPHPU [+v Heartsbane] by ChanServ |
| 16:40.32 | *** join/#uphpu clintberry (~clintberr@205.197.215.90) |
| 16:40.32 | *** mode/#UPHPU [+v clintberry] by ChanServ |
| 17:11.35 | *** join/#uphpu codeninja-don (~stringham@pub-198-91-58-175.sumofiber.com) |
| 17:14.10 | *** join/#uphpu code-ninja{io} (~stringham@pub-198-91-58-175.sumofiber.com) |
| 17:53.27 | *** join/#uphpu beandog (~beandog@gentoo/developer/beandog) |
| 17:53.27 | *** mode/#UPHPU [+v beandog] by ChanServ |
| 18:10.22 | *** join/#uphpu UtahDave (~boucha@208.186.233.100) |
| 18:10.22 | *** mode/#UPHPU [+o UtahDave] by ChanServ |
| 19:02.50 | *** join/#uphpu kendsnyder (~Adium@68.69.174.66) |
| 19:02.50 | *** mode/#UPHPU [+v kendsnyder] by ChanServ |
| 19:42.16 | unum | I have a database design question, I need to save a default schedule for several hundred employees |
| 19:42.29 | unum | so what time will they come in and what time will they leave each day of the week |
| 19:42.46 | unum | how would you design that table |
| 19:45.04 | romanovic | so, there will be a limited set of work schedules? |
| 19:45.47 | unum | well each employee will have a default schedule |
| 19:45.59 | unum | but I do need a log of that schedule |
| 19:46.08 | unum | but I was planning on keeping that in a seperate table |
| 19:46.29 | romanovic | but there will be a default schedule specified per employee? |
| 19:46.38 | unum | that's actually why I'm working on this, the logging is the new feature |
| 19:46.40 | unum | yes |
| 19:48.43 | romanovic | so, it could be a one-to-one relationship, where the new schedule table has default shift info and a foreign key to the id in the employee table |
| 19:49.02 | *** join/#uphpu _carbohydrate (~textual@192.150.9.200) |
| 19:52.22 | romanovic | i guess that only applies if you can assume the employee works the same shift each weekday. |
| 19:54.00 | unum | well then there's an other table that tracks there schedule for each week |
| 19:54.24 | unum | this one is used to prepopulate the other, when your are talking about 800 part time employees, it gets tricky |
| 19:54.54 | unum | but I found out the reason they wanted it tracked. probably a good feature for the future but I have better solution for the problem at hand |
| 19:55.19 | romanovic | so, each employee may have a different schedule, and each day isn't necessarily the same for each employee? |
| 19:55.47 | unum | correct |
| 19:55.57 | romanovic | you could also have a one-to-many relationship between employees and weekly shifts |
| 19:56.35 | unum | well what I originally did was a one-to-many with days of the week and an in and an out time |
| 19:57.09 | unum | so employee_id,day_id,time_in,time_out where my columns |
| 19:57.20 | unum | and employee_id and day_id are the primary keys |
| 19:57.54 | unum | now I remember why I did it that way |
| 19:58.02 | unum | I think I'm going to have to keep it that way |
| 19:58.07 | romanovic | sounds logical. is there a use case that doesn't cover? |
| 19:58.23 | unum | no just easier to log if I do a one to one |
| 19:58.38 | unum | or atleast query the log in sensible manner |
| 19:58.42 | romanovic | yeah |
| 19:58.57 | unum | but there is a use case the one to one method I was thinking of doesn't cover that I forgot about |
| 19:59.00 | unum | multi shifts a day |
| 19:59.03 | unum | not common |
| 19:59.09 | unum | but happens occasionally |
| 19:59.30 | romanovic | yeah. i had a part time job once with two 2-hr shifts in a day |
| 20:09.41 | *** join/#uphpu SunSparc (~jonathan@c-67-186-238-27.hsd1.ut.comcast.net) |
| 20:09.42 | *** mode/#UPHPU [+v SunSparc] by ChanServ |
| 20:12.12 | *** join/#uphpu _carbohydrate (~textual@192.150.9.200) |
| 20:51.56 | *** join/#uphpu code-ninja{io} (~stringham@pub-198-91-58-175.sumofiber.com) |
| 21:00.42 | unum | so now I have a few things where they want to be able to view old data |
| 21:00.58 | unum | since we're already talking about that case we'll stick with it |
| 21:01.19 | unum | they have a scheduling screen that shows an employees schedule for any given week and their current default schedule |
| 21:01.50 | unum | it has been requested that that screen now show the schedule for any given week and their default schedule as it was at that time |
| 21:02.27 | unum | so I guess the question is do I create a logging table or do I just have one big table |
| 21:03.26 | unum | that query seems like it's going to be a pain |
| 21:03.32 | unum | but I have similiar issues with positions |
| 21:04.17 | unum | I need them to be able to set an effective date for a position and have it dispay data according to what that persons position was at that time |
| 21:13.43 | unum | I got playing this http://envisionutah.org and forgot I asked a question |
| 21:44.19 | romanovic | unum: tough question. if you put it all into one table, it may be more queryable. you could set effective dates on scheduled shifts, such that a query for an employee's current shifts returns all records with her id that have no end date |
| 21:45.49 | romanovic | and historical shifts could be queried with a 'where <somedate> between effective_start and effective_end' clause |
| 21:47.27 | romanovic | any structure that requires more logic to reconstruct the shifts for a given date would make it harder to query |
| 22:11.40 | unum | that makes sense |
| 22:11.52 | unum | I was thinking of just having an effective starting field |
| 22:12.02 | unum | but having an effective ending field as well will make it much easier |
| 22:12.25 | unum | you kind of have duplicated data because your effective ending date will always match with an effective starting date |
| 22:12.39 | unum | but adding that field sure seems to make the whole thing much more mangeable |
| 22:13.01 | unum | and you can always coalesce with todays date in your query |
| 22:13.09 | unum | to handle the null cases |
| 22:13.21 | unum | or handle it with an or is null |
| 22:34.32 | *** join/#uphpu stevecoug (~stevecoug@oalug/member/stevecoug) |
| 22:34.32 | *** mode/#UPHPU [+v stevecoug] by ChanServ |
| 23:44.23 | *** join/#uphpu stevecoug (~stevecoug@oalug/member/stevecoug) |
| 23:44.23 | *** mode/#UPHPU [+v stevecoug] by ChanServ |