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.
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
okay so I have two ways of doing my database I have two different users with different fields but that will mean that I need two different tables and that will mean more coding etc.. that's inefficient
the users table:
first_name, Last_name, email, password, dis,
the other user table:
business_name, business_email, password, dis, posts,
I need help how do you recommend I do my login? with 2 different tables should I combine them? or should I have two login pages or something?
I am using PHP and MySQL this is not and school project this is for a commercial website I know most of you say I need to use a framework but I don't want to so.
Maybe you can try to use this
user (user_id,first_name, Last_name, email, password, dis, role)
business(business_name, posts, user_id)
and you can add relations between user and business table. you can add role for different types of users with type data enum('type1','type2')
First Approach - You can login with user type if he has business email or not and use 2 separate tables like you mentioned.
Second Approach - If your service needs to have both user and business email for each user, then you can even merge the tables for login. You can define one to NOT NULL.
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 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 3 years ago.
Improve this question
I have multiple products/environment, like Google has drive, docs etc.
One common Auth server is there which will contain users table.
But I have roles table related to each product, which contains roles for user for respective product.
Now how to manage this roles table?
I have following ways to do this, which one is better and why?
Create common table roles in main schema, and have product ID to link the records in table.
Have different table in same schema with prefix product_name. Eg. prod1_roles, prod2_roles.
Have different schema in same database, for Eg. product1 schema contains product1 roles table and so on.
Which of the above approach should I go with? Creating different database for 1 table is not feasible for me. So I want to go with any one of above or any other better approach will be appreciated.
If all your tables could have the same columns, is better to have just one, in a central schema, using an product_id. You will use the same pattern for login all your users at different products. This make your security layer easyer to control. And this is an important feature.
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 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.