Re: Form saving, db question ?
On Jul 8, 7:11 am, vlado <vl...@miha.net> wrote:
I have a form like this
Param type1(outputText) : value1(inpuText)
Param type2 (outputText) : value2(inputText)
. .
. .
and so on. And I want to save it in a database. Is it better to have one
table which will have columns like this :
ID, PARAM_TYPE, PARAM_VALUE
1 FORD_MUSTANG 10
2 AMG_CLK 50
Wow, that didn't line up well.
and so on.....
, or
table that will have columns like this :
ID, PARAM_TYPE_FK, PARAM_VALUE,
1 1 =
10
2 2 =
50
and so on....
where PARAM_TYPE_FK is FK to look_up table cointaing types like
(FORD_MUSTANG, MERCEDES_AMG...and so on) , or to have these types in
let's say enum in web controller and write just (1,2) in PARAM_TYPE_FK
column without look up table.
That depends.
You will need a search engine and/or Wikipedia for the following.
If you are using a relational database, it is best to keep it at least
at third normal form (3NF), unless it's a data warehouse, in which
case the time dimension changes the idea of what constitutes a normal
form.
Your question seems to focus on the matter of natural keys vs.
sequenced surrogate keys. What is the business-domain meaning of the
"ID" column in your layout?
When you do a relational database design, at least at the so-called
"logical" level, you need to know what constitute the keys in your
problem domain. I venture to gamble that "ID" is not part of the
problem domain and therefore no part of your logical design. If you
do use such a surrogate key, it will be an optimization detail of the
physical implementation that has no place in the domain model.
For your particular problem, I'd probably have a lookup table
representing the car types to keep them consistent, and copy the
actual value into the table that references them.
table PARAMS:
PARAM_TYPE PARAM_VALUE
------------ -----------
Ford Mustang 10
Chevy Camaro 17
table PARAM_TYPES
PARAM_TYPE
------------
Ford Mustang
Chevy Camaro
Yes, there'd be a FK relationship between PARAM_TYPE in both tables.
This is not a Java question, but Java programmers do need to know
about database design.
--
Lew