Hi,
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:
users: has uid, name, login. capabilities: has capid, name, and a default (bool). user_capabilities: has uid, capid, and a bool.
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 :)
In reply to Class::DBI and DB design by v_thunder
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |