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.
Related
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 2 years ago.
Improve this question
What is the best way to manage preferences for appointments in database? In my scenario a patient can send multiple preferences (slots) for appointments to a practitioner. The practitioner will approve the most feasible slot according to his/her availability.
How can I design a ERD so that I can allow different no. of preferences to different patients, e.g. patient A can send only 2 preferences based upon its pricing plan and patient B can send 5 preferences based upon its pricing plan.
It seems like you need a pivot table. It would need to have patient_id, practitioner_id, and preferred_time. The patient would create records in this table. When a practitioner approved a preferred_time, the data could be copied into this appointment table you are showing and expanded.
You can then add a hasMany preferred_time relationship to the patient model, and use that to interact with the data.
Any combination of patient and practitioner could have zero, one, or many preferred times at any given time.
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 4 years ago.
Improve this question
I'm trying to find the best solution for my needs. I have a budgeting application that each user will have their own budget which will include potentially hundreds or thousands of budget entries. Initially I thought I would have a table for the users and basic info, and then each user would have their own sql table with all of their budget items held within. However, if the user list grows to hundreds or thousands then I would have a large amount of tables since each user would have their own. I also considered a single table to hold everyone's budget entries but I'm not sure that's the correct solution either.
Any advice? Thank you in advance
I think a single table that holds all the budget entries, with a primary key that's referenced by a foreign key in the "users" table, is a good way to go. You can always use something like select * from users u join budgets b on u.userID = b.userID where userID = xxx to get the budget items for a particular user.
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'm working on creating a database for a gym to track the members info. I want to be able to track the times that people go so you will be able to see when it is busiest. I'm not sure how to go about this. Do I need to make a new table for the information of when a member goes or do I add it into the members or gyms table?
I would add this to a different table. You could make a new table with user_id which is the same as the users ID in the user table. It would then be quite easy to tie the visits to the users, if that’s a point.
Create a visits table with the following columns
visitId
memberId
gymId
entryTime
exitTime
The GymId column may not be required if your member is linked to a gym but it depends on your requirements
Think in terms of "domain" models. From your question it appears you already have Member and Gym models.
I suggest introducing an Attendance model.
Attendance
- UserId
- CheckInDateTime
This would translate to a new database table called "attendance" with the corresponding columns.
In order to see when is the busiest time - I would execute a "select count" statement on the attendance table and "group by" the check_in_date column (truncate the time portion).
A note on persisting datetime values. It is recommended to store the datetime value in UTC timezone. Then you can have your application convert the timezone accordingly when viewing the data.
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.
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 9 years ago.
Improve this question
I currently have 3 table and I am unsure if they should be merged or not. They do have similar fields, and a supplier would need to login at some point or another, and even clients
User
Username
Password
Name
Surname
Mobile
Telephone
Email
Client
Name
Telephone
Email
Fax
VatNo
Supplier
Name
Telephone
Email
Fax
VATNo
LastRefreshDate
OpeningHoursId
Can somebody give me a suggestion as he best way to go forward.
The tables should probably not be merged. However, that's a judgement call based on guesses about what the tables mean.
It looks like clients and suppliers can be corporate entities (VAT numbers, for example), but users should be individuals rather than collective accounts. You may well have a list of users associated with a given supplier; similarly, you may well have a list of users associated with a given client. In some circumstances, a supplier may also be a client. You would need a User ID number in the Users table; you would need a Client ID number in the Clients table and a Supplier ID number in the Suppliers table. You would have simple mapping tables to list the Users associated with a Client and another to list the Users associated with the Suppliers.
However, a lot depends on whether the guesses I've made (plausible ones, but nonetheless guesses) are remotely on target.