Re: Modeling
- From: Doc O'Leary <droleary.usenet@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 23 Sep 2005 11:23:59 -0500
In article <1127419994.483722.44250@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
kr4ster.news@xxxxxxxxx wrote:
> In this case, I was planning on requiring the user to select from a set
> list of buildings/floors/room. Having a simple "location" field
> wouldn't quite work.
Why not? It's seems you're intent on discarding the abstraction of
location even though it provides a handy way to decouple objects. A
text field provides a simple search interface, and anything more than
that seems best provided by a hierarchical selection widget, not
breaking up the location into its component parts.
> I want to store the building,
> floor, and room seperately as I want them to be managed entities in the
> system. In this breakdown, I seem to have hit the same roadblock I hit
> in my original posting.
Because your "want" does not reflect the reality of the system. If the
system manages them, storing them separately only leads to potential
error because of denormalization. Your approach is not just wrong from
an object model perspective, it is wrong from a data model perspective.
.
- References:
- Modeling
- From: kr4ster . news
- Re: Modeling
- From: Doc O'Leary
- Re: Modeling
- From: kr4ster . news
- Modeling
- Prev by Date: Re: Program to an Interface not an implemetation
- Next by Date: Where Does File System Singleton Go?
- Previous by thread: Re: Modeling
- Next by thread: Re: Polymorphism sucks [Was: Paradigms which way to go?]
- Index(es):
Relevant Pages
|