Perl and data/databases

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

This question has N subquestions. I suppose the easiest one is: if a perl module has to come with data to be useful, how much data should be part of the module? If the module can come with MB of data, should it?

In developing this, I've been using DBM::Deep. I know DBM::Deep::Blue exists. DBM::Deep nominally requires DB_file. DBM::Deep::Blue does everything internally. In terms of developing the data, I think a persistent perl structure is required. How does/should one decide between the two above? I know MLDBM isn't what I would prefer to do.

Most of what I am going is HoH, some is LoH. Are there any lessons on how to turn Lo* or Ho* into SQL?

Thanks

Comment on Perl and data/databases

Replies are listed 'Best First'.
Re: Perl and data/databases by BrowserUk (Patriarch) on Nov 12, 2010 at 05:53 UTC
if a perl module has to come with data to be useful, how much data should be part of the module? If the module can come with MB of data, should it? The simplest answer to that is: just enough to make it useful and no more. If there is a larger corpus of data that may be required by some users, consider packaging the larger subset as a separate package. eg. Xxx::Yyy comes with the minimally useful dataset. Installing Xxx::Yyy::Pqr installs the bigger dataset for those that need it. It's easy to see that can be extended to multiple 'expansion' sets. In terms of developing the data, I think a persistent perl structure is required. How does/should one decide between the two (DBM::Deep .v. DBM::Deep::Blue) above? To my knowledge, DBM::Deep is Pure Perl. And runs pretty much anywhere perl does. DBM::Deep::Blue is written in C, therefore install requires a compiler, potentially limiting your user-base. Which may or may not be a bad thing. It also requires 5.12.1 which further limits your target audience. Most of what I am going is HoH, some is LoH. Are there any lessons on how to turn Lo or Ho* into SQL?* Do you just want to be able to query an individual sub* by it primary key? Or do you need to subselect to a finer granularity? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply]
Re: Perl and data/databases by CountZero (Bishop) on Nov 12, 2010 at 08:19 UTC
Are there any lessons on how to turn Lo or Ho* into SQL?* I don't know about lessons, but SQL::Abstract knows how to turn a Perl datastructure into SQL. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]