Am Montag 02 Juli 2007 15:33 schrieb John Napiorkowski: [ quote of Chris H. Lacos message ]
> I also like to use uuids as PK as well, however when I > am using them as PK's I prefer to use a custom domain > and type in postgres to create them rather than use > the DBIC plugin. That way if my admins need to access > the database directly and make changes (like add rows, > etc.) or if I need to have the DB used by applications > not using DBIC I don't need to worry that the PK's > will get messed up. Thank you very much for your answers up to now, Christopher and John! They make me a lot more confident that uuid is what I want. But the statement about direct access to the databases bypassing dbic makes something ring in my head... As far as I know, sqlite doesn't support uuids by itself, so I would have to rely on dbic resp. Data::UUID. Does it, as a not-so-easy-bypassable alternative, make any sense to use some sort of "quasi-uuid" that is implemented as an INSERT trigger? Something like "DATETIME + RANDOM" or so? My keys don't necessarily need to be *universally* unique, but only for my specific application where it's unlikely that two instances are run at the very same time. You talk about "custom domain and type in postgres", which sounds a bit like your own "uuid"-implementation, but I don't really get the idea how you actually do it. > I do this when I get to use Postgresql. When I have > to use Mysql I just go with oldschool serial PKs. > > --john Thanks a lot - Ben _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
