I was recently asked to look at something similar at work recently, to enable keeping a "database" of contacts which would be stored in a RDBMS (Oracle, in this case). It's certainly do-able, in more ways than one: serialisation (using Storable, YAML, or Data::Dumper, for example); non-relational databases (à la BerkeleyDB); a faked RDBMS (for example, DBD::CSV); or tightly controlled limited access to another real relational database. Anyway, here's a few things to consider.
- How much is performance an issue? If you're going to be loading up these databases hundreds of times a second, something fast like Storable, BerkeleyDB or a real RDBMS with persistent connections is gonna be a good choice;
- How much do you trust the people using the 'database'? if you can trust them, and the functionality is well protected, perhaps giving them a sandpit relational database is the way to go. Most major RDBMS (Oracle/MySQL/PostgreSQL/whatever) allow very fine-grained configuration of user rights;
- How much do you need the full power of SQL, as opposed to just persistent data? If you don't need it, go for a simpler serialisation-style solution.
- Have a think through how things like transactions and commits will be handled: do you want data to be written transparently (more like tie), or do you want explicit control over when the little database is written to the big main database (more like DBI)?
If you wanted a full relational database, and really couldn't give even limited access to limited 'real' databases to your users, then I think you'd have to use a modified DBD::CSV, with the file-based interface (based on DBD::File replaced with one that fetched the source CSV from TEXT fields in your main database
HTH
ViceRaid