Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm writing a database that will match up care workers to clients. The carers visit the clients and assist them to get dressed etc. So the carer table holds there information such as what gender they are do they drive etc. If a client wants a female carer then I would check to see the gender of the relevant carer and all male carers would be excluded. I started down this route with my tables but soon discovered there was lots of combinations of questions and answers.
I don't know if this requires a many to many relationship but I'm a bit lossed off.
Any help would be gratefully received.
You should use a bridge entity to eliminate the many to many relationship between your Carer and Client tables. This Transaction table would also allow you to add additional transaction-based information to that entity such as Driver, etc... that wouldn't belong with either the Carer or Client.
Something like this:
Carer
Carer_ID PK
Name
Gender
Address
Vendor_ID FK -- Assuming your individual carers are part of a network
etc... Other Carer based details
Client
Client_ID PK
Name
Address
Gender
etc... other Client based details
Transaction
Transaction_ID PK
Client_ID FK
Carer_ID FK
DateTime
Location
Driver_ID FK -- Assuming you want to add a driver table
etc... Other transaction based details
As a follow-up... I personally disagree with those recommending the Entity-Attribute-Value design. EAV might be okay for basic look-up values in a front end application but basing your overall database design on it is a very bad idea (for integrity and maintenance reasons). It is much better to follow standard relational database normalization practices and create an entity table for each of your primary actors.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have an EER diagram of the hospital database. I am currently working on the normalization process.
As I understand the partial dependency is when an attribute is dependent on only the part of the composite primary key. And this should be removed.
I've applied the rules on my database but still want to make sure that these tables doesn't include partial dependency.
In examinationo table the composite key consists of inpatient_no, doct_no and lab_no. In my opinion diagnosis and conducted_test attributes depend on all three of them. Is this correct?
This table has composite key of inpatient_no, doct_no and surgery_no. The attributes date and time convey information when the inpatient will undergo the surgery. Is this a partial dependncy?
I'm very new to databases, so my quesitions can be quite easy.
It looks to me like your table called inpatient_undergoes_surgery represents an entity, in this case an event. The table has one row for each surgical appointment. It has date and time as attributes. It also has one-to-one relationships to an inpatient, doctor, and surgery.
This table appears to be normalized to me. The others might not be. In particular, it's possible that your surgery table duplicates the information in this table.
Pro tip It's best to use a DATETIME or TIMESTAMP data type to represent the kind of date and time in your table. There's no need to use separate columns for date and time. Understanding that the date and time taken together are actually a single attribute of your entity helps clarify your design process.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a table that will hold 'game stats'. The name of the stats that are held are going to be changing depending on which sport the stats are for.
Is best practice to make two tables: one for the stats with columns such as 'Stat1, Stat2' etc. and another one holding the titles with the sportID as a key. Or would the best practise to have several tables for resorts for each sport. Or any other way?
Thanks,
I agree with andy. A generic-titled column like Stat1 - where the purpose is unspecified in the column name, is used polymorphically, or the column type must be made more generic - usually indicates a poor SQL/RA design.
Consider if this were encountered: create table people (field1 varchar(20), field2 varchar(20)). Yeah - not going to fly in my database. Give the columns (and tables) names that mean something in relation to purpose.
Instead, each different type of information collected should have it's own entity (read: table) or group of related entities. In this case I would imagine that each sport represents a different type of collected stats/information. (Even Win/Loss information can vary by sport.)
Trying to "label" columns based on an additional table is a half-way attempt of an Entity-Attribute-Value (EAV) model. While an EAV can be useful it comes with a lot of downsides in SQL and should not be used except after very careful consideration for a specific use-case. (I do not believe that EAV fits this scenario appropriately.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am new to database design and would really appreciate it if you gave me the TL;DR of good database design and how I would apply it to my own project.
I need to design a database that will consist of
Employees
Employers
Employer settings
Employee settings
Messages
Employee tasks and
Employee locations.
The way that I was thinking of going about it was creating an
Employers table
Employee table
Employer settings table which references employees by id
Employee settings table
and relate the rest of the tables to the employees by id.
Is this a good idea?
Employers table.
Assuming this is not a person, but a company.
Employee table
Include employer id for employee's designation. You can use separate table for this.
Employer settings table
Focus more about the employer, and never relate this with employee
Employee settings table
Messages table
Include the message, employer id, and employee id in which the message is addressed
Employee tasks table
Include the task, employer id, and employee id in which the task is addressed
Employee locations table
This is mandatory if location has multiple values per employee. If not, you can include location on employee or employee settings table
The idea is good. If you're new to Db design I would recommend you to pay more attention on:
Defining references keys properly so data does get lost by accident
Manage created/updated timestamps for each record
Try to look ahead. i.e. What happens if employee changed his employer? maybe you need to persist effective from/to dates of employment rather that simple ID reference. Having full history of data in DB is always good idea.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm new to programming, and hope this question isn't too basic. I've searched the questions here but can't find anything exactly like it.
I'm making a website in which people have to complete a sign-in form and then answer a survey. The survey answers will drive how the site performs for each user (there will be different monthly reminders in email personalized to the survey responses). I have two MySQL databases, one for the sign-in and one for the survey.
How do I get the member ID in the member database to be the same as the survey ID in the survey database? Or am I thinking about this all wrong, and there's another solution?
I'm most familiar with PHP and JavaScript, so I hope that there will be a way to do this in the coding if not in the database design. Again, sorry if this is too basic and many thanks in advance for your help.
This is a terribly generic question to answer, but I hope I can help you a little along:
Now, assuming that you have a good reason for separating the user registration and the surveys in two different databases (you did not give a reason for it being so), after a successful user registration you can assume that the user is 'logged in'. This should mean that the ID of the registered user is available to you in code.
You do not have to have identical survey IDs and user IDs, it usually makes more sense to have a separate table knitting users and surveys together (with a user_id field and a survey_id field).
After setting up or saving the survey, store a record in this table, connecting the user with the survey.
If you were hoping for a more specific answer, I suggest you delve into a little more detail in your question.
Good luck!
Just some hints, they won't rock the house but probably good for a start:
Put the two tables in the same database. This is less a technical requirement, but it's easier for you. The two tables belong together, keep them in the same database.
It's okay to have two tables.
The member ID and the survey ID do not need to be the same. Instead add a memberID column to the survey table and set it to the appropriate ID of the member table.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a table called enterprise in my database. If the enterprise expresses its demand to my company, the enterprise will become our prospection. And after, if the enterprise accept my company's proposal, we will sign the contract, and enterprise becomes out client.
Now, I have created 3 tables which are enterprise, prospection, client.
So, how should I design the database?
One approach would be to have a table Companies, and the three tables you already have. All three tables have field CompanyId that has a foreign key constratint linkining it to the companies table. This design has the advantage that you have to keep the company information in one place and there is no duplication.
Another way would be to have a field in the companies table, that marks them as an enterprise, prospect, or client.
Which design you should choose largely depends on information for the different classes. If you thinking along inheritance (i.e. a client is a prospect is a enterprise) than the company table suffices. However, if ther is a large amount of information and the information is different for each of the three classes than the first approach would be better.
You should, however, always try to keep the information in one place, i.e. in one field/table (= fully normalized). In some cases you can deviate from this principle for performance reasons, but keep in mind that this also means a higher maintenance overhead - you have to update n tables when a value changes.