Please direct all responses to the list, not to me directly. Thanks.
On Tue, 22 Feb 2005, Dermot Paikkos wrote:
> More likely it's me that's confused...
>
> Perhaps I didn't give all the details in the earlier mail. The user
> will only enter their surname. The script would then search the file
> for a match. For those odd souls how share a common surname they
> would have to select their firstname. I would then use the ID for all
> other references to that user which would avoid having to ask them
> again if they which Chris Devers or Christine Devers.
>
> The actual program is a clock-in system for the staff which I want to
> do in mod_perl. I thought a DBM file would be the fastest way to
> access the user list. I need to check that the user is in the list
> before I add their clock-in time to their own 'private' flat file
> which records the time they started, go to lunch ..etc.
>
> From what [you're] saying I am not going to get a massive performance
> boost by using a DBM file. Should I just stick to using a flat file
> and extend it as you say?
I don't think I said anything about performance differences, as I don't
know enough about your code to indulge in such speculation. But, that
said, the whole point of database access mechanisms like DBM is to make
lookups faster by generating indexes into the data, so as a general
rule, yeah, DBM / DBI / etc code should be faster than lookups against
flat files.
With small data sets though, as in the 50 record set you're talking
about, the performance probably won't be a big deal either way, which
was why I suggested extending your current scheme rather than rewriting
everything with a proper DB{I,M} access layer. The only way to know for
sure is to write it both ways and benchmark it, but my hunch is that for
50 records, there won't be much difference.
Not that writing DBM/DBI code is very difficult, but if the code you
have already works, it isn't necessary to rewrite it.
As for access controls, my impression is that an employee timeclock
system is one that's worth protecting against abuse. As an example, you
probably don't want people to maliciously or accidentally make changes
for other people's timesheets, as that would create all kinds of issues.
One easy & effective approach to this might be to let Apache do as much
of the authentication work as possible: set up Apache-level password
controls to the punchclock site, and give each employee a username and
password for this site. When they log in, the username will be available
as an environment variable that you can use for maintaining records, and
you can be reasonably sure that people aren't logging in as each other.
Make sense?
--
Chris Devers
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
