Re: Form saving, db question ?
vlado wrote:
I'm using a relation database, and ID in these tables i=
s used
as a primary key. What do you mean by you will have a lookup table
with car types to keep them consistent ? Is't lookup table bes used
when let's say I hava a drop down list in
my form with data that which will be rearly changed or updated ?
Arved Sandstrom wrote:
My question would still be, in *your* problem is the car type
(something like FORD_MUSTANG) part of the identity? Lew was trying to
get at this, because it's important.
Actually, I was trying to get at why he was using ID specifically.
The answer "it's the primary key" is flat-out silly - that's circular
reasoning. It's not the primary key because it's the primary key.
WHY is it the primary key? What does it *mean*?
If the answer is "nothing in terms of the problem domain" (vlado - you
need to know what "problem domain" means) then the logical analysis
should eliminate ID and look at the *real* primary key - the one that
identifies the thing described *in terms of the domain of discourse*.
A database table is a representation of the problem domain - it
doesn't drive the definitions, it reflects them.
If it's not part of the identity then that field is more of a
free-form descriptive string; if you wish to pre-define the available
values that then is still more of a user-input presentation-layer
constraint, and you could use an enum mapping to a varchar field to
store the actual values. In this case your ID primary key is a
surrogate key and you may have no natural key at all.
If OTOH the car type is part of the identity (it's all or some of
a/the natural key) then you may very well still be using the ID column
as a surrogate and primary key, but it's now also in your interests to
ensure that the car type column is constrained (a unique index) on the
data/RDBMS side. In which case the table that enforces this constraint
isn't going to be the table that stores user input; hence foreign
keys. In this case, as Lew said, the actual param value is in the user
input table, that uses a foreign key relationship to point back at the
table containing the car type natural keys.
vlado - that point is the key.
"Rarely changed or updated" isn't typically your driver in deciding
data relationships, what the natural keys are, or how you'll enforce
data integrity in your tables. It's definitely a factor - for example,
I'd take it into account when fine-tuning entity caching in JPA - but
not at this stage.
1.What do you mean by "part of identity" ?
Once again, read about third normal form (3NF). I didn't mention it
for its irrelevance, but its relevance.
You are going to have extremely poor results if you don't familiarize
yourself with the basics of database design.
"Identity" is the attribute or collection of attributes that uniquely
identifies an entity. Think of it as the object attributes that
contribute to 'equals()' evaluation, if you like.
Answer the question I asked above, which you have for some reason so
far refused to do: What is the *meaning* of ID in the problem domain?
It isn't that "it's the primary key". That's backwards thinking.
What does it represent in terms of the entities that make it the
primary key.
Again, I'm willing to gamble that it means nothing.
Please answer this question.
2.Other thing is that on every project we have practise to have lookup
tables , like country that have for example ID, NAME columns, so I can't
use table without primary key (ID).
ID and "primary key" are not synonyms.
What is the *real* key?
--
Lew