Hash inside hash - database? 1

[Tupps]

I'm gonna write a forum in Perl, and I just wondered the best way to store the member details. I didn't want to read through each member file just to load their "number of posts" or something each time someone views a topic, so I thought about using hashes, eg:

$users = {
	"Danny" => {
		name	=> "Danny Tuppeny",
		email	=> "Danny\@MyBest50.com",
		age	=> "17",
	},

	"John" => {
		name	=> "John Edwards",
		email	=> "John\@Johnnyboy.com",
		age	=> "127",
	},
};

Obviously with more stuff in though.

Is this stupid? I thought maybe it would take a lot of memory if the number of members got quite big.

What's the best way? I don't want to use a database like MySQL, I'd rather use flat files (for those that don't have databases, and so it's still efficient for small forums)

I'd be very grateful of any suggestions.

Thanks,

Danny

 

[MikeLacey]

Danny,

Have you thought of storing these details in a DBM file? DBM files are supported in Perl.

That would give you fast access, you could delete, modify records easily and you could read the data into your structure above. Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[Tupps]

DBM? Is that perl mod? Is it included as the standard distribution (I think I have it, but not sure if my host does).

I did start using $$username{item}

eg. $dannytuppeny{name} and $jimbob{email} etc., but I suppose a database would be better.

Thanks

 

[MikeLacey]

DBM is quite an old file format actually. It comes from UNIX. I think NDBM is supported on NT -- what platform are you working on? Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[Tupps]

I'm writing on WinMe, but uploading to a Unix server. Both Apache, Perl, PHP etc.

I was just thinking... I have MySQL, whish I use with PHP.. I sit the same commands as with that? (eg "SELECT * FROM table WHERE f_name = 'Danny'" ??)

Thanks,

Danny

 

[MikeLacey]

Well, if you have MySQL you can use DBI -- that's *got* to be the easiest way. Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[Guest_imported]

MySQL is not a really good solution because it does not
do (built-in) restraints on fields. I have a friend whose
boss tries to maintain a MySQL DB and has to remember to
change his field validation code all over the place.

DBM is not so good either.

I have a smallish HASH HASH HASH quotation DATABASE
in pure perl. The code uses 'include' stuff so my
perl code calls the DB code fragment which I allow
savvy salesmen to fiddle with.

eg. quote.pl calls quoterc.pl to get the HASH's filled in.

I also have the quote.pl code handle all the HTML stuff
it literally unpacks itself after I edit it. I only have
to edit one file and I can check for single mention of variables
(for those occasions when I mis-spell a variable)
and I can make global changes to variable names etc.

OF Course PHP is a great way to go for WEB stuff and DB's.

COLDFUSION is an expensive program with some bugs but hey
we are used to BUGS if you want to play with MS products.

Kind Regards
Chris Thompson
cjt@comnet.com.au

 

[Tupps]

I wanted to use perl, as it seems to parse files and text quite quick. I need something I can both read and write data too (unlike some things I downloaded which don't have a feature to actually write the data!!)...

I'm getting confused... TIMTOWTDI!!! :-?

Oh well, I may go back to my original idea of PHP and MySQL...

 

[goBoating]

Tupps, I think MySQL or PostgreSQL would do what you want. The DBM or flat file approach would work also with a little file locking as traffic control. I don't understand Chris' criticism that MySQL won't constrain fields. I don't see how a 'pure' Perl approach enforces any automatic field constraints....<ponder>...the constraints would have to be written into the code.....< ponder>.......

Chris, maybe you can ellaborate?

In my mind, it is a question of scale.
If you want to build a large complex system that will handle hundreds of tables of relational data with millions of records and numerous simultaneous connections, then you are looking at Oracle or Informix or the like, and you are looking at paying a real database administrator.

If you want something that will maintain a few tables for user information and postings, then MySQL or PostgreSQL would work fine. PostgreSQL has a few more powerful features and is also free. It will do triggers and functions.

Finally, flat files or the DBM approach will work also for limited systems that you don't expect to have to expand significantly. I run a web based system that is XML flat files that has nearly 1000 entries with 35-40 fields in each entry. Custome report generation is fairly straight forward by parsing the XML and the structure will be easily converted to PostgreSQL if it starts to get slow, which I has not yet.

You can take a look at a flat file based discussion package available at

http://www.hypernews.org/

The software is free and reasonably fast and not to hard to tweak. I have several instances running for our organizations internal use.

Sorry that TMTOWTDI......, I'm not sure this will be helpful. I realize it might have just further muddied the water.

HTH anyway.


keep the rudder amid ship and beware the odd typo

 

[Tupps]

Well, I think MySQL sounds best then. As it'll probably be very small to start with, and it may grow to a few hundred members.

Thanks to everyone for the pov's, I'll make sure if I'll take them into consideration each time I need a database!

Thanks again,

Tupps