Scenario:
I have the task to add a new field on a form, which is called account number. When a user clicks submit, it goes and submit the appropriate data to the appropriate tables...not important.
Currently, the tables that are involved are 3: customers, orders, and accounts.
The tables structures are:
Customers -> customer_id (PK), ...
Orders -> order_id (PK), customer_id (FK), ...
Accounts -> order_id (PK), account_number, ...
As you can see, a customer can have many orders, and each orders can have only one account.
Even though in the table structure I added PK and FK, the database engine is actually MyISAM, which doesn't support transactions and relationships. To add "relationship" between tables, the previous developer(s) decided to add the appropriate PK and FK to "fake" the relationships between tables.
PLEASE NOTE: I did not have any part of creating the database and tables; it was given to me as is.
The business logic is that a customer can have only one account.
As far as I know, the way the tables are mapped out, a customer has more than one account.
Without redesigning the tables, it looks like that I don't have a choice.
This is what I have in mind without redesigning the tables:
Create a SQL script to clean up and update account numbers in accounts, so that each account will have the same account number for a particular customer...even though a customer has many oders.
Anywhere in the web app that can insert an account number, I have to check to see if the customer has an account number. If so, then come back with a message stating that the customer already has an account number...maybe select the account number or update it with a new one. If not, then insert it.
Any better options?
By the way, I'm using MySQL and PHP/CodeIgniter.
Related
I have created a database with many tables but at the moment, i am concerned with 3 of the tables i have. Company table, Manager table,Customer table.
Now every company has one manager to use the application so with that, it has a one to one relationship and the table looks like this
Company
name
email
phone
manager_id
Manager
id
name
But then, every company can have lots of customers and each customer can belong to more than one company. In respect to that, i made a many to many relationship with the manager table to create a pivot table.
Because i want to avoid duplication, in the customer table, phone is primary. Will this relationship avoid the duplication. I want to be sure of this before i start writing my codes..
I am a newbie with database design. Thank you
Manger_has_customer
manger_id
customer_id
PS: This is how the customer table looks like
Customer
id
name
phone
In my simple system there is a users table where user logins and passwords are stored as well as a customers table.
Users can be related to customers in 3 different ways.
1) Sales Representative to the customer
2) Lead generated by this customer
3) Customer account entered by this rep
Originally I planned on having all on the customers table:
customers.user_id customers.lead_id customers.entered_by_id.
With CakePHP is this the wrong way? How should it be designed?
I am 1 day new to CakePHP.
Without knowing more about what you are building and your requirements, this is what I would do:
users: contains just authentication info
users.role: useful for querying what role a specific user is (customer, sales rep, admin, etc.)
users.username
users.password
sales_representatives: contains sales rep data
sales_representatives.user_id: Links the sales rep data to a specific user
customers: contains customer data
customers.user_id: Links the user to a specific user (assuming you want them to log in, if not you can skip this)
customers.sales_representative_id: Links a customer to a sales rep. You might want to store a history of sales reps for a specific customer in a separate table, but this field is just the current sales rep.
customers.lead_id: Links to a specific lead this customer came from. Can be null in case it was inbound and not a lead, but will probably link to something useful.
leads: Contains lead data
leads.sales_representative_id: Contains the current sales rep for a given lead. As with the customers table, you might want to store a list of historical sales reps for a given lead in a separate table.
You might also optionally add a user_id to the lead table if a lead can login, but that might not be the case in your system.
What is your entered_by_id? That seems more like a lead-related id, in which case you may want to track that in the leads table (separate from the sales_representative_id).
Most of this stuff isn't CakePHP-related, though good schema planning will go a long way to making using CakePHP easy :)
i have three tables to store details of different types of uses: customers, suppliers, staff
here are the structures of them,
customer(id,f_name,....)
supplier(id, name, address....)
employee(id, name, job_title....)
now i need those to log-in to the system , the log-in details stored in separate table,
user(user_id, password, role, ref_id)
how i planed to work this is, when registering some one, firstly insert the record to customer, supplier or employee according to the person, then insert a record in to the USER table in which the "ref_id" is the id of the previous table. the user is provided the "user_id" which can not be changed and they can change their password themselves.
when log-in, check the user_id, password combination, if ok then takes the ref_id and type, the appropriate table can be determined by the type which may be customer, supplier or employee....
the reason i done this in above way is,
customer, supplier and employee table has many different attributes except few like id, name...so can not maintain all the data in one table. in this situation if we use ids of customer, supplier and employee..would provide duplicate ids because they are separate tables!
so i need to know,
Is it correct the way i have implemented the authentication ?
if it isn't what is the correct way? (please mentioned that the details of the three parties should be handled separately)
i need to define relationship between supplier, customer, employee --> with user table. so is it ok to define three relationship as follows or another solution, how if the user table keep alone without relationship? is it violate the relational database concept?
customer (id-pk) ---->user (ref_id-fk)
supplier (id-pk) ---->user (ref_id-fk)
employee (id-pk) ---->user (ref_id-fk)
I am building a web application that has users and orders. I have a question about how to handle the relationship between the two.
An order belongs to a user. But here's the twist, a user can optionally choose to outsource an order to another user.
When an order is outsourced, the original user still remains the owner and only he can modify certain things like price, quantity etc on the order.
The user the order is outsourced to can view some of the order information and can update specific properties on the order like marking as fulfilled.
An outsourced order should show up on both users "orders index".
All the users are "equal" meaning on certain orders a user might be the owner and on others he might be fulfilling the order. A user can also fulfill his own orders.
It doesn't seem like a true many to many relationship as one of the users doesn't really own the order, he just has limited access to it.
What would be the simplest way to handle this order/users relationships? I would like to avoid using a complete permission system, is there a way to simply handle this with an "outsourced" table? How about having a user_id and outsourced_to field on the order table?
Thanks for your input!
If it's of any help, the application uses Laravel.
It seems like your Orders table has two separate relationships with the Users table.
Orders have an owns/owned-by relationship to Users.
Users(1) -- owns -- (*)Orders
One User can own many Orders. One Order is owned by only one User
Then there is a completely separate outsourced-to relationship between Orders and Users.
Orders(*) -- outsourced-to -- (1)Users
(Here I assume that an Order can only be outsourced to one other User. A User may have many Orders outsourced to them.)
The best way to represent this is to have the Orders table have a 'owner' foreign key column into the Users table and another 'outsourced_to' foreign key column also to the Users table.
What columns of Orders the outsourced user can edit will be controlled by the code and not by the dB.
A separate outsourced table will be needed only if Orders can be outsourced to multiple Users at the same time.
How about having a user_id and outsourced_to field on the order table?
Sounds good.
Also, think about a kind of de-normalization, like moving fields, which editable by "outsorced-to" user to separate table.
I may not be asking this in the best way possible but i will try my hardest. Thank you ahead of time for your help:
I am creating an enrollment website which allows an individual OR manager to enroll for medical testing services for professional athletes. I will NOT be using the site as a query DB which anybody can view information stored within the database. The information is instead simply stored, and passed along in a CSV format to our network provider so they can use as needed after the fact. There are two possible scenarios:
Scenario 1 - Individual Enrollment
If an individual athlete chooses to enroll him/herself, they enter their personal information, submit their payment information (credit/bank account) for processing, and their information is stored in an online database as Athlete1.
Scenario 2 - Manager Enrollment
If a manager chooses to enroll several athletes he manages/ promotes for, he enters his personal information, then enters the personal information for each athlete he wishes to pay for (name, address, ssn, dob, etc), then submits payment information for ALL athletes he is enrolling. This number can range from 1 single athlete, up to 20 athletes per single enrollment (he can return and complete a follow up enrollment for additional athletes).
Initially, I was building the database to house ALL information regardless of enrollment type in a single table which housed over 400 columns (think 20 athletes with over 10 fields per athlete such as name, dob, ssn, etc).
Now that I think about it more, I believe create multiple tables (manager(s), athlete(s)) may be a better idea here but still not quite sure how to go about it for the following very important reasons:
Issue 1
If I list the manager as the parent table, I am afraid the individual enrolling athlete will not show up in the primary table and will not be included in the overall registration file which needs to be sent on to the network providers.
Issue 2
All athletes being enrolled by a manager are being stored in SESSION as F1FirstName, F2FirstName where F1 and F2 relate to the id of the fighter. I am not sure technically speaking how to store multiple pieces of information within the same table under separate rows using PHP. For example, all athleteswill have a first name. The very basic theory of what i am trying to do is:
If number_of_athletes >1,
store F1FirstName in row 1, column 1 of Table "Athletes";
store F1LastName in row 1, column 2 of Table "Athletes";
store F2FirstName in row 2, column 1 of Table "Athletes";
store F2LastName in row 2, column 2 of table "Athletes";
Does this make sense? I know this question is very long and probably difficult so i appreciate the guidance.
You should create two tables: managers and athletes
The athletes table would contain a column named manager_id which would contain the id of the manager who signed the athlete up or NULL if the athlete signed himself up.
During output, create two CSV files (one for each table).
Further reading:
Defining Relationships
If you will retain the names for a future submission, then you should use a different design. You should also consider if a manager can also be an athlete. With those points in mind, consider having three tables: PEOPLE, REGISTRATION and REGISTRATION_ATHLETE. PEOPLE contains all athletes and manager. REGISTRATION is the Master table that has all the information for a submission of one or more individuals for testing. REGISTRATION_ATHLETE has one row for every Athlete to be tested.
People table:
---------------
People_ID
Type (A for Athlete, M for Manager B for Both)
First Name
Last Name
Birthdate
other columns of value
Registration table:
-------------------
Registration_ID
Registration_Date
People_ID (person requesting registration - Foreign Key to PEOPLE)
Payment columns....
Registration_Athlete table:
---------------------------
Registration_ID (Foreign Key to REGISTRATION)
People_ID (Foreign Key to PEOPLE)
I am not a mysql person, but I would think this simple type of structure would work.
Finally, storing credit card information is problematic as it runs into PCI (Payment Card Institute) rules, which you will want to avoid (think complicated and expensive). Consider processing payments through a third party, such as Google Checkout, etc. and not capturing the credit card.
Well based on your comment reply and what you are looking for. You could do this.
Create one database for Registration.
Create the columns ID, name, regDate, isManager, ManagerID (Whatever Else you need).
When a Manager enrolls set isManager to 1 and form a hash based on name and regdate, that would be the Managers Unique ID that would be added to all of the Athletes entries that the manager registers.
When a lone athlete registers don't worry about the ID and just set isManager to 0.
I think I may be oversimplifying it though. Wouldn't be the greatest for forming different types of queries but it should be alright if you are trying to minimize your db footprint