Prev: have casting calls for female models in buffalo ny
Next: Models, casting calls
From: Lars Brownies on 22 May 2010 03:09
For monitoring recruitment actions per applicant I need to store about 50
actions per applicant. The activity table would look like:

ApplicantID*
ActivityID*
DateStart
DateEnd

My concerns are:
1. The table would have an enormous amout of records if I had let's say
30,000 applicants.
2. When an new applicant would be added I would have to automatically add
all the 50 action records, otherwise the user would have to pick them
manually. Also some jobs require other applicant actions than others.

A not normalized table would seem easier but would require a table design
change every time there was a new type of action, which is also not
desirable.

How would you deal with such a situation?

Thanks, Lars


From: Mark Andrews on 22 May 2010 08:09
That looks right. Perhaps more fields in the activity table (status of
activity, notes etc...).

The activity table is usually the table with the most records in a CRM
system.

--
Mark Andrews
RPT Software
http://www.rptsoftware.com
http://www.donationmanagementsoftware.com

"Lars Brownies" <Lars(a)Browniew.com> wrote in message
news:ht7vuq$1qgc$1(a)textnews.wanadoo.nl...
> For monitoring recruitment actions per applicant I need to store about 50
> actions per applicant. The activity table would look like:
>
> ApplicantID*
> ActivityID*
> DateStart
> DateEnd
>
> My concerns are:
> 1. The table would have an enormous amout of records if I had let's say
> 30,000 applicants.
> 2. When an new applicant would be added I would have to automatically add
> all the 50 action records, otherwise the user would have to pick them
> manually. Also some jobs require other applicant actions than others.
>
> A not normalized table would seem easier but would require a table design
> change every time there was a new type of action, which is also not
> desirable.
>
> How would you deal with such a situation?
>
> Thanks, Lars
>
>
From: Larry Linson on 22 May 2010 13:32
I do not see a valid reason for pre-populating the Activity Table with a
copy of every possible activity for each applicant, especially as you state
that not all applicants records will need all the activities.

When you add an activity record for an applicant, provide a ComboBox from
which the user can choose the appropriate activity. A ComboBox is ideal,
because with the default AutoExpand option, you can begin typing and it will
automatically scroll the drop-down list -- you don't have to scroll through
all the earlier options to reach the one you want.

You can include VBA code in the AfterUpdate event to validate that the newly
entered record does not duplicate an existing record for that applicant, if
that is appropriate. But, that code can, and should be, sufficiently
"intelligent" to allow the same activity at different dates or times, or in
combination with other distinguishing characteristics.

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access

"Lars Brownies" <Lars(a)Browniew.com> wrote in message
news:ht7vuq$1qgc$1(a)textnews.wanadoo.nl...
> For monitoring recruitment actions per applicant I need to store about 50
> actions per applicant. The activity table would look like:
>
> ApplicantID*
> ActivityID*
> DateStart
> DateEnd
>
> My concerns are:
> 1. The table would have an enormous amout of records if I had let's say
> 30,000 applicants.
> 2. When an new applicant would be added I would have to automatically add
> all the 50 action records, otherwise the user would have to pick them
> manually. Also some jobs require other applicant actions than others.
>
> A not normalized table would seem easier but would require a table design
> change every time there was a new type of action, which is also not
> desirable.
>
> How would you deal with such a situation?
>
> Thanks, Lars
>
>


From: Dan on 22 May 2010 22:24
We have a db with a couple of large tables, but your situation may be
different, so this is just a possibility. Ours we split the db, repathed,
created ACCDE, the front end was copied to all the clients, the back end was
placed on our server. It did take some of the load off of one unit doing all
the work. Again your siutation may be different, but was similar to ours in
having large tables. Just a thought...


Dan


"Lars Brownies" wrote:

> For monitoring recruitment actions per applicant I need to store about 50
> actions per applicant. The activity table would look like:
>
> ApplicantID*
> ActivityID*
> DateStart
> DateEnd
>
> My concerns are:
> 1. The table would have an enormous amout of records if I had let's say
> 30,000 applicants.
> 2. When an new applicant would be added I would have to automatically add
> all the 50 action records, otherwise the user would have to pick them
> manually. Also some jobs require other applicant actions than others.
>
> A not normalized table would seem easier but would require a table design
> change every time there was a new type of action, which is also not
> desirable.
>
> How would you deal with such a situation?
>
> Thanks, Lars
>
>
> .
>
From: Lars Brownies on 23 May 2010 08:11
"Larry Linson" <bouncer(a)localhost.not> schreef in bericht
news:#NOktSd#KHA.5916(a)TK2MSFTNGP04.phx.gbl...
> I do not see a valid reason for pre-populating the Activity Table with a
> copy of every possible activity for each applicant, especially as you
> state that not all applicants records will need all the activities.

Thanks. I thought of it more as a checklist to save users work.

> When you add an activity record for an applicant, provide a ComboBox from
> which the user can choose the appropriate activity. A ComboBox is ideal,
> because with the default AutoExpand option, you can begin typing and it
> will automatically scroll the drop-down list -- you don't have to scroll
> through all the earlier options to reach the one you want.

The activities depend on the job they apply to. Maybe I can offer combo
values depending on the job.

Lars


 |  Next  |  Last
Pages: 1 2
Prev: have casting calls for female models in buffalo ny
Next: Models, casting calls