Re: [Gnumed-devel] External id type attributes, data consistency and validation

[Karsten Hilbert]

On Sun, Sep 25, 2011 at 02:32:41PM -0700, Jim Busser wrote:

> so it is presumably more fitting that any such rules are tied into the 
> *relationship* between the value
> 
>       ext_id
> 
> and the individual to whom it pertains
> 
>       identity

Uhm, well, that's maybe too narrow in scope.

> taking into account the requirements of the ext_id_type
> 
>       dem.enum_ext_id_types
> 
> which is where you are seeming to agree we should store
> the constraints, and what you have clarified is that in
> place of multiple columns (one per specific constraint) we
> would better gather up one-to-many possible constraints per
> external ID type,

I can easily understand there to exist rules (of whatever
origin) applicable to manifestations of external ID types.

I would think it proper database design to store such
restrictions with each external ID type. This would then not
allow one doctor to format SSNs one way while another doctor
may prefer another way - but that would not be a property of
the SSN type but rather of the doctor (!).

> and store these in a single column
> 
>       dem.enum_ext_id_types.regexen
> 
> BTW as far as a column name, I gather
> 
>       .regexen
> 
> is an inventive plural for pseudo-latin regex

Geek speak: boxen, UNIXen, VAXen

        http://www.retrologic.com/jargon/overgeneralization.html

> and would need to clarify how multiple strings would need to be formatted / 
> stored to best allow their re-use.

We would not because it would be an array of TEXT.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346