Re: RDBMS design issue

On Tue, 8 Jul 2025 10:18:46 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

On 7/8/2025 7:31 AM, Joe Gwinn wrote:
>

[I guess when you write code, the idea of chasing pointers
is highly intuitive]

 
Very complicated for sure.  But what is the *purpose* of this database
to be?  This will lead to what needs to be tracked and how precisely.
And to what can be elided.

>
My (personal) "address book" takes this form -- with the exception of the
tuples created for these one-to-many relations (IsFatherTo, IsEmployeeOf, etc.)
As such, I can "walk" through a person's "six degrees of separation" to
get the information on a particular individual.
>
  Joe's brother's wife's mother's daughter
  Joe's brother's mother-in-law's daughter
  (one of) Joe's brother's sister-in-laws
>
Isn't this how we relate to people not in our immediate family?
Do you remember your brother's mother-in-law's full name, cold?
Or, do you step through the relationships (in your mind) and
try to drag up "handles" for each of the people you "step along"?

Although true, this is not an answer to my question.

The Swedish have a useful system:  Mor is Mother and Far is Father.
MorMor is your maternal grandmother and MorFar is your paternal
grandmother, and so on, to any depth.  I don't offhand know of
extensions beyond Mor and Far, but they  may exist.  This pattern
occurs in all Norse languages.

There is a childrens' song playing on this.  I encountered it when in
Stockholm in the 1970s, when the children in a nearby park were
singing it in chorus with gusto.

It was created as the result of a survey I had done of clients'
needs (for an address book).  I had imagined a much smaller dataset;
how many people do YOU know (and keep track of)?  I have a few hundred.
A client showed me *his* address book with *5000* entries!  (almost
all of which were HIS clients -- not people with whom he interacted
frequently but, rather, people whose contact information he had to
retain:  "Mr Smith called, today.  You should call him back during
business hours"
>
[I.e., you wouldn't store *a* phone number per People as most have
multiple phone numbers; you'd store the set of numbers and how
they relate to that People.]
>
There are lots of details about "People"s that aren't important
(do you care about eye color?  weight?  height?).  But, there is
nothing to prevent you from augmenting an existing set of
relations with, for example, a "Heights" relation that maps
a "People ID" to a specific "height" -- adding the field to
"People" is likely unjustified but a height can still be
associated with those People for whom it is important.

 
Again, all determined by intent, not technology.

When contacting Mr Smith, you'd likely want to know how to address
him ("Hi Bob!" vs. "Hello Mr. Smith").  So, a "Greetings" relation.
>
Do you recall the name of the nice lady at the insurance company
who helped you sort out that billing error?  Do you rely on your
memory?  Or, jot notes, somewhere?  (how do you access those
notes?)

By date.

The bottom line is Focus!

Joe