[Tfug] "Ordering" tuples in a table

[Bexley Hall]

Hi Dave,

>> So, what I do is create a new entry for "mom" *if* you give
>> me data for her as "child's" parent -- and then *hope* you
>> come around to eventually filling in the details of *that*
>> record at a later time.  (the way I do it currently is
>> pretty involved since I need to note those records that
>> were artificially created so that they aren't persistent
>> *if* you happen to create yet another "new" record to replace
>> it)
> 
> It sounds like your problem may be more on the user
> interface side of things then?

Well, I am of the belief that it's always the *designer's* problem!
:>  I try hard to make the user see an interface that doesn't 
*impose* on his way of doing things -- the application should
bear the cost of making the system work *for* the user.
Often, this clashes between how things *should* be done and
how the user "thinks" they are being done.

E.g., building on the parent-child example... a typical
product (don't think in terms of desktop applications;
instead, think in terms of PDA, cell phone, etc.) would
either *not* be as thorough in their data model (e.g.,
the "contacts/address book" would not even *try* to
preserve personal relationships) or would let/force
the user to completely specify this data (e.g., type
in the name of their mother) and make little/no
effort to link that data to the data for that real
person elsewhere in the database.

(sorry, hard to express this in concise terms.  But,
think of the example and think of: the fact that it
*isn't* included in products and, if it were, how it
would likely be implemented)

> Why not add an 'Add Child' button to the
> 'Person' record view. Then when the user clicks the
> 'Add Child' button the child record is created with
> the parent reference properly populated. You could also have
> a 'Set Parent' button to associate a child with
> it's parent after record creation/persistence has
> already happened.

And a "set employer" and a "set spouse" and a ...  :>

I do this implicitly by letting you "pick" a value for
each field.  In the case of your mom/dad, you can pick
from among the people already known to the system -- or,
add a new entry which causes me to create a bogus record
for that person in the hope that you might later flesh
it out -- or *replace* it (and, by having flagged the
bogus record *as* "bogus", the RDBMS can purge those
entries so they don't clutter up the "list of known
persons").

This approach is inherently extensible to all of the
other fields that could similarly be "references"
(foreign keys) to other data in the database.  I.e.,
there is no "add child" button (since parents don't
have children but, rather, children have *parents*)
but an implied "add parent" button.

Though you have to think about how the user's model
differs from the "implementor's" model.  E.g.,
users tend to think of persons as having *children*
(and/or parents) more than they think of "parents".
So, I have to add a layer to the interface that
lets the data model masquerade behind the user's
concept of what constitutes a "person".

(this is actually quite an interesting puzzle!  What
*does* represent a "person"?  It is amazing how
quickly you can embellish your model to include all
sorts of things that really aren't pertinent -- but,
that, as a *user* of that data, you might *associate*
with "persons".  :-( )

That's why the PDA concept is so enlightening as it
presents lots of challenges for data models *and*
for the types of users likely to interact with those.