|The stupid question is the question not asked|
Class::DBI and DB designby v_thunder (Scribe)
|on Jun 06, 2003 at 15:40 UTC||Need Help??|
v_thunder has asked for the
wisdom of the Perl Monks concerning the following question:
I use a postgres DB for an application of mine, which I am redesigning and at the same time switching to Class::DBI (from DBI). It seems from the docs like a fairly nice package, at least to non-db-savvy people like me.
I am finding the primary key restrictions of Class::DBI rather annoying, though, and I'm wondering if I'm lacking some nugget of wisdom that will make this make sense.
I have some tables like this:
If I read the Class::DBI docs right, I need to add a "relation_id" column to the user_capabilities table, even if I'm never going to need it. Why? What was the reasoning behind that restriction?
Also, what about this case: I add another table, like:user_logins: has a uid, and a timestamp.
I'd add one more row each time the user logs in, and I'd query on uid to get a list of all the user's logins in the past. Would I have to add another "id" column to that table as well?
Lastly, have I picked a bad solution? I did some research before going with class::DBI, most people seemed reasonably happy with it (and also mentioned the primary key thing being annoying). I'm just wondering if there are any horror stories I should be aware about before spending a lot of time re-writing chunks of my app to work with Class::DBI.
Thanks for any help you can provide :)