I have a database design requirement that is getting increasingly complex for me to figure the best way of approaching.
Currently, I have "contacts", and I have "companies". A company can have multiple contacts, but a contact can only belong to one company. This makes an obvious 1:n relationship. However, a contact does not have to have a company; mainly a residential/non-business customer (thus would be referred to as a "customer" on the front-end). This turns it into a 0:n relationship it seems.
The contacts table has a simple foreign key to the id of the companies table to establish this relationship.
The problem comes with storing addresses and phone numbers. Currently, the contacts table and companies table both store a single address and two phone numbers each (static columns). In most cases, the software simply mirrors the same data in both tables; the "company" data is shown as prevalent when it is available (aka the customer does not have the id of "0" for its company). This causes some confusion to the end user, and also has severe limitations.
I am in need of revamping this design in order to store multiple addresses (billing, ship to, etc), and of course as many phone numbers as I want. This is especially for companies that may have multiple facilities and one central billing office of course.
At first, I think of making the 1:n for the addresses against the companies table; however, the contacts also needs its potential separate data. This mostly gets complicated since a contact, as mentioned before, does not have to have a company, and could be a stand-alone. The company needs a master list of addresses for probably billing purposes, then the contact may need their own list of addresses for service and such. Or, the company could simply have all the addresses (could be best for statistics), and then the contact has only their primary address or something.
How can I go about putting this all together? Do I have one table for all contact/company addresses, or do I need seperate tables (contacts_addresses and companies_addresses)? I will of course use the same strategy for phone numbers.
The more I research, the more I get confused to be honest with so many answers and approaches. The leading one so far for my application sounds like this question. According to this, should I have the 1:n relationship with the companies table, and then a simple 1:1 relationship for the contacts? If this is the case, do I have contacts refer to the same table (and have a dropdown of the addresses linked with their company for a choice, and an option to make a new one), or have simple static columns in the contacts table?
An individual and an organization are concrete representations of an abstract Legal Party (This is called the Party Model).
Individual : Party
Organization : Party
An email address, web address, phone number, physical address can be thought of concrete representations of an abstract address.
EmailAddress : Address
WebAddress : Address
PhoneNumber : Address
PhysicalAddress : Address
An address can be unoccupied. A person can have multiple addresses. Multiple people can share one address.
Therefore there is a many-to-many relationship between Party and Address:
Party -< ContactMethod >- Address
Where ContactMethod has a role label, such as "Work", "Home", etc. The more specialized PhoneContactMethod might have an Extension column.
Related
I am trying to model as much of the data as possible for a new app before starting. The app will have Users & Spaces. The Spaces will have a number of Admin levels but will also have non-admin Members. The Space will associate Admins through space_roles/space_admins join table (name depends on the design decision I am trying to make). I am using a Role model to create the association between Spaces and Admins. This means the the space_roles table will be a three way join with user_id, space_id and role_id columns.
I plan to eventually build a bunch of tools around Spaces that the Members will have access to. These might not necessarily be restricted to Members of a certain Space. There most likely will be cases further down the road where Members of one Space can interact across organizational boundaries with Members of another Space using the Space as the scope (e.g. a fan of one sports team could join in on a discussion on the wall of another sports team where sports team is an analogy for Space).
My question is should I just create another Role called 'member' or should I break members out into another model (Member?) with an association through space_members? Please explain the advantages/disadvantages of your recommendation as best as possible.
If your Admin users are a subset of your Users, and it's possible for Users to become, or stop being, Admins, then keep them in the same table.
If your users (admins or not) can participate in more than one of your spaces, you probably want a single users table, and a separate users_spaces join table. That table might have this layout.
user_id part of the primary key
space_id the rest of the primary key
role 1 = contributor to the space, 2=member, 3=admin 4=owner etc
If users and admins are entirely distinct sets of people, then use two two tables and keep them separate. For example, if you were doing health care, and they were Nurses and Patients, you would definitely keep them separate, because they are subject to different confidentiality rules.
I am building a database on Access that, among other things, tracks who has referred patients to our office (I work in an optometrist's office which does a specialized kind of therapy).
I don't have much experience creating relational databases, and I am wondering if I'm heading the right direction. Before posting here, I've asked 5 of my computer programmer friends for help, but suddenly every is busy... So here goes.
1 patient can have Many referrals
my son's teacher and my coworker referred me here (2 referring
sources)
my doctor told me about you, and then I saw your website (2 referring
sources)
1 referral can consist of:
an individual (Dr Blah-Blah, or My Friend Jane Doe)
an organization (Doctors Group)
an individual that is part of an organization (Dr. So-and-So from Doctors
Group)
a media source (website, pamphlet, commercial, tv show, etc)
Often it's not possible to determine which individual at an organization referred the patient (because patients can't remember), so only the organization is recorded. But sometimes it is possible, so the individual and the organization are recorded. And sometimes individuals are not part of any organization.
This is the partial design that I came up with: http://postimg.org/image/uipaq7rrl/
Patients Table
Referring Media Table
stores details of media sources
Referring Organization Table
stores the names/details of organizations
Referring Individuals Table
stores names/details of individuals
uses Ref Org ID as a foreign key, in case individuals are members of an organization
Referrals Table
uses the Patient ID as a foreign key to link the referrals to the patients
How should I link the Referrals Table to the Ref Org, Ref Indv, and Ref Media tables?
I came up with something like this: http://postimg.org/image/qtpoiflmv/
But that seems redundant and leaves a lot of blank spaces, depending on the type of referral: http://postimg.org/image/oepj99ohz/
What should I do? What is a good way to build relationships between these tables?
without even thinking or getting involved, if you see spaces like that, looks like you need a table with referral types
I checked this question here but unfortunately the link to the diagram in not working so I'm stuck.
I am trying to have multiple emails for one user (work, business, personal, etc) and I'm not sure how to best approach this situation.
I am thinking to have 4 tables: user, email, email_type, and user_has_email (user N:M email).
I made two diagrams but I don't know which one would be the better one.
First diagram helps me if one user has the same email for both work and personal (because I don't have to store it twice). Second option is good as well but I would have to store emails twice or more even if one user uses the same email for work, business, personal, etc.
I am planning to use the same idea for storing addresses, which occupy more space than emails and I am thinking that the diagram 1 is more suitable for this.
What do you think?
Diagram 1
-explanation of user_has_email: I chose to make the email_type PK because there may be the case when a user has the same email for work or personal. If I don't PK the email_type I would only be able to have one email_type per user. Did I complicated it too much?
Diagram 2
Instead I would use
user (user_id, first_name, last_name)
user_emails (user_id, email_type_id, email)
email_types (email_type_id, email_type)
I would prefer Diagram 1 for the following reasons.
You can make the email field UNIQUE so that you can store it only once regardless of the type.
It does not seem right to make the email and the email type tightly coupled, if you face a situation where you have to establish a one-to-one relationship between the user and the email for some other feature.
Any kind of validation for the user-email relationship should be handled in the business logic (even if you have constraints in the database).
The following structure should fit the bill:
There is a 1:N relationship between users and e-mails, and each user's e-mail can have zero or more types, from the set of shared types.
If the e-mail types don't need to be shared among users, the model can be further simplified:
BTW, the case for using M:N for addresses is not clear either, due to the inherent "fuzziness" of addresses - see this post for some musings on the subject.
Consider my scenario of a model consisting of two aggregate roots, Customer and Order as well as a "shared" entity Address.
Also note that Address is abstract has the following subclasses: PhysicalAddress, PostOfficeBoxAddress and PrivateBagAddress.
A Customer can have many addresses organized into some sort of address book.
Upon making an order a customer would select an Address from their address book to be used as a delivery address.
My initial thoughts were to share an address between the two entities, but I have since opted out as it will cause trouble with managing the respective invariants.
Another option I could go for is to create two hierarchies of Address, each for their purposes as a customer address or delivery address. This again doesn't seem right as there is a lot of repeated code.
How would I model this situation properly?
An entity is something that should be able to exist by ifself such as a customer or order. However an Address is not an entity, an Address is a value type and cannot exist on its own hence:
An Address can only exist as a value type that is aggregated within an entity
You can define your address hierarchy as a value type in your domain but many entities may use this.
We find that we come across these types of entities all the time such as Address, MoneyType etc.
Solution would be to create 1 Address hierarchy value type in your domain. Then any entity can have an Address as a property where applicable
I'm trying to figure out the best way to design these tables for a website I'm making for a school club. I want to set it up so each user can have multiple emails, phone numbers, and addresses tied to their account. To do this I tried to tie all these things to a contacts table and store the contacts id in the users table as a foreign key. The contacts id is also a foreign key in the emails, phone numbers, and addresses table. Is this a feasible way of relating these tables or should I just cut out the middle man (contacts table) and store the user id in the emails, phone numbers, and addresses tables?
Just in case my description of the relationships weren't enough, here is an ERD for the tables:
Sorry for such a "noob" question, it's been a while since I had to build a database with more complexity than 2 tables. Any general tips for database design are very much welcomed as well.
All you need to do is remove the Contacts table and store the user_id in the tables on the right, rather than contact_id.
Remove contact_id from Users as well.
I have dealt with this very question in the past. We did it wrong and we were sorry.
The determining factors should be these:
Will you have any other category of person that isn't a user, for whom you need to store contact information?
Will those kinds of persons somehow be "fungible" with users?
If you answer both these questions "yes," keep your contact table. Otherwise get rid of it.
The mistake made by a team I worked on was our answer to the second question. We had medical patients and doctors/nurses/etc as our categories of people. We stored their contact information together. But we shouldn't have done that because patients' contact information is very sensitive and confidential, but health care provider information is much less so. We were always wishing we didn't have the two kinds of data in just one set of tables after the system became successful.
Unless you can convince yourself you need your contact table, get rid of it, I say!
Yes I would cut out the midle man:
Although I was tempted to go the 'contact_type' route, I have found that there are usually validations and different data types which become more complicated when the contact is generic. For instance a table that has address fields is not the same as a phone number and having both presents more complexity and less readability.
This model focuses on simplicity, e.g. a user has many emails and an email belongs ot a user.
According to me you can design DB accordingly
Table 1 : Users
UserID //PK
Name
Table 2 : Contacts
ContactID //PK
UserID //FK to Users
ContactTypeID // FK to ContactType
Value
Table 3 : ContactType
ContactTypeID //PK
ContactTypeName
Description
Table 1 is pretty clear stores user information
Table 3 holds information about contacttype i.e email, home phone, mobile, home address, shipping address, etc
Table 2 holds information about user, contact type and its value
like cinatacttypeid corresponds to mobile than value is , etc.