I am trying to create a subscription based payment module for a project.
There are three plans
Will cost 49$ but right now it will be free till we acquire users.
499$ which will have 15 days trial
799$ which will also have 15 days trial.
We are using Stripe for Payment Integration.
I have a users table with as follows
users(name, email, password, ....)
Now i want to store the following
Define and Maintain Plans
Which plan a user is subscribed to
When a user is subscribed to a plan - details regarding the payments - upgrade - downgrade etc.
Can some one share how i can do it via Mysql tables and if i am missing any key information that i need to store ?
Here it is a little sketch of what i would do in this scenario :
Tables
Users
id, nameemail, password, ...
MaintainPlans
id, user_id, name, ...
Payments
id, name, user_id, ...
Operations
id, type, user_id, name, ...
Notes
The user_id field reference of course the id primary key of the user table
Each tables can,of course, contains more columns containing more information or relations(i have inserted only the essentials.
The Operations type field should contain an enumeration with the possible value (upgrade, downgrade), could be defined into and enumerator or into another table referenced (even better) ...
Related
I have created 3 tables: accounts, products, claims. These are the relationships:
Accounts: PK - username
Products: PK - serial number, FK - username
Claims: FK - username, FK - serial number
My issue is that a user can add a claim even for products the user has not purchased, as long as the user knows that serial number, while I should allow the user to add a claim only for products the user purchased. For inserting claims I am using this query:
INSERT INTO claims (username, serial_no, date, issue) VALUES (%s, %s, %s, %s)
Do I need to change the table relationship with keys to fix the above, or use a more specific query? Better, what is the logic behind how this is supposed to work?
You should filter the products by username of the current user to avoid claiming products that are not related to the user. If you filter the product to be claimed then you won't need to change your table structure, it's only up to you on how you'll implement the filter in the programming language you are using.
First select all the products related to the user.
SELECT * FROM products WHERE username=#currentusername;
Then in your program, just allow the user to claim only from the fetched products.
I'm trying to implement a flight booking system, and the use case is as follow:
A registered customer should be able to buy several tickets, not only for himself, and for each ticket the passenger info would be recorded.
In the database design, I have two tables -- a ticket table, and a purchase table. Tuples in the ticket table records only information with the flight and the passenger, and each ticket has a unique ticketID as primary key. Inside the purchase table, it has a foreign key reference to the ticket table, and has attributes that indicate which registered use this purchase record belongs to.
Now, suppose I have several tuples of passenger data sent to the server, the first thing I should do is to insert new tickets, and then I could perform insertion on the purchase table indicates the relation between each tickets and the person who bought the tickets. Notice that the new records in the purchase table would have ticket_ids which were just created by new tickets.
My confusion is: how do I implement this within one operation as a whole? ** In the purchase table, I would also give the tuples that are created by the same customer in the same transaction an ID, indicates that those tickets belongs to the same purchase records. ** Could I achieve this using a stored procedure? I feel like the passing of data is tricky, since I'm very new to stored procedure, etc.
Suppose I have a login table containing id, username, password, type, and linked_id
The type column specifies whether that login belongs to an employee or a client.
If they are an employee, linked_id is their ID in the employee's table.
If they are a client, linked_id is their ID in the client's table.
Intuitively, this seems like a bad idea, but other than dealing with foreign key constraints, I can't think or a reason not to.
This also brings up another question: Is it ALWAYS important to have FK constraints in situations like this?
Thoughts?
I think you are thinking about your table design incorrectly. I would have the login information in one table and then point to the login record from the appropriate table. In other words, point to your login record from the employee and clients tables rather than pointing to a client or employee record from the login record. That allows you to have your foreign key constraints and removes the need for an extra field of "type"
As an example:
Login: Id(PK), Username, Password
Employees: Id(PK), Name, EmployeeNumber, Login_Id(FK_LoginId)
Clients: Id(PK), Name, Address, Login_Id(FK_LoginId)
Then, you inherently know what "type" each login is by what table the data is stored in.
The easiest solution would be to simply add an additional column in your database and have EmployeeId and ClientId to make the table structure easier to understand.
You could also argue that you're missing an Entity in your database design. As an example, what if an Employee was also a client? How would the current system deal in that circumstance?
You could have an intermediate table to manage this and determine the status of that Person.
I.e. have the table Login.
Fields: ID, username, password, type, PersonId
And then another table Person with the EmployeeId and ClientId, although I do think this would cause a lot of NULL values it would support the above circumstance I have described.
As an additional note, I would not want to look at the existing Login table, identify the linked_id field and then have to decide which table this column relates to, Employee or Client?
You could also split this out like #randyh22 has suggested and remove the linked_id field altogether and have the Login identifiers in the child tables (Employees and Clients).
Restructure:
Login table: LoginId, Username, Password (Ensure it is hashed)
Employee table: EmployeeId, Forename, Surname, LoginId
Client table: ClientId, Forename, Surname, LoginId
I had to implement the following into my database:
The activities that users engage in. Each activity can have a name with up to 80 characters, and only distinct activities should be stored. That is, if two different users like “Swimming”, then the activity “Swimming” should only be stored once as a string.
Which activities each individual user engages in. Note that a user can have more than one hobby!
So I have to implement tables for this purpose and I must also make any modifications to existing tables if and as required and implement any keys and foreign key relationships needed.
All this must be stored with minimal amount of storage, i.e., you must choose the appropriate data types from the MySQL manual. You may assume that new activities will be added frequently, that activities will almost never be removed, and that the total number of distinct activities may reach 100,000.
So I already have a 'User' table with 'user_id' as my primary key.
MY SOLUTION TO THIS:
Create a table called 'Activities' and have 'activity_id' as PK (mediumint(5) ) and 'activity' as storing hobbies (varchar(80)) then I can create another table called 'Link' and use the 'user_id' FK from user table and the 'activity_id' FK from the 'Activities' table to show user with the activities that they like to do.
Is my approach to this question right? Is there another way I can do this to make it more efficient?
How would I show if one user pursues more than one activity in the foreign key table 'Link'?
Your idea is the correct, and only(?) way.. it's called a many to many relationship.
Just to reiterate what you're proposing is that you'll have a user table, and this will have a userid, then an activity table with an activityid.
To form the relationship you'll have a 3rd table, which for performance sake doesn't require a primary key however you should index both columns (userid and activityid)
In your logic when someone enters an activity name, pull all records from the activity table, check whether entered value exists, if not add to table and get back the new activityid and then add an entry to the user_activity table linking the activityid to the userid.
If it already exists just add an entry linking that activity id to the userid.
So your approach is right, the final question just indicates you should google for 'many to many' relationships for some more info if needed.
I have 2 tables - one storing user information (id, username, password) and the second one storing information about events (id, name, description, date, username(represents the user who created the event)). I would like to implement 'favourite events' functionality. This would allow the user to store his favourite events and later display them in a list. I am not sure how to implement this in terms of design. I need a simple solution. Something like storing the IDs of favourite events in a field in the user table. I am using mysql and PHP. Can anyone point me to the right direction?
You want to have a table linking the foreign keys from the user and event tables.
Users Table:
id, username, password
Events Table:
id, name, description, date, username
Favorites Table:
id, user_id, event_id
This way you can easily access the list of favorite events.
SELECT events.name, events.description, events.date
FROM events, users, favorites
WHERE favorites.user_id = users.id
AND favorites.event_id = events.id
What you need is the most classic and basic many-to-many relationship.
You'll need extra table (let's say: user_event_ref) that will store user and event ids.
User:
id
name
Event:
id
name
UserEventRef:
user_id
event_id
In usereventref each column is a Foreign Key, and both columns are parts of Primary Key.
There's always the option to add a tiny-int field to the Events table flagging an event as a favorite. This doesn't violate normalization in that whether or not an even is a favorite has no effect on the other events. It has the added benefit of automatically deleting the event from favorites if the event is deleted.
If a sorting scheme is needed for the favorites you can still modify the events table in the same manner. If details about the "favorite" such as when it was added to the list etc is needed then you should use an additional table as suggested.