Jesper Krogh wrote: >> 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 > In the case of SSN, I'd most likely store that and birthday in two separate fields. Also I'd be loathe to store SSN anyway ;)
Still not convinced its a good idea, but: http://search.cpan.org/~jrobinson/DBIx-Class-0.06003/lib/DBIx/Class/Manual/Cookbook.pod#SELECT_COUNT(DISTINCT_colname) Just replace count with prefix might work Ash _______________________________________________ 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]/
