From: Lew on
vlado wrote:
>      If I have example like this above, I will first have to fill lookup
> table with some values (Saturn....), and then when saving one record to
> DB define constants on let's say web, business or data tier that
> will have the same value as lookup table, because when saving record in
>

You can look up the constants from the lookup tables to populate your
GUI widgets.

> DB i [sic] will have to define FK value before persist.
>

That's if you use foreign keys. You might not for lookup values; that
was the point of the post.

> Then I will have the same values in DB defined twice, is it ok ?
>

Yes, though not "defined" but "referenced" twice.

--
Lew
From: vlado on
On 12.7.2010 21:24, Lew wrote:
> vlado wrote:
>
>> If I have example like this above, I will first have to fill lookup
>> table with some values (Saturn....), and then when saving one record to
>> DB define constants on let's say web, business or data tier that
>> will have the same value as lookup table, because when saving record in
>>
>>
> You can look up the constants from the lookup tables to populate your
> GUI widgets.
>
>
>> DB i [sic] will have to define FK value before persist.
>>
>>
> That's if you use foreign keys. You might not for lookup values; that
> was the point of the post.
>
>
>> Then I will have the same values in DB defined twice, is it ok ?
>>
>>
> Yes, though not "defined" but "referenced" twice.
>
> --
> Lew
>
Regarding to lwhat you said about "

You can look up the constants from the lookup tables to populate your
GUI widgets.

"
Yes, that's ok when i have just one page /form to persist to
database, but I have 3 or 4 similar forms, let's say in garage/car
example if i have in
first table range of year from 2005-2009 to persist , and the second
form saves years range 2006-2009. That's the probem, because year's
interect. How can I
load data from lookup tables and distinguish them for two forms if my
data in lookup table will be 2005, 2006, 2007, 2008, 2009(only one
column). I need to have one more
column to tell me for which form it is in my lookup table, or no ?

Thanks.


From: Lew on
Lew wrote:
>> You can look up the constants from the lookup tables to populate your
>> GUI widgets.
>

vlado wrote:
>      Yes, that's ok when i have just one page /form to persist to
> database, but I have 3 or 4 similar forms, let's say in garage/car
> example if i have in
> first table range of year from 2005-2009 to persist , and the second
> form saves years range 2006-2009. That's the probem, because year's
> interect. How can I
> load data from lookup tables and distinguish them for two forms if my
> data in lookup table will be 2005, 2006, 2007, 2008, 2009(only one
> column). I need to have one more
> column to tell me for which form it is in my lookup table, or no ?
>

I wouldn't put years in a lookup table in the first place. I'd most
likely use surface-edit validation (in Java for Java-based systems) on
the form itself to constrain the year ranges, but not enforce that in
the data layer.

There's always a decision as to where to enforce data rules. You have
surface edits, middleware logic and data constraints - which you
choose for any given rule is a matter of art.

--
Lew
From: vlado on
On 12.7.2010 23:05, Lew wrote:
> Lew wrote:
>
>>> You can look up the constants from the lookup tables to populate your
>>> GUI widgets.
>>>
>>
> vlado wrote:
>
>> Yes, that's ok when i have just one page /form to persist to
>> database, but I have 3 or 4 similar forms, let's say in garage/car
>> example if i have in
>> first table range of year from 2005-2009 to persist , and the second
>> form saves years range 2006-2009. That's the probem, because year's
>> interect. How can I
>> load data from lookup tables and distinguish them for two forms if my
>> data in lookup table will be 2005, 2006, 2007, 2008, 2009(only one
>> column). I need to have one more
>> column to tell me for which form it is in my lookup table, or no ?
>>
>>
> I wouldn't put years in a lookup table in the first place. I'd most
> likely use surface-edit validation (in Java for Java-based systems) on
> the form itself to constrain the year ranges, but not enforce that in
> the data layer.
>
> There's always a decision as to where to enforce data rules. You have
> surface edits, middleware logic and data constraints - which you
> choose for any given rule is a matter of art.
>
> --
> Lew
>
Ok, but let's say car type, or model could be put in lookup table
and joined to CAR table through FK key, but also it could be set
directly into CAR table (type, model columns) ?
From: Arved Sandstrom on
vlado wrote:
> On 12.7.2010 23:05, Lew wrote:
>> Lew wrote:
>>
>>>> You can look up the constants from the lookup tables to populate your
>>>> GUI widgets.
>>>>
>>>
>> vlado wrote:
>>
>>> Yes, that's ok when i have just one page /form to persist to
>>> database, but I have 3 or 4 similar forms, let's say in garage/car
>>> example if i have in
>>> first table range of year from 2005-2009 to persist , and the second
>>> form saves years range 2006-2009. That's the probem, because year's
>>> interect. How can I
>>> load data from lookup tables and distinguish them for two forms if my
>>> data in lookup table will be 2005, 2006, 2007, 2008, 2009(only one
>>> column). I need to have one more
>>> column to tell me for which form it is in my lookup table, or no ?
>>>
>>>
>> I wouldn't put years in a lookup table in the first place. I'd most
>> likely use surface-edit validation (in Java for Java-based systems) on
>> the form itself to constrain the year ranges, but not enforce that in
>> the data layer.
>>
>> There's always a decision as to where to enforce data rules. You have
>> surface edits, middleware logic and data constraints - which you
>> choose for any given rule is a matter of art.
>>
>> --
>> Le
>>
> Ok, but let's say car type, or model could be put in lookup table
> and joined to CAR table through FK key, but also it could be set
> directly into CAR table (type, model columns) ?

You could. I have done fairly substantial (as in several years worth of)
maintenance work on a government motor vehicle registry J2EE
application. In that application vehicle make is a separate table and
the vehicle table, among others, references make by FK. Vehicle model,
OTOH, is just a plain String in the vehicle table. That's what makes
sense for us.

AHS

--
The warning message we sent the Russians was a calculated ambiguity that
would be clearly understood.
-- Alexander Haig
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: PDF Screen Shots
Next: open all sites free now