Hello All, I am having some problems modeling a relationship properly and
could use some advice. My final question is at the bottom of this post
(everything else is explanation). Basically what I have is a customer to
our company who can be either an individual or a company, each company may
have many employees (which are really individuals that work-for *or
are-related-to* a company), now for the problem: each individual, company
and company-contact may have multiple contact numbers, how can I stay
normalized and put all those numbers in one table? Ok I'll explain my
structures and relationships:
TABLE RELATIONSHIPS:
=============== =====
* tbl_Customer is a supertype to tbl_Individual and tbl_Company*
tbl_Customer 1:1 tbl_Individual
" " 1:1 tbl_Company
*tbl_CompanyCon atact is a junction table to support the N:N relationship for
company contacts*
tbl_CompanyCont act M:1 tbl_Individual
" " M:1 tbl_Company
TABLE STRUCTURES:
=============== ==
tbl_Customer (super-type table)
CustID - pk
CustType - 'I' or 'C' (to facilitate the sub-type)
tbl_Individual (sub-type table)
cCustID - pk (same as tbl_customer pk)
FirstName - string
LastName - string
tbl_Company (sub-type table)
cCustID - pk (same as tbl_customer pk)
CompanyName - string
Discount - single
tbl_CompanyCont acts (junction table)
IndividualID - composite pk
CompanyID - composite pk
Title - string
Final Structure Note:
Our customer can be either a company or an individual. If its a company
there will/can be many contacts. Contacts are also individuals (so they can
be customers either way). Everyone will have contact numbers (and numbers
will be different when an individual is with a company vs. by themselves)
My Real Question:
how do I add a tbl_ContactNumb ers that can be related to the individual,
company, and companycontact. where I see the problem is my
tbl_CompanyCont acts because it uses a composite key unlike the company or
individual tables so how can I stay normalized and only create one
tbl_ContactNumb ers that I can stuff all three sets of numbers in? Hope I
was clear. Any and all advice is always welcome.
Thanks,
Mike Krous
22  3753 
Mike, are individuals and companies both the same kind of entity?
For example, it seems to me that you make sales to individuals and to
companies, etc, etc, so they are both really "clients"?
If that makes sense, would you consider putting both into one table? Use an
IsCorporate yes/no field to distinguish whether this is an individual or
corporate entitiy.
This structure simplies the problem no end, and generates a very flexible
set of options for the relationships. One possibiltiy is to have
tblClientContac t table with *two* foreign keys to tblClient: one for the
company, and one for the individual. If the company is present but the
individual is not, it's a company phone number. If the individual is present
but not the company, it's a personal phone number. If both are present, the
number relates only to the individual in the context of their work at that
company.
There are heaps of other possibilities, including junction tables between
the two copies of the Client table. The junction table can define the role
the individual/company has with another individual/company (e.g. manager of
company, son of individual, or parent company of franchisee, etc.)
The only problem I had with this incredibly flexible set of relations was a
client who wanted to print out a flat-file listing of who was related to
whom. It wasn't worth what he wanted to pay to try to untangle the almost
infinite web of recursive relations that are possible with this structure.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Mike Krous" <m.krous@nospam _comcast.net> wrote in message
news:K_******** ************@co mcast.com... Hello All, I am having some problems modeling a relationship properly and
could use some advice. My final question is at the bottom of this post
(everything else is explanation). Basically what I have is a customer to
our company who can be either an individual or a company, each company may
have many employees (which are really individuals that work-for *or
are-related-to* a company), now for the problem: each individual, company
and company-contact may have multiple contact numbers, how can I stay
normalized and put all those numbers in one table? Ok I'll explain my
structures and relationships:
TABLE RELATIONSHIPS:
=============== =====
* tbl_Customer is a supertype to tbl_Individual and tbl_Company*
tbl_Customer 1:1 tbl_Individual
" " 1:1 tbl_Company
*tbl_CompanyCon atact is a junction table to support the N:N relationship
for company contacts*
tbl_CompanyCont act M:1 tbl_Individual
" " M:1 tbl_Company
TABLE STRUCTURES:
=============== ==
tbl_Customer (super-type table)
CustID - pk
CustType - 'I' or 'C' (to facilitate the sub-type)
tbl_Individual (sub-type table)
cCustID - pk (same as tbl_customer pk)
FirstName - string
LastName - string
tbl_Company (sub-type table)
cCustID - pk (same as tbl_customer pk)
CompanyName - string
Discount - single
tbl_CompanyCont acts (junction table)
IndividualID - composite pk
CompanyID - composite pk
Title - string
Final Structure Note:
Our customer can be either a company or an individual. If its a company
there will/can be many contacts. Contacts are also individuals (so they
can be customers either way). Everyone will have contact numbers (and numbers
will be different when an individual is with a company vs. by themselves)
My Real Question:
how do I add a tbl_ContactNumb ers that can be related to the individual,
company, and companycontact. where I see the problem is my
tbl_CompanyCont acts because it uses a composite key unlike the company or
individual tables so how can I stay normalized and only create one
tbl_ContactNumb ers that I can stuff all three sets of numbers in? Hope I
was clear. Any and all advice is always welcome.
Allen, thanks for the response. To answer your question as to wheter
individuals and companies are both the same kind of entity, The answer is
no. individuals have a first, middle, last name, a name prefix, name
suffix, and salutation fields to mention just a few, Companies have
CompanyName (one field), tax id, discount, companytype, defaultCarrier,
ect.. What you are describing is how I currently do it, however this setup
has its own neusences (i know thats not how its spelled :) for instance
populating company/individual combo boxes or running reports on name. those
are the ones I think of immediatly, I know the IsCorporate flag will allow
me to use if/thens to properly format the output but it has always seemed
undesirable. What I am really looking to do I suppose is to _Normalize_
this database as much as possible first then go ahead and back track as I
see necessary.
Mike
"Allen Browne" <Al*********@Se eSig.Invalid> wrote in message
news:3f******** **************@ freenews.iinet. net.au... Mike, are individuals and companies both the same kind of entity?
For example, it seems to me that you make sales to individuals and to
companies, etc, etc, so they are both really "clients"?
If that makes sense, would you consider putting both into one table? Use
an IsCorporate yes/no field to distinguish whether this is an individual or
corporate entitiy.
This structure simplies the problem no end, and generates a very flexible
set of options for the relationships. One possibiltiy is to have
tblClientContac t table with *two* foreign keys to tblClient: one for the
company, and one for the individual. If the company is present but the
individual is not, it's a company phone number. If the individual is
present but not the company, it's a personal phone number. If both are present,
the number relates only to the individual in the context of their work at that
company.
There are heaps of other possibilities, including junction tables between
the two copies of the Client table. The junction table can define the role
the individual/company has with another individual/company (e.g. manager
of company, son of individual, or parent company of franchisee, etc.)
The only problem I had with this incredibly flexible set of relations was
a client who wanted to print out a flat-file listing of who was related to
whom. It wasn't worth what he wanted to pay to try to untangle the almost
infinite web of recursive relations that are possible with this structure.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
After a second read of your post, I have some questions. If that makes sense, would you consider putting both into one table? Use
an IsCorporate yes/no field to distinguish whether this is an individual or
corporate entitiy.
Isn't my structure pretty much the same as yours up to the point of phone
numbers. All I did different is subtype the company and individual data.
They are both of the same primary-key-scope of the super-type table
tbl_Customers and I use a field in the tbl_Customers table I=individual
C=Company. I guess my point is, isnt that the same as yours just less empty
fields?
There are heaps of other possibilities, including junction tables between
the two copies of the Client table. The junction table can define the role
the individual/company has with another individual/company (e.g. manager
of company, son of individual, or parent company of franchisee, etc.)
thats what my tbl_CompanyCont acts table does, however my problem is its
primary key is a composite key so I have a hard time relating it and other
tables (with single pk's) to another table.
One possibiltiy is to have
tblClientContac t table with *two* foreign keys to tblClient: one for the
company, and one for the individual. If the company is present but the
individual is not, it's a company phone number. If the individual is
present but not the company, it's a personal phone number. If both are present,
the number relates only to the individual in the context of their work at that
company.
This is exactly what I tried to do, so I made a table
tbl_ContactNumb ers
NumberID - pk (allows for 1:N relationships)
individualID - fk individual table
CompanyID - fk company table
number - string
type - long (uses lookup table)
now how do I enforce referential integrity with this? Or do I not?
I tried to relate the tbl_CompanyCont acts to tbl_ContactNumb ers on both fk's
and create another relationship from tbl_Customers to just the IndividualID
of tbl_ContactNumb ers. however this would not allow me to enter data in the
table becuase It wanted a related record in both tables which could not be
the case if I used only a value in IndividualID and left CompanyID 0 (to
show individual number).
Mike Krous
"Allen Browne" <Al*********@Se eSig.Invalid> wrote in message
news:3f******** **************@ freenews.iinet. net.au... Mike, are individuals and companies both the same kind of entity?
For example, it seems to me that you make sales to individuals and to
companies, etc, etc, so they are both really "clients"?
If that makes sense, would you consider putting both into one table? Use
an IsCorporate yes/no field to distinguish whether this is an individual or
corporate entitiy.
This structure simplies the problem no end, and generates a very flexible
set of options for the relationships. One possibiltiy is to have
tblClientContac t table with *two* foreign keys to tblClient: one for the
company, and one for the individual. If the company is present but the
individual is not, it's a company phone number. If the individual is
present but not the company, it's a personal phone number. If both are present,
the number relates only to the individual in the context of their work at that
company.
There are heaps of other possibilities, including junction tables between
the two copies of the Client table. The junction table can define the role
the individual/company has with another individual/company (e.g. manager
of company, son of individual, or parent company of franchisee, etc.)
The only problem I had with this incredibly flexible set of relations was
a client who wanted to print out a flat-file listing of who was related to
whom. It wasn't worth what he wanted to pay to try to untangle the almost
infinite web of recursive relations that are possible with this structure.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Mike Krous" <m.krous@nospam _comcast.net> wrote in message
news:K_******** ************@co mcast.com... Hello All, I am having some problems modeling a relationship properly
and could use some advice. My final question is at the bottom of this post
(everything else is explanation). Basically what I have is a customer
to our company who can be either an individual or a company, each company
may have many employees (which are really individuals that work-for *or
are-related-to* a company), now for the problem: each individual,
company and company-contact may have multiple contact numbers, how can I stay
normalized and put all those numbers in one table? Ok I'll explain my
structures and relationships:
TABLE RELATIONSHIPS:
=============== =====
* tbl_Customer is a supertype to tbl_Individual and tbl_Company*
tbl_Customer 1:1 tbl_Individual
" " 1:1 tbl_Company
*tbl_CompanyCon atact is a junction table to support the N:N relationship
for company contacts*
tbl_CompanyCont act M:1 tbl_Individual
" " M:1 tbl_Company
TABLE STRUCTURES:
=============== ==
tbl_Customer (super-type table)
CustID - pk
CustType - 'I' or 'C' (to facilitate the sub-type)
tbl_Individual (sub-type table)
cCustID - pk (same as tbl_customer pk)
FirstName - string
LastName - string
tbl_Company (sub-type table)
cCustID - pk (same as tbl_customer pk)
CompanyName - string
Discount - single
tbl_CompanyCont acts (junction table)
IndividualID - composite pk
CompanyID - composite pk
Title - string
Final Structure Note:
Our customer can be either a company or an individual. If its a company
there will/can be many contacts. Contacts are also individuals (so they
can be customers either way). Everyone will have contact numbers (and
numbers will be different when an individual is with a company vs. by
themselves)
My Real Question:
how do I add a tbl_ContactNumb ers that can be related to the individual,
company, and companycontact. where I see the problem is my
tbl_CompanyCont acts because it uses a composite key unlike the company
or individual tables so how can I stay normalized and only create one
tbl_ContactNumb ers that I can stuff all three sets of numbers in? Hope
I was clear. Any and all advice is always welcome.
On Wed, 12 Nov 2003 06:17:02 -0800, "Mike Krous"
<m.krous@nospam _comcast.net> wrote: TABLE STRUCTURES:
============== ===
tbl_Customer (super-type table)
CustID - pk
CustType - 'I' or 'C' (to facilitate the sub-type)
tbl_Individu al (sub-type table)
cCustID - pk (same as tbl_customer pk)
FirstName - string
LastName - string
tbl_Company (sub-type table)
cCustID - pk (same as tbl_customer pk)
CompanyName - string
Discount - single
I think you have this backwards.
"Customer" usually describes a relationship between a seller and a
buyer. The seller is almost always an organization (even if it's a
sole proprietor with no employees). In most business databases, the
seller isn't recorded at all--it's just understood to be "my company".
The buyer might be either an individual or an organization.
Since individuals and organizations are not entirely the same (duh),
but are not entirely different (they participate in many of the same
relationships), then they are likely subtypes of something. (You were
right about this.)
But "customer" describes a relationship that both individuals and
organizations can participate in. That's one clue. In data modeling,
a supertype is more general or more abstract than its subtypes.
"Customer" isn't more general or abstract than either "individual " or
"organizati on". That's another clue. "Customer" isn't the supertype.
"Parties" is what you're looking for.
Let's say [Parties] is a supertype, containing all the attributes
common to both individuals and organizations. At the very least,
[Parties] will include the name by which the party is known to your
organization, and the type of party it is, say "Ind" for individuals,
"Org" for organizations. [Orgs] contains all the attributes unique to
organizations; [Inds] contains all the attributes unique to
individuals.
Parties generally have addresses, phone numbers, and so on. And
parties in the real world exist independently of wheither they're your
customers. (So you can record information about them as it comes to
hand, not just when they decide to buy something from you.)
I think you should be careful about modeling personnel and contacts.
Many common assumptions are mistaken. (For example, that everyone who
works "for" a company is an employee; some might be independent
contractors or temp agency help.) In general, though, an employer is
an organization, and personnel are individuals. So [Personnel] would
include one foreign key reference to [Orgs] and another foreign key
reference to [Inds].
That enough to get you started?
--
Mike Sherrill
Information Management Systems
> I think you have this backwards.
hmm...sounds a bit extreme for the examples you have provided. "Customer" usually describes a relationship between a seller and a
buyer. The seller is almost always an organization (even if it's a
sole proprietor with no employees). In most business databases, the
seller isn't recorded at all--it's just understood to be "my company".
The buyer might be either an individual or an organization.
that is what im modeling, my _customers_. I never said anything about
tracking the seller. You are correct the buyer may be a individual or
organization but both of those are my _customer_ hence the super-type table
"customer".
Since individuals and organizations are not entirely the same (duh),
but are not entirely different (they participate in many of the same
relationships), then they are likely subtypes of something. (You were
right about this.)
then they are likely subtypes of something.
yes of a _Customer_ as I see it, or a "Party" if you want to call it that,
but I believe that title is so vague.
But "customer" describes a relationship that both individuals and
organizations can participate in. That's one clue. In data modeling,
a supertype is more general or more abstract than its subtypes.
"Customer" isn't more general or abstract than either "individual " or
"organizati on". That's another clue. "Customer" isn't the supertype.
I have to respectfully disagree, a _customer_ with no further description
IS a more generic than the specific type of customer i.e. Individual or
Organization
"Parties" is what you're looking for.
Ok, for the sake of argument lets say I call it "Parties", that didnt change
my structures at all. (or my original problem for that matter)
Let's say [Parties] is a supertype, containing all the attributes
common to both individuals and organizations. At the very least,
[Parties] will include the name by which the party is known to your
organization, and the type of party it is, say "Ind" for individuals,
"Org" for organizations. [Orgs] contains all the attributes unique to
organizations; [Inds] contains all the attributes unique to
individuals.
with the exception of a common name field in the Customer/Parties table
(which I dont see why I would want anyway) this is exactly what I do, so
exactly what are you telling me here? To change my name to "Parties"?
Parties generally have addresses, phone numbers, and so on. And
parties in the real world exist independently of wheither they're your
customers. (So you can record information about them as it comes to
hand, not just when they decide to buy something from you.)
I suppose in a theoretical sense you are correct here, however I wont care
about these people until they are a customer, so I again dont see the big
issue on using the name "Parties", its only a name, it hasnt changed
anything else within my design. Ok, so I call it "Parties," now what?
I think you should be careful about modeling personnel and contacts.
Many common assumptions are mistaken. (For example, that everyone who
works "for" a company is an employee; some might be independent
contractors or temp agency help.) In general, though, an employer is
an organization, and personnel are individuals. So [Personnel] would
include one foreign key reference to [Orgs] and another foreign key
reference to [Inds].
Ok, so the first real suggestion I've heard from you. This would be an
extremely rare case if one organization acted on the behalf of another but I
suppose this could happen. I will take another look at my structures and
see how I could apply this to my situation.
Don't get me wrong, I do appreciate your suggestions, I guess I really have
never cared for generalized, wreckless, negligent comments such as the one
you started your post with. I'd say you have given me nothing more than a
subjective suggestion (which I do appreciate). I wouldn't say I have it
backwards at all, I'd say I have some standing issues with my start to a
normalized structure.
Mike Krous
"Mike Sherrill" <MS************ *@compuserve.co m> wrote in message
news:jm******** *************** *********@4ax.c om... On Wed, 12 Nov 2003 06:17:02 -0800, "Mike Krous"
<m.krous@nospam _comcast.net> wrote:
TABLE STRUCTURES:
============== ===
tbl_Customer (super-type table)
CustID - pk
CustType - 'I' or 'C' (to facilitate the sub-type)
tbl_Individu al (sub-type table)
cCustID - pk (same as tbl_customer pk)
FirstName - string
LastName - string
tbl_Company (sub-type table)
cCustID - pk (same as tbl_customer pk)
CompanyName - string
Discount - single
I think you have this backwards.
"Customer" usually describes a relationship between a seller and a
buyer. The seller is almost always an organization (even if it's a
sole proprietor with no employees). In most business databases, the
seller isn't recorded at all--it's just understood to be "my company".
The buyer might be either an individual or an organization.
Since individuals and organizations are not entirely the same (duh),
but are not entirely different (they participate in many of the same
relationships), then they are likely subtypes of something. (You were
right about this.)
But "customer" describes a relationship that both individuals and
organizations can participate in. That's one clue. In data modeling,
a supertype is more general or more abstract than its subtypes.
"Customer" isn't more general or abstract than either "individual " or
"organizati on". That's another clue. "Customer" isn't the supertype.
"Parties" is what you're looking for.
Let's say [Parties] is a supertype, containing all the attributes
common to both individuals and organizations. At the very least,
[Parties] will include the name by which the party is known to your
organization, and the type of party it is, say "Ind" for individuals,
"Org" for organizations. [Orgs] contains all the attributes unique to
organizations; [Inds] contains all the attributes unique to
individuals.
Parties generally have addresses, phone numbers, and so on. And
parties in the real world exist independently of wheither they're your
customers. (So you can record information about them as it comes to
hand, not just when they decide to buy something from you.)
I think you should be careful about modeling personnel and contacts.
Many common assumptions are mistaken. (For example, that everyone who
works "for" a company is an employee; some might be independent
contractors or temp agency help.) In general, though, an employer is
an organization, and personnel are individuals. So [Personnel] would
include one foreign key reference to [Orgs] and another foreign key
reference to [Inds].
That enough to get you started?
--
Mike Sherrill
Information Management Systems
On Tue, 18 Nov 2003 01:05:17 -0800, "Mike Krous"
<m.krous@nospam _comcast.net> wrote:
[snippage throughout] I think you have this backwards.hmm...sounds a bit extreme for the examples you have provided.
If your thinking is backward--and it *is* backward--then you've simply
put the cart before the horse, and that's easy to fix.
that is what im modeling, my _customers_. I never said anything about
tracking the seller.
I said essentially the same thing--that most business databases don't
record the seller. That doesn't mean the seller doesn't exist, and it
doesn't mean the seller is irrelevant to logical data analysis.
You are correct the buyer may be a individual or
organization but both of those are my _customer_ hence the super-type table
"customer".
[snip remainder]
"Supertype" and "subtype" have a pretty specific meaning in relational
systems. You seem to have misunderstood what "supertype" means.
"Customer" is a supertype of the mutually exclusive subtypes
"individual s" and "organizati ons" if and only if
1) every individual is a customer, and
2) every organization is a customer
While this might be every seller's dream, it's not true in the real
world. Fabian Pascal's book _Practical Issues in Database Management_
has a pretty good treatment of supertype/subtype issues.
--
Mike Sherrill
Information Management Systems
The only thing I hear from you is squabling over the word I chose to use for
my Supertype table and _yes_ it is a supertype table. Other than that I
have heard nothing productive, thanks for trying.
Mike Krous
"Mike Sherrill" <MS************ *@compuserve.co m> wrote in message
news:25******** *************** *********@4ax.c om... On Tue, 18 Nov 2003 01:05:17 -0800, "Mike Krous"
<m.krous@nospam _comcast.net> wrote:
[snippage throughout] I think you have this backwards.
hmm...sounds a bit extreme for the examples you have provided.
If your thinking is backward--and it *is* backward--then you've simply
put the cart before the horse, and that's easy to fix.
that is what im modeling, my _customers_. I never said anything about
tracking the seller.
I said essentially the same thing--that most business databases don't
record the seller. That doesn't mean the seller doesn't exist, and it
doesn't mean the seller is irrelevant to logical data analysis.
You are correct the buyer may be a individual or
organization but both of those are my _customer_ hence the super-type
table"customer".
[snip remainder]
"Supertype" and "subtype" have a pretty specific meaning in relational
systems. You seem to have misunderstood what "supertype" means.
"Customer" is a supertype of the mutually exclusive subtypes
"individual s" and "organizati ons" if and only if
1) every individual is a customer, and
2) every organization is a customer
While this might be every seller's dream, it's not true in the real
world. Fabian Pascal's book _Practical Issues in Database Management_
has a pretty good treatment of supertype/subtype issues.
--
Mike Sherrill
Information Management Systems
"Mike Krous" <m.krous@nospam _comcast.net> wrote in message
news:UO******** ************@co mcast.com... I think you have this backwards. hmm...sounds a bit extreme for the examples you have provided.
"Customer" usually describes a relationship between a seller and a
buyer. The seller is almost always an organization (even if it's a
sole proprietor with no employees). In most business databases, the
seller isn't recorded at all--it's just understood to be "my company".
The buyer might be either an individual or an organization.
that is what im modeling, my _customers_. I never said anything about
tracking the seller. You are correct the buyer may be a individual or
organization but both of those are my _customer_ hence the super-type
table "customer".
Since individuals and organizations are not entirely the same (duh),
but are not entirely different (they participate in many of the same
relationships), then they are likely subtypes of something. (You were
right about this.)then they are likely subtypes of something.
yes of a _Customer_ as I see it, or a "Party" if you want to call it
that, but I believe that title is so vague.
But "customer" describes a relationship that both individuals and
organizations can participate in. That's one clue. In data modeling,
a supertype is more general or more abstract than its subtypes.
"Customer" isn't more general or abstract than either "individual " or
"organizati on". That's another clue. "Customer" isn't the supertype. I have to respectfully disagree, a _customer_ with no further description
IS a more generic than the specific type of customer i.e. Individual or
Organization
"Parties" is what you're looking for.
Ok, for the sake of argument lets say I call it "Parties", that didnt
change my structures at all. (or my original problem for that matter)
If there are individuals that can exist in your system without being a
customer then individual is not a sub-type of customer. In your case
that is an individual that exists solely as a contact for a company.
The company is the customer, not the individual. Individual is not
a sub-type of Customer.
If you're thinking that the individual is the customer acting on behalf
of the company, then the company is not a customer. Company is
not a sub-type of Customer.
Company and Individual can be a customer.
Individual can be a CompanyContact.
>> Parties generally have addresses, phone numbers, and so on. And parties in the real world exist independently of wheither they're your
customers. (So you can record information about them as it comes to
hand, not just when they decide to buy something from you.)I suppose in a theoretical sense you are correct here, however I wont care
about these people until they are a customer, so I again dont see the big
issue on using the name "Parties", its only a name, it hasnt changed
anything else within my design. Ok, so I call it "Parties," now what?
Ok, as ive said, yes Parties is technically more correct, I agree. I am
building an order entry system and for what we are doing "customer" seemed
just fine....Yes "Party" is actually more correct (that's how I learned
super/sub typing)...That however, does nothing for my original question, and
as a result changed nothing more than my table name from tbl_Customers to
tbl_Parties.... ok, now what? I still have the same problem I had to start
with. I have tried to look at this in a more philosophical way, thinking I
was being told to look deeper into the reason behind why I call it what I
call it. That's good and fair, maybe im missing the boat here but as far as
I could see it, it didn't come close to answering my particular question,
guess I was hoping for a response a little closer to my question. For
example Allen Browne, he did an excellent job of giving me a suggestion and
he was focused on my problem, it was much appreciated. As far as I could
gather Mike was essentially telling me that I had it "backwards" to change
my table name to "Parties". As best as I could read from his post that was
supposed to make my problem magically disappear.
Mike
"rkc" <rk*@yabba.dabb a.do.rochester. rr.bomb> wrote in message
news:Zm******** ************@tw ister.nyroc.rr. com...
"Mike Krous" <m.krous@nospam _comcast.net> wrote in message
news:UO******** ************@co mcast.com... I think you have this backwards.
hmm...sounds a bit extreme for the examples you have provided.
"Customer" usually describes a relationship between a seller and a
buyer. The seller is almost always an organization (even if it's a
sole proprietor with no employees). In most business databases, the
seller isn't recorded at all--it's just understood to be "my company".
The buyer might be either an individual or an organization.
that is what im modeling, my _customers_. I never said anything about
tracking the seller. You are correct the buyer may be a individual or
organization but both of those are my _customer_ hence the super-type
table "customer".
Since individuals and organizations are not entirely the same (duh),
but are not entirely different (they participate in many of the same
relationships), then they are likely subtypes of something. (You were
right about this.)
then they are likely subtypes of something.
yes of a _Customer_ as I see it, or a "Party" if you want to call it
that, but I believe that title is so vague.
But "customer" describes a relationship that both individuals and
organizations can participate in. That's one clue. In data modeling,
a supertype is more general or more abstract than its subtypes.
"Customer" isn't more general or abstract than either "individual " or
"organizati on". That's another clue. "Customer" isn't the supertype.
I have to respectfully disagree, a _customer_ with no further
description IS a more generic than the specific type of customer i.e. Individual or
Organization
"Parties" is what you're looking for.
Ok, for the sake of argument lets say I call it "Parties", that didnt
change my structures at all. (or my original problem for that matter)
If there are individuals that can exist in your system without being a
customer then individual is not a sub-type of customer. In your case
that is an individual that exists solely as a contact for a company.
The company is the customer, not the individual. Individual is not
a sub-type of Customer.
If you're thinking that the individual is the customer acting on behalf
of the company, then the company is not a customer. Company is
not a sub-type of Customer.
Company and Individual can be a customer.
Individual can be a CompanyContact.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: MLH |
last post by:
I use a mouse-down procedure to trap right mouse
clicks and CTRL-Right mouse clicks. Running the
procedure must put honey or some other sticky
substance into my keyboard because subsequent
RightMouseClicks run as if they were CTRL-RightMouseClicks
I have to close the form and reopen it to clear this
behavior. Then, after the first CTRL-RightMouseClick,
it starts all over again.
|
by: Astronomically Confused |
last post by:
using System;
using System.Collections;
using System.IO;
using System.Net;
using System.Net.Sockets;
using System.Threading;
class HttpProcessor
{
private Socket s;
|
by: Crutcher |
last post by:
I've been playing with dictionary subtypes for custom environments,
and I encountered a strange interaction between exec, dictionary
subtypes, and global variables. I've attached a test program, but
first I'd like to give some background.
Python uses dictionary objects as symbol tables in it's execution
contexts. Since these objects used to be basic types, which were not
subclassable, some of the interpreter code accessed them using...
|
by: red floyd |
last post by:
Does anyone know if C++0x will address the issue of enumerated subtypes?
That is, if I have an enum, and want a type-compatible subtype of it....
Something along the lines of
enum Day {
Sunday,
Monday,
Tuesday,
|
by: Bernard Dhooghe |
last post by:
The (limited to propagatable since version 9) log records are described
in the API reference manual.
What is meant by: normal/undo/redo/compensation records, what are the
possible subtypes for each of these record, what events trigger there
creation and when are they propagatable?
Remark: I believe this should be part of the documentation.
| | |
by: Samuel |
last post by:
Hi,
I remember seeing an easy way to list all subtypes of a specific type
but I haven't been able to find it anymore. What I am trying to do is
this: Given a class, get a list of all classes that derive from it.
Pretty much like __mro__ but downwards rather then upwards. Any ideas?
-Samuel
|
by: nflacco |
last post by:
Is there a convient way to do a supertype/subtype heirarchy in mysql
and do queries on the supertype to return sets of subtypes?
For example, suppose I have a table with several types of military
hardware:
Table:
Id----Type--------Price
1.....Mig-15.....$20
1.....Mig-17.....$32
|
by: xsnox |
last post by:
anyone??
am trying to create a database (mysql) from a super type subtype relation. my question is how do i create the tables with the right constrain (PK, FK)
here is the proposed tables t
t1 Parts with fields part_no, description, location, manufactured?, purchased?
t2 Manucfatured_part........ with fields.......M-part_no, routing_no
t3 Purchased_part .........with fields........P_part_no, purchase_date
t4 ...
|
by: msjonathan |
last post by:
Hej hej,
I have some classes like this:
Resource
|
Person
/ \
Employee Visitor
Somewhere in my program I do like this: entity.GetType() (entity is type of Employee).
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
