design strategy on handling large DB

[pgodfrin]

Ok, that makes sense--just seems like a 'gotcha' to keep in mind when
using DBI with mysql, as Peter pointed out earlier in this thread.
Thx.

Yes that is certainly a "gotcha". However, the OP's question was never
answered (although the question was strangely posed...).

Question to the OP - why would you want to cache the table outside of
the DBMS? I can see in certain cases, like very (VERY) small 'lookup'
tables, which you would prefer not to have to I/O to the database
every time you user interface is called, but I think there is a module
to do that sort of thing already - Cache. But, I would not try to
cache the underlying database file - I would cache the results of a
select statement. For example if you have a code table which is 20
rows, I would select the 20 rows and cache the result. Not try to
cache the underlying database file in which those 20 rows are
located...

phil

 

[szr]

Yes that is certainly a "gotcha". However, the OP's question was never
answered (although the question was strangely posed...).

You could also take a look at DBD::mysqlPP

(http://search.cpan.org/~oyama/DBD-mysqlPP-0.04/mysqlPP.pm)

which is a pure Perl version of DBD::mysql