> Jesper Krogh wrote: > Unless you have a *VERY* good reason to keep the fields as one, split > them out into two separate fields.
That could be a solution.. but this database is in production, so that is not an option for now. You could argue that it would be the correct thing to do in this case, but the features that I use are generic, so it would be nice if if where possible to use them anyway. Say, lets take an social security number as an example .. here in Denmark they are composed of the birth-day and som "checksum". 020575-2432 Would you still split those in two seperate fields? Searching on the "birthday" if you do, you'll have a unique constriant across several fields and a datarepresentation that are very uncommon. As it is .. you can both easily ass checks and searches using stored procedures and indexes.. (even very speedy ) Jesper -- Jesper Krogh _______________________________________________ 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]/
