I have a question regarding extending a table in mysql.
Let's assume that we have a user table
User:
user_id
user_name
Let's assume that this is user is used in a company which has multiple departments.
Now if the HR department want the user to have birthday and hire date fields only, but finance department needs the bank account id and years of service fields only.
I think I need to have another table, but I don't know how will it look like.
How can I make the table flexible in a way that it can be extended based on the needs?
Related
Introduction
Currently I'm designing a database structure for my university. I want to store student personal data and staff (non student) data. FYI, the total number of student's records is about 136K, incrementing about 10K each year. On the other hand, staff's records is only about 3K (slow incrementing).
Problem
I argued with my friend about three options below:
Create Person table, staff table and student table. The last two is inherited from Person table.
Create Person_staff table, staff table (inherit from person_staff). Then, same goes to student, create Person_student, and student table (inherited from Person_student).
Create Staff and Student table.
My opinion, option #1 is the best choice. But my friend argued that if we do that (option #1), we will have slow query when we need to retrieve only staff data, because had to join with Person table which is filled with student records (significantly larger than staff records).
Any advice for me? Thanks in advance.
EDIT: FYI, we need to be able to track each person (whether staff or student) who was once a student or staff.
I have three table users, cars and enquiries and their design is like:
users:
id ,name, email
cars:
id,user_id,name
Enquiry:
id, car_id,description
I just want to know that should I have to keep user_id in Enquiry table or not.As I know that i can fetch user detail with reference of car_id of cars table.what is the best way to manage these kind of things.
Thanks in advance.
If you remove the user_id from Enquiry table, you have an implicit assumption in your design that the enquiry is aways created by the car owner.
Is this assumption acceptable to you?
This may be very subjective, but talking about correctness, my opinion is that you should keep the user_id because Enquiry itself is an entity and should have its own owner.
It is based on your reports but I would say, you will not require the extra user_id as everytime you would be joining all the table for detailing the user info and car info with the Enquiry taken.
Hello Stack Overflowers,
I'm redesigning a system for an ordering group.
We have a hundred or so companies (ordering accounts) that order from us.
And maybe 40 of those companies also have online stores (admin accounts) with us.
An online store has a customer list of users that belong to their store, and the admin account lets them create and manage customers and customer orders.
So the customer shops, and when finished the order goes to the company.
The company verifies the order (combines orders to save shipping if they want) and then send it(/part of it) to us or fill it(/part of it) from their inventory.
We pack their order at our warehouse and ship it to the address on the order.
And we invoice the company.
The company then settles payment with their customer. (we never bill a customer directly)
Hopefully that wasn't too convoluted...
So again, we never bill a 'customer' directly. But in our current system, we store all accounts (ordering, admin, AND customers) in the same way.
While considering the redesign, I've questioned if this is the most logical approach. And I was thinking of storing our billable accounts (ordering and admin) in an accounts table and customers in a separate customers table.
The way I was thinking of setting this up was, our accounts have an accountID XXXXX, while users have a similar userID YYYYY, but are identified by a composite key of the two (XXXXX-YYYYY)
So company A's first customer is AAAAA-000001 and company B's BBBBB-00001. This seems fine when I think about things like customer orders being billed to their parent company, and displaying all of a companies customers, etc.
But is it a bad idea to have a customer table where customers non-unique customerIDs, even if that isn't the Primary Key?
I know I could make it work, but is it suboptimal when doing something like a customer_address table that relates a customerID and an addressID? Wouldn't it then need to use an accountID + customerID right?
Originally I was thinking they would all be accounts, and the account number would just be structured that way AAAAA-00000 being the admin account, AAAAA-00001 being customer 1, and so one.
But that brings me back to, should our accounts table treat our clients/billable accounts and their customers the same?
Sorry if this question is kind of all over the place. I think that demonstrates how unsure I am of how it should all be structured...
Any input would be greatly appreciated.
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 7 years ago.
Improve this question
I'm trying to figure out a good way to build a database for events. I have a client that has a list of customer names and promo codes. A customer on the list can go to a landing page, fill out the promo code and choose an event from a drop down field they would like to attend. He currently has 4 events ready to go.
In the database, should I create 4 tables, one for each event with customers or separate the customers from the event tables (ie...customer table and 4 event tables). There might be more events in the future so scalable options would be preferred.
Also, each customer is only aloud a maximum number of 4 tickets and they can only use the promo code once.
Thanks!
Jay is correct that a complete answer would be quite long, but I'll offer a few starting pointers nonetheless as it sounds like you're quite new to database architecture.
As a general principle, you should never build a schema that involves adding/removing tables at run time. The relationship you're looking for between customers and events is many-to-many, which in MySQL would use a junction table. An example schema would look like this:
customer
customer_id (primary key)
email, name, etc.
event
event_id (primary key)
name, time, etc.
ticket
ticket_id (primary key)
customer_id (index)
event_id (index)
date_purchased, etc.
Rules like "each customer is only allowed 4 tickets" should be implemented at a code level rather than a schema level since that is subject to change and your schema should be flexible enough to accommodate that change, tempting as it may be to have four columns in the customers table for the four tickets.
To get the events that customer ID 1 is attending:
SELECT DISTINCT event.*
FROM ticket
LEFT JOIN event ON ticket.event_id = event.event_id
WHERE ticket.customer_id = 1
To get the customers attending event ID 1:
SELECT DISTINCT customer.*
FROM ticket
LEFT JOIN customer ON ticket.customer_id = customer.customer_id
WHERE ticket.event_id = 1
A common format for junction tables is to combine the two table names, as in event_customer, but in this case calling it ticket makes more sense, since you might be including additional information about the ticket purchase in that table.
Let's say I have a table which represents Users:id, name. The table is huge, about 100 million rows.
Also users have some property, lets say City of birth. This is optional field so only a small part of users (let's say only 5%) have provided it. So I also have a table with cities: id, name. Relation is 1 to many - user can have only one city, and the a city can be a bithplace for many users.
The question is: how to connect them?
a) Adding a column city_id to the users table. (doomed for 95 millions nulls for users who don't have the property)
b) Creating a third, conjunction table user_city: user_id,city_id (With purpose to omit that huge number of NULLs if a).
Also, please, keep in mind that the application needs to
select user.name ... where city_id=xxx
So the city_id column needs to be indexed in any case
Because any non-alien user has only one birth city (unless he was born in a taxi), it seems silly and wasteful to have a table of birth city indexed by User ID. I would put birth city right in the user table where (as I claim) it belongs, notwithstanding that most city fields will be NULL.
But, forgetting my mere opinion, this is the classic time vs. space problem, the space consideration being the millions of extraneous, useless NULLs; and the extra time being the millions of extraneous, useless SELECTs into the city table.
What does your solution to that problem tell you?