Re: candidate keys in abstract parent relations

Tony Rogerson wrote:
> I totally agree with your post there, cool! But it leads me to a question
> that I'd like to throw out in the airways...
>
> We can (and do) build logic in to protect ourselves to an extent, for
> example make sure a date of birth is realistic; somebody isn't claiming a
> pension where they are only 16 etc...
>
> That leads me to the question though, those type of data validation are more
> business logic aren't they or perhaps not? To what extent do we defend the
> validity of the data in the database, for instance an email address, in SQL
> Server you can now create a column say is_valid_email which can call a CLR
> scalar function that can run a bit of C# / VB.NET to actually go out and
> validate if that email address is truely valid at the point you want it...
>
> select *
> from member_list
> where is_valid_email = 'Y'
>
> I'd be interested to know peoples thoughts on this, do you keep this logic
> centrally within the database so that you don't have to duplicate it on each
> application that uses the database??
>
> Tony.
>

Ha! Leave it to microsoft to foist the uncertainty principle on helpless developers. By the time all that code finishes testing the handle for the 'last' 'member', the email handle for the 'first' member may have been suspended by his ISP. Sometimes I get notifications of failed emails a week after I send them. So when the set/relation is returned, handles that were valid when the query started won't necessarily still be valid (would that remain a relation or some bastard?) Of course the really deep thinkers in Redmond might be thinking that this could spawn a whole new industry, optimizing those week-long queries!

If this means that a table can have different predicates at different times, I wonder what EF Codd would think of it if he were still alive?

Only half-kidding - maybe you're talking only of validating the syntax or representation of the handle. I'll be interested to see how they develop this further, like how all the usual relational ops will behave on that CLR column, eg. how does one compare two such programs to see if they are somehow 'equal'? How would normalization work - based on the value or the code?

As for the actual question, I think it's a darned good one put in a fresh way even if thinking about has given me some good laughs this morning. Can't resist - I suppose in some cases a lot of disk space could be saved if each app had its own validation code. That way, rows that were invalid for one app could be valid for another, but those apps could share the same db tables! Though this group might then need to be renamed to 'comp.applications.theory'!

Seriously, the reason I think it's a good question is that it touches on something that I've had a hard time understanding - just what is the theory behind 'derived' columns, even ones as simple as Date's 'GMWT'.

p Received on Mon Jan 23 2006 - 16:49:59 CET