Re: RDBMS design issue

Liste des GroupesRevenir à se design 
Sujet : Re: RDBMS design issue
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.design
Date : 08. Jul 2025, 18:18:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <104jjto$3m3m5$2@dont-email.me>
References : 1 2
User-Agent : Mozilla Thunderbird
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"?
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.
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?)

Date Sujet#  Auteur
8 Jul03:32 * RDBMS design issue15Don Y
8 Jul09:41 +* Re: RDBMS design issue2Liz Tuddenham
8 Jul17:58 i`- Re: RDBMS design issue1Don Y
8 Jul15:31 `* Re: RDBMS design issue12Joe Gwinn
8 Jul18:18  `* Re: RDBMS design issue11Don Y
8 Jul18:59   `* Re: RDBMS design issue10Joe Gwinn
8 Jul19:28    `* Re: RDBMS design issue9Don Y
8 Jul19:58     +* Re: RDBMS design issue5Joe Gwinn
8 Jul22:06     i`* Re: RDBMS design issue4Don Y
9 Jul19:40     i `* Re: RDBMS design issue3Joe Gwinn
9 Jul19:56     i  `* Re: RDBMS design issue2Don Y
9 Jul20:44     i   `- Re: RDBMS design issue1Joe Gwinn
9 Jul09:15     `* Re: RDBMS design issue3Liz Tuddenham
9 Jul18:28      +- Re: RDBMS design issue1Joe Gwinn
9 Jul18:51      `- Re: RDBMS design issue1Don Y

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal