dbdoug at gmail.com
Tue May 1 13:17:25 CDT 2018
I've build time tracking databases both ways - either using the normalized
simple 'atomic' time records, or by using pay period based records. I don't
know which to recommend. All I know is that, as soon as you use pay period
based records, you will be asked to build reports by date range, not pay
period range, but as soon as you use the simple records, you'll need to
build screens and reports based on pay periods. Basically, you're going to
have to write code to convert one type to the other and back, no matter
what - take your pick!
On Mon, Apr 30, 2018 at 6:54 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
> At times, there are valid reasons for NOT normalising or for re-thinking
> what you actual mean
> by nromalisation.
> This is one of them.
> Think in terms of a TYPE or Object called a "PayPeriod" rather than "Day"
> and D1Hours to
> D14Hours become separate attributes, not separate entities. :)
> I've built systems exactly like this in the past and in fact I'm doing
> another one right now.
> I doubt that there will ever be a fortnight with more or less days. :)
> If they decide to change to a different pay period, (weekly or monthly?)
> how you store daily
> attendance hours will be the least of your worries.
> On 30 Apr 2018 at 11:30, Bob Heygood wrote:
> > Rocky & Jim,
> > Yes I knew intuitively that I was breaking some normalization rules.
> > Just started to let the UI interface drive the schema.
> > For data entry the user insists on being able to "tab" through a whole
> > pay period (2 weeks) for each employee and job.
> > So, how do I use a table with only one record per day?
> > UNBOUND, I guess. And then via code stuff into a "proper"
> > table........ I have done so before but a lot work.
> > Really don't need any other fields.
> > Thanks for responding,
> > Bob
> AccessD mailing list
> AccessD at databaseadvisors.com
> Website: http://www.databaseadvisors.com
More information about the AccessD