Re: Validation
- From: "d-42" <db.porsche@xxxxxxxxx>
- Date: 11 Apr 2007 20:18:55 -0700
The second, Global fields, method is probably the best and easiest. I
don't really know what "table instances" are,
Pardon me "Table Occurrences" (on the Relationships Graph)
but once the Relationship
is defined you don't actually need any related fields on the current
layout to accessing them - just a script command along the lines of:
Set Field [GlobalField, LinkData]
If [Count(Relationship::KeyField) = 0]
{do whatever for no related records}
Else
{related records do already exist}
End If
Interesting.
Yeah, I can see the simplicity advantage in script coding, but the
expense is in design complexity, as the validation check can't be
contained by a script but instead has to spill-over into the data
design, adding fields, table occurrences, and relationships.
In order to avoid obfuscating the data model with global validation
relationships I find myself creating a whole separate tree in the
relationships graph just to support the validation.
A side effect of splitting it into a separate tree is that I have to
create a dedicated layout to do the validation testing, because the
'global relationships' are connected to a different table occurrence
than the real data model. This also means the script has to flip
layouts.
And at that point, since I already need a separate table occurrence I
think its best to put the globals in a separate dedicated utility
table so the fields don't pollute the data table.
The script approach would save me the whole tree; its perhaps not
quite as efficient, but it keeps the database design easier to
understand, which in a complicated solution might be worth something.
I'm dealing with a solution with over 40 core data tables plus many
more utility tables, work tables, and so on, adding 30+ validation
trees to the graph is an unwelcome prospect.
I know I -could- just attach everything to the data-model; and in fact
that's what I'm coping with right now -- monstrous "spiders" graphs
from the v6 to v7 conversion. And as people started dangling 'deeper'
relationships off the spider to add functionality the result is an
incomprehensible mess. :)
Thanks very much for your insight; as you can see I was leaning
towards the script (and hoping for something even better). But if, as
you say, standard practice is via globals though; then I should
reconsider. After all adding 30 validation trees won't make the
database much harder to understand as the individual trees themselves
are simple and separate from the main data model, but it will make
some of the already 'stuffed' value-lists (like choosing a 'table
occurence' in set-field) even *more* stuffed.
.
- Follow-Ups:
- Re: Validation
- From: Helpful Harry
- Re: Validation
- References:
- Validation
- From: d-42
- Re: Validation
- From: Helpful Harry
- Validation
- Prev by Date: Re: Validation
- Next by Date: Basic Design
- Previous by thread: Re: Validation
- Next by thread: Re: Validation
- Index(es):
Relevant Pages
|
