Prev: PDF Screen Shots
Next: open all sites free now
From: Lew on 12 Jul 2010 15:24 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 12 Jul 2010 16:57 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 12 Jul 2010 17:05 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 12 Jul 2010 17:08 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 12 Jul 2010 17:27
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 |