Re: Unique attributes
Re: Unique attributes
- Subject: Re: Unique attributes
- From: Arturo Pérez <email@hidden>
- Date: Wed, 15 Feb 2006 22:38:45 -0500
On Feb 15, 2006, at 5:53 PM, Ian Joyner wrote:
On 16/02/2006, at 1:25 AM, Arturo Perez wrote:
Ian Joyner wrote:
Thinking on it a little further and an afternoon walk (now I need my
afternoon nap), perhaps unique is not as high in the semantic chain
as we would like, since identifying candidate keys in relations
implies unique across the set of attributes in the key. This would
help in being able to identified if things were normalized into at
least 3NF or BCNF or where to denormalize for performance reasons.
That way, I think EOModeler could be made into a much more useful
tool than just the ER approach it supports and people may be
normalizing things and doing good design without realizing it! (OK,
I have to reread the books on normalization everytime :-()
Ian
I'm not sure I follow what you're saying here. Are you looking for
something like
EO1 relatedTo EO2 unique?
Or are you just looking for (EO1.attr1, EO2.attr2) UNIQUE? Postgres
will do this but without database logic I don't see how to do the
other.
Nothing about relationships between tables, but just identification of
candidate keys within a table, ie, all attributes or sets of
attributes that can be used to uniquely identify records. EO just uses
the PK as a pointer between records and as such it is just underlying
implementation mechanics, which is for the most part rightly made
invisible. However, this means that the many other semantic and design
uses of keys are not supported, except in our paper designs. Such a
key to identify a person record could be surname x first_name (which
is not a really good key because in reality uniqueness is not
guaranteed, so usually an employee number is used in preference, but
it's probably the simplest example I can think of). A better example
probably comes from relationship tables which relate two or more other
tables (join tables) like BOOK_LOAN where a candidate key would be
book_number x borrower_number (maybe with a date in case of multiple
borrowings of same book by same person).
Ah, I see what you're getting at. EO does support multi-value PKs
(for the join table example) but that doesn't address your point.
My perspective might be colored by my preferences and I'm just thinking
out loud but...
I am a big fan of model-based fetchspecs. The code-based ones violate
the "if you're writing code, you're doing it wrong" rule. As such, I
believe (with no evidence to back it up) that perhaps model-based
fetchspecs were intended to address your point to a certain extent.
You need alternate keys and a fetchspec would provide that. It will
return EOs properly etc.
Now, what won't a model-based fetch spec do? You'd need to couple them
to validation somehow. That's one thing that would need to be
addressed. What are other things your mental model requires? I think
redoing some of the object-uniquing EOF does based on PK would need to
be redone. Anything else?
-arturo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden