Re: Which databases to use?

jZed is absolutely correct - DBM::Deep is an excellent option if you're looking at a DBM-type solution. This is also good for most SQLite solutions as SQLite doesn't really provide the "relational" part of an RDBMS. (IMHO, it's just a less-featureful implementation of SQL::Statement in C.) DBM::Deep would easily solve both of your needs.

Now, your next question will be "When should I use an RDBMS (like MySQL or PostgreSQL) vs. DBM::Deep?". That's a really good question. The answer, luckily enough, is very simple. Use an RDBMS when you have separate parts of your data that have relationships. That's what the R in RDBMS stands for. Otherwise, all you need is a DBMS, which is what DBM::Deep is.

As for SQL, you can have SQL query pretty much anything you want - that's what DBD::AnyData is for. :-)

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: Which databases to use?

Replies are listed 'Best First'.
Re^2: Which databases to use? by wink (Scribe) on Aug 19, 2005 at 14:53 UTC
Thanks! Your reply was very informative. I suppose I'm still a bit confused as to what constitutes "relational" in a database. For instance, in example #2, it's a database of academic questions (ever heard of Quizbowl?) that include the main category, subcategory, type of question, question, answer(s), and the author. I will want to do a number of different lookups: by category (or subcategory), by author, grab all the answers (so we can avoid duplicates)... I don't know exactly why, but this seems like a possible candidate for the RDBM, but I'm really not familiar enough with them to decide. :-/	[reply]
Re^3: Which databases to use? by jZed (Prior) on Aug 19, 2005 at 15:31 UTC
Are some of the question multiple choice questions? If so you have relational data : there is a one to many relationaship between a question and the multiple possible answers to that question. Do you need to track information about authors? If so you have relational data since there is a one to many relationship between one author and the multiple questions they have written. But whether the data fits the relational model is not, IMNSHO, the only thing to consider. You also need to consider who is going to write the code that does things like adding new data, removing old data, querying data, displaying data result sets in various formats, etc. These operations are standard operations for RDBM systems regardless of the complexity of the data. Therefore there already exist many solutions and you don't need to re-invent inserts, update, delete, display, etc. yourself. Do those solutions exist for other non-RDBMS systems? Well they can certainly be recreated with Perl, anything can. But I doubt you'll find the breadth of solutions already created in the RDBMS world. In Perl RDBM systems are primarily accessed through DBI which presents a standard interface. This means that there are many people who are familiar with how to do all of those operations and that there are many modules that allow you to do those operations in a coding style you prefer.	[reply]
Re^3: Which databases to use? by dragonchild (Archbishop) on Aug 19, 2005 at 16:37 UTC
Note: there is a certain amount of overhead associated using the relational part of an RDBMS. Very often, if you only have a small dataset, say under 1000 rows of data, the relational overhead is often not worth it and it's easier just to use a DBM such as DBM::Deep. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]