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
Related
I want to design a web application for keeping track of the finance of the members of an organization. Certain functions are very similar to Splittr. I define my requirements using the MWE database diagrams:
"Finance" tables: Each user will have one personal finance account, for which I am using the following three red tables:
"SharedExpense" tables: Each user can have shared expenses with other users in many 'shared-expense-groups'. For each group, I am using the following three blue tables:
(Note how each user can define amount of their share, and own category of the shared expense. UserShare table uses a composite primary key.)
The problem: I have to relate the users to their 3 personal "Finance" tables and the 3N "SharedExpense" tables (where N is the number of 'shared-expense-groups' the user belongs to).
Attempted Solutions:
Multiple databases. Each user has a unique database for their "Finance" tables. Each 'shared-expense-group' has a unique database on the server. I can then relate the users from one master database with the following four purple tables:
Drawbacks: Foreign keys come from different databases, large number of databases to be backed up.
Multiple tables. I can create all the tables in the same database and relate all of them with the four green master tables:
Here, the number of tables is a potential problem. If there are M users and N 'shared-expense-groups, then there will be 3M + 3N tables!
The question: Is there more elegant and simpler database design for the purpose? If not, which of the above two solutions is better and why?
Links to relevant, previous StackOverflow Q&A:
Personal finance app database design
Database design for tracking progress over time
SQL for a Household Bill splitting db
Comparing 1 Database with Many Tables to Multiple Databases with Fewer Tables in Each
There is to much to describe all the challenges in a summary, but I'll pick out a few.
Fundamental design violations: such as a table/database for each user
entity design, 3NF: such as category.budget and ledger.transaction_type
referential integrity/relationship design:
account is for one user, but account table does not contain the user id;
usershare is a subset of ledger, but they both point to a user;
object naming concerns:
clear and consistent naming entities, based on real usage. Is a member a user or a user a member? If they are the same, choose one name. If they are not the same, the design is different. Do staff use client or customer rather than member?
consistency in your key naming. The key name should directly tie it to the source entity. Members.ID should be referenced as members_id, rather than user_id. However, see the next entry before correcting this.
be consistent in your entity plurality. The general consensus is that the name should describe a single record (User) rather than all the records (Users).
ledger.spent_on - that name is not obviously a date. It could be pointing to a user or category as well. An attribute name should describe the attribute without needing additional explanation. For example, ledger.Purchase_Date is self explanatory. It should also be clear how it relates to the entity. UserShare.Share doesn't really tell me what it contains.
Sorry to be blunt, but I would start over. Consider what you have as a good trial run and start again using the additional information you have.
Ask questions of your designs (Are all users members? Are all members users?). If the answer is anything other than Yes or No, break it down further.
Try what-if scenarios (What if a shared ledger exceeds the category budget? How will previous spending be perceived if the category budget changes?)
Consider what reporting questions may be asked (Who went over budget? How much are we spending on this category?) and then consider the query to answer the question.
Read up on 3NF and maybe some of the higher normalization levels as well. Whereas 3NF is pretty nearly the minimum normalization, the higher levels become increasingly specialized and may or may not be appropriate for you design.
The better you understand your data AND business, the better your design will be, and the better your end product will turn out.
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.
So I have this application that I'm drawing up and I start to think about my users. Well, My initial thought was to create a table for each group type. I've been thinking this over though and I'm not sure that this is the best way.
Example:
// Users
Users [id, name, email, age, etc]
// User Groups
Player [id, years playing, etc]
Ref [id, certified, etc]
Manufacturer Rep [id, years employed, etc]
So everyone would be making an account, but each user would have a different group. They can also be in multiple different groups. Each group has it's own list of different columns. So what is the best way to do this? Lets say I have 5 groups. Do I need 8 tables + a relational table connecting each one to the user table?
I just want to be sure that this is the best way to organize it before I build it.
Edit:
A player would have columns regarding the gear that they use to play, the teams they've played with, events they've gone to.
A ref would have info regarding the certifications they have and the events they've reffed.
Manufacturer reps would have info regarding their position within the company they rep.
A parent would have information regarding how long they've been involved with the sport, perhaps relations with the users they are parent of.
Just as an example.
Edit 2:
**Player Table
id
user id
started date
stopped date
rank
**Ref Table
id
user id
started date
stopped date
is certified
certified by
verified
**Photographer / Videographer / News Reporter Table
id
user id
started date
stopped date
worked under name
website / channel link
about
verified
**Tournament / Big Game Rep Table
id
user id
started date
stopped date
position
tourney id
verified
**Store / Field / Manufacturer Rep Table
id
user id
started date
stopped date
position
store / field / man. id
verified
This is what I planned out so far. I'm still new to this so I could be doing it completely wrong. And it's only five groups. It was more until I condensed it some.
Although I find it weird having so many entities which are different from each other, but I will ignore this and get to the question.
It depends on the group criteria you need, in the case you described where each group has its own columns and information I guess your design is a good one, especially if you need the information in a readable form in the database. If you need all groups in a single table you will have to save the group relevant information in a kind of object, either a blob, XML string or any other form, but then you will lose the ability to filter on these criteria using the database.
In a relational Database I would do it using the design you described.
The design of your tables greatly depends on the requirements of your software.
E.g. your description of users led me in a wrong direction, I was at first thinking about a "normal" user of a software. Basically name, login-information and stuff like that. This I would never split over different tables as it really makes tasks like login, session handling, ... really complicated.
Another point which surprised me, was that you want to store the equipment in columns of those user's tables. Usually the relationship between a person and his equipment is not 1 to 1 and in most cases the amount of different equipment varies. Thus you usually have a relationship between users and their equipment (1:n). Thus you would design an equipment table and there refer to the owner's user id.
But after you have an idea of which data you have in your application and which relationships exist between your data, the design of the tables and so on is rather straitforward.
The good news is, that your data model and database design will develop over time. Try to start with a basic model, covering the majority of your use cases. Then slowly add more use cases / aspects.
As long as you are in the stage of planning and early implementation phasis, it is rather easy to change your database design.
I have an application which handles the creation of different shop entities.
The process:
1. User registers to the website
2. User creates a shop (with various attributes)
What I have so far for database tables is:
[USER]
user_id
[USER_TO_SHOP]
user_id
shop_id
[SHOP]
shop_id
The above design covers the need for 1 user to have many shop entities under their account.
What I want to achieve now, is to have shop entities which are standalone but also have shop entities which are a part of group of shops
Chain of Shops example:
McDonalds Address X Chicago
McDonalds Address X New York
McDonalds Address X Boston
How should I proceed with my database design in order to support chain of shops but also standalone ones? Best practices are really appreciated!
*by standalone I mean a shop entity that does not belong to a chain
Off the top of my head I'd have a locations table and rename shop to company so single companies go into that table but can have multiple locations. Then users are associated with a company location.
There are many ways to achieve what you want, so, answers will be subjective since we don't really have the whole picture.
From what you're saying, a shop can belong to between 0 and 1 chains? If so, I would simply add one extra table and add a foreign key to the shop table:
[CHAIN]
chain_id
chain_name
[SHOP]
shop_id
chain_id
Well, for chains, you could have something like this, just like you have for users:
[CHAIN]
chain_id
[CHAIN_TO_SHOP]
chain_id
shop_id
Not sure what you mean by a standalone shop though - if you mean a shop that isn't owned by a user or a chain, could be something like this:
[STANDALONE_SHOP]
shop_id
But I would question the need for such a table, since a standalone shop could be assumed by an absence of an entry in CHAIN_TO_SHOP or USER_TO_SHOP
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.