Home > Archive > PERL Beginners > February 2005 > DBM file or similar
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
DBM file or similar
|
|
| Dermot Paikkos 2005-02-23, 3:56 am |
| Hi,
I am looking for a way to store firstname/surname/id values in a
file. Currently I am using a flat file to store just the christian
name and surname in the format:
firstname|surname
My problem is that the file is used to gain access a program and the
users enter their surname to access it and there are users (not
surprisingly) that have the same surname. To get around this some
users are getting the surnames changed. I would prefer a more elegant
solution and hoped there was a 3 field DBM file or similar I could
use.
Does anyone know if there is something like this available? I could
continue to use a flat file. There are only 50 users to store and
perhaps it would not be improved by moving to a DBM file.
Thanx.
Dp.
~~
Dermot Paikkos * dermot@sciencephoto.com
Network Administrator @ Science Photo Library
Phone: 0207 432 1100 * Fax: 0207 286 8668
| |
| Mark Rogaski 2005-02-23, 3:56 am |
| Dermot Paikkos <dermot@sciencephoto.co.uk> wrote:
>
> My problem is that the file is used to gain access a program and the
> users enter their surname to access it and there are users (not
> surprisingly) that have the same surname. To get around this some
> users are getting the surnames changed. I would prefer a more elegant
> solution and hoped there was a 3 field DBM file or similar I could
> use.
>
Dermot,
When you say that you want a 3 field DBM, do you want to use 2 fileds as
an index or have 2 fields in the stored value?
If you want a 2 field index, just pick some unique character as a
delimiter and join the names.
dbmopen(%DB, ...);
my $key = join '|', $surname, $firstname;
my $id = $DB{$key};
$DB{$key} = $id;
dbmclose %DB;
Note that you should avoid using "\0" for this purpose since other
programs that use the DBM file may use null termination for the index
strings.
If you want a 2 field stored value, just use the join() for encoding
the value you assign to $DB{$surname}. For more complex data
structures, use Data::Dumper or Storable to marshal the data into a
string that can be stored and to restoree the data retrieved from the
DBM.
Mark
| |
| Wiggins d'Anconia 2005-02-23, 3:56 am |
| Dermot Paikkos wrote:
> Hi,
>
> I am looking for a way to store firstname/surname/id values in a
> file. Currently I am using a flat file to store just the christian
> name and surname in the format:
>
> firstname|surname
>
> My problem is that the file is used to gain access a program and the
> users enter their surname to access it and there are users (not
> surprisingly) that have the same surname. To get around this some
> users are getting the surnames changed. I would prefer a more elegant
> solution and hoped there was a 3 field DBM file or similar I could
> use.
>
> Does anyone know if there is something like this available? I could
> continue to use a flat file. There are only 50 users to store and
> perhaps it would not be improved by moving to a DBM file.
>
> Thanx.
> Dp.
>
> ~~
> Dermot Paikkos * dermot@sciencephoto.com
> Network Administrator @ Science Photo Library
> Phone: 0207 432 1100 * Fax: 0207 286 8668
>
>
You might consider using Storable and just dumping your user database to
disk so that it can be read back in as a Perl structure. Or maybe
XML::Simple to store it as XML, either method will give you an arbitrary
amount of flexibility. Of course any delimited file should work, you
could use Text::CSV for instance. It really comes down to how *you* want
to solve it. DBI and SQLite might be a good choice too, then if you
eventually move to a more robust DB server you shouldn't need to change
your code (much).
Try a few out and see what works best. If you are talking about 50 users
and only 3-10 fields they are all going to be about the same speed wise,
aka really fast.
http://danconia.org
| |
| Chris Devers 2005-02-23, 3:56 am |
| On Tue, 22 Feb 2005, Dermot Paikkos wrote:
> I am looking for a way to store firstname/surname/id values in a
> file. Currently I am using a flat file to store just the christian
> name and surname in the format:
>
> firstname|surname
Sorry, I'm  .
If you're comfortable with this approach, why not just extend it to --
firstname|surname|id
-- or even --
id|firstname|surname
-- ? Isn't that the easiest way?
The "problem" with this approach is that interacting with it gets more
complicated -- users have to keep their ID around so that it's possible
to differentiate between "Chris Devers 42" and "Chris Devers 17". You
can't really get around this though -- assigning ID fields to records is
a theme common to all databases, as it's the only way around the problem
of distinguishing seemingly identical records.
Coding all this up isn't very challenging -- all you have to do is add a
field and hooks to read & write it. The bigger problem is social, not
technical: everyone needs a unique identifier, either a randomly or
sequentially selected ID tag (e.g. id number), or some other token they
select themselves (e.g. account name &/or password). Both have drawbacks
(people don't like having to remember IDs; people don't like passwords)
but one way or the other, this seems like what you have to do.
(Also, I'm assuming that security isn't a consideration here, and that
the biggest problem with people accessing the wrong account is that it's
a nuisance, rather than a real security risk. If people accessing each
other's accounts *is* a problem, then you need to re-evaluate things:
each user needs a password or a similar authentication mechanism, the
user list file needs to be protected & probably encrypted, etc. If, on
the other hand, it's just annoying but nothing is actually harmed by
people using each other's accounts, then the approach you have is fine.)
--
Chris Devers
| |
| Dermot Paikkos 2005-02-23, 3:56 am |
| More likely it's me that's ...
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 your 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?
Dp.
On 22 Feb 2005 at 10:00, Chris Devers wrote:
> On Tue, 22 Feb 2005, Dermot Paikkos wrote:
>
>
> Sorry, I'm .
>
> If you're comfortable with this approach, why not just extend it to --
>
> firstname|surname|id
>
> -- or even --
>
> id|firstname|surname
>
> -- ? Isn't that the easiest way?
>
> The "problem" with this approach is that interacting with it gets more
> complicated -- users have to keep their ID around so that it's possible
> to differentiate between "Chris Devers 42" and "Chris Devers 17". You
> can't really get around this though -- assigning ID fields to records is
> a theme common to all databases, as it's the only way around the problem
> of distinguishing seemingly identical records.
>
> Coding all this up isn't very challenging -- all you have to do is add a
> field and hooks to read & write it. The bigger problem is social, not
> technical: everyone needs a unique identifier, either a randomly or
> sequentially selected ID tag (e.g. id number), or some other token they
> select themselves (e.g. account name &/or password). Both have drawbacks
> (people don't like having to remember IDs; people don't like passwords)
> but one way or the other, this seems like what you have to do.
>
>
>
> (Also, I'm assuming that security isn't a consideration here, and that
> the biggest problem with people accessing the wrong account is that it's
> a nuisance, rather than a real security risk. If people accessing each
> other's accounts *is* a problem, then you need to re-evaluate things:
> each user needs a password or a similar authentication mechanism, the
> user list file needs to be protected & probably encrypted, etc. If, on
> the other hand, it's just annoying but nothing is actually harmed by
> people using each other's accounts, then the approach you have is fine.)
>
>
>
> --
> Chris Devers
~~
Dermot Paikkos * dermot@sciencephoto.com
Network Administrator @ Science Photo Library
Phone: 0207 432 1100 * Fax: 0207 286 8668
| |
| Wiggins d'Anconia 2005-02-23, 3:56 am |
| Please bottom post, and group reply so that everyone can help and be helped.
Dermot Paikkos wrote:
> More likely it's me that's ...
>
> 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.
>
This still shares the same problem that Chris mentioned earlier, what do
you do in the case of duplicates? My first job out of college I worked
for a small web firm, when I started there were a total of 12
employees.... 2 Brian Millers. Middle initials... J and JS ... Went to
the same college, both played sports (though different), lived in the
same apartment complex, were both Perl programmers!!!!!! One of the
keys is that to have an effective login system you *must* come up with a
*unique* identifier.
This is FAR more important than the tiny boost you will get by varying
your implementation backend.
> 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.
>
I would suggest not reinventing this wheel.
If you must, I would scrap the flat text files and opt for at least a
simple SQL database, even if it is SQL lite. You will soon thank
yourself, and anyone maintaining it after you won't ask for the address
of your first born.....
> boost by using a DBM file. Should I just stick to using a flat file
> and extend it as you say?
> Dp.
>
You won't. But you shouldn't. Use a DB, or look for a suitable
alternative online, and spend your tuits working on something that
hasn't been written hundreds of times.......... At the very least start
with an application framework where user/session management has already
been written.
http://danconia.org
| |
| Chris Devers 2005-02-23, 3:56 am |
| 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 ...
>
> 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
|
|
|
|
|