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
Related
I created Users table.
After the user registered, The system enter his address, phone, city and more personal details to Users table.
There is another table, called Contacts, there the user add another people details.
Now, if there is Contacts table, How better to save the personal details of the user in Users table? in one json column that contains all the user personal details, or in normal columns (address, phone, city)?
I just do not want to happen a situation of multiple data.
I think separate columns for each field will be the better option!
Well, it would of course be easy to just store it as JSON, but that way, it could be a bit messy to search for certain stuff in the database (say you wish to check all users from a given city for example).
When it comes to user information, I always find the best way to do this is to store only login vital data and the base info in a users table.
Something like:
id | email | password
And then have different tables for the other data.
Name and such (which a user only has one of (of course one could have multiple names, but I usually only store first and last names)) could be stored in a user_information table, which is in a one to one relation with the user (foreign key for the user_id so that it can be quickly fetched when needed).
When it comes to address and phone number, a user could actually have multiple.
I understand that its possible that your system/app is only supposed to support one address or one phone number and the like, but its always nice to make it "right" from the start, so that its easy to just let the user add multiple of them whenever the need is there.
That way, you would have a few different tables:
users
user_information
addresses
phone_numbers
and so on...
The user_information, addresses and phone_numbers would preferably all have a user_id column which would be used for a foreign key to point at the user who owns it. And if you wish to make it possible to use the same tables for contacts, a contact_id could be added too (and a foreign key to point to the contact).
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 :)
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.
I am trying to get my head around an issue relating to database logic.
I have a system that is to allow the user to create an event, performances and multiple different ticket types for a given event. These will then be added to the database with prices relating to the ticket types for a given event (the ticket types can be reused for other events and there is no set number of types for each event) and then a customer will go onto the site, select one of the events, performances and will then have listed for them to choose from the different ticket types with prices.
At this point I have a table for events which is using a series to store the ticket ids which are stored in a separate table and yet another table which stores the prices. The use of the series is ridiculous as it tends to crap out on me and either fails to work (as mysql doesn't handle the code properly) or it is incredibly limiting on what can be done with the info Has anyone any better idea how I might achieve this result?
example of an event:
event name: 'event 1'
performance: '23/03/13 (12:30)'
ticket types: Adult (€20), Student (€15), Special (€10), etc
the person setting up the event can create any ticket types they want or use existing ones in the system and just have a price set for this particular event.
If I understand you correctly, I believe what you are doing is most likely the best way to do it.
A user can create multiple events, each of which can have a variety of tickets. Tickets are not specific to an event (can be used on multiple events), and thus the price can not be stored with the ticket information.
Therefore, what you want to do is have these tables:
events - Stores information on the event
tickets - Stores information on the ticket
*events_tickets* - a join table for events and tickets (As it is a many to many relationship)
The events_tickets table would have columns like so:
primary id, event_id (Foreign Key), ticket_id (Foreign Key), price
Hope that helps.
table Event: Id_Event, Ds_Event, Dt_Event, Id_Venue
table Ticket_Type: Id_Ticket_Type, Ds_Ticket_Type, Ic_Ticket_Type_Is_Custom (boolean)
table Event_Ticket_Type_Price: Id_Event, Id_Ticket_Type, Nr_Ticket_Price
table Venue: Id_Venue, Ds_Venue, Ds_Venue_Address
I am developing a web portal which will store the job requirement like, experience, salary etc in a database and whenever any user (new/old) matches that criteria the job should display him in his dashboard after he logins.
My Columns in employees are
Age, City, Industry, Marital status.
So, when admin post the jobs, he will define the criteria which user can see this. For ex. Age between 20-30, City only Mumbai like that.
How do I store these information in database efficiently.
I am using PHP/MySQL.
You would ideally create a table with the user's:
Unique ID
Name
Marital Status
City
Age
Create a second table to pair industry and UUID, like so:
Unique ID
Industry
This is so that a given user can belong to more than a single industry.
Third, create a table to pair user IDs and experience:
Unique ID
Position
Industry
Start date
End date
Since industry and experience are data which a given user can possess an arbitrary quantity of, you need to abstract the data into its own tables. Don't try representing all of this information in a single table - it's a solution that scales poorly past a single employer.
I'd also like to note that if your application is going to be deployed in the United States and several other nations, it's actually illegal for employers to discriminate based on age and marital status. I'm assuming this doesn't apply to you, but there it is.
in terms of speeding up your look ups, the most important thing you'll want to do is make sure you index the columns that you will be searching against.
So for instance, if you want to do a search that is based on someonen's start date:
like:
select * from tablename where start_date > 'some date';
then it's very important that you index the start_date column on the 'tablename' table.
Apart from making sure that your tables are orthongal deciding what the best way of setting up your database you'll want to ask your self what kind of questions will you be asking your database and design your tables around those questions.