[Dbix-class] Re: doing a search

[Matt S Trout]

On 22 Jan 2007, at 19:36, A. Pagaltzis wrote:

> * Matt S Trout <dbix-class at trout.me.uk> [2007-01-22 15:10]:
>> Using only the table name is kinda foolish because it screws
>> you when you have multi-col PKs.
>
> Granted; I haven’t had such a case though. :-)  I think it’s
> good practice to use surrogate keys in any case were you’re not
> absolutely and completely certain that the key can positively
> never ever ever change.

Ah, the ActiveRecord/Jifty::DBI approach. Personally I've always  
preferred to do actual database design.

And anyway, primary keys -are- allowed to change, else what's ON  
UPDATE CASCADE for?

> Since I also haven’t had to use legacy
> schemata, my only multi-col PKs have been (FK,FK) pairs in join
> tables. And my surrogate key column is always called `id`, which
> I wouldn’t bother mentioning in any case.
>
> If I did have a multi-col PKs I’d want to refer to, I guess I’d
> opt for also including the FK column name. But I wouldn’t drop
> the extra label describing the relationship, so I’d end up with
> `foo.author_user_asdf` referencing `user.asdf`. (Maybe I’d use a
> double underscore to delimit the relationship from the referee or
> something; not sure.)

I've always preferred relname_attrname simply because as I refactor  
stuff the attribute may end up being joined across to a view or  
whatever or a different table, and I don't like to hardcode my table  
names (DBIC's ability to not give a fuck when I rename stuff tends me  
to prefer nothing else does :)

-- 
Matt S Trout, Technical Director, Shadowcat Systems Ltd.
Offering custom development, consultancy and support contracts for  
Catalyst,
DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for  
details.
+ Help us build a better perl ORM: http://dbix- 
class.shadowcatsystems.co.uk/ +