I was doing a mini project on Cryptocurrency tracking. I have a Users table in Mysql to store the details of registered users in my webapp.
When user logs in, they can see a table of cryptocurrencies. They can add a specific cryptocurrency as favorite from that table by clicking a button.
Now, when they click that button I want to store the id of specific crypto in a table. Since one user can add more than one crypto as their favorite, I can't store the CryptoId in a single cell. So, my requirement is, I need seperate "Favorite" table for every user. Whenever a new User registers, I want to create a new "Favorite" table for that user. How can I achieve this?
Please give me any solution or advice on this, or any alternative Idea on how I can implement this requirement of mine.
What you need is a many-to-many relationship table:
Users:
user_id
username
...
Crypto_Currencies:
cc_id
cc_name
UserCCFaves:
user_id
cc_id
Each time a user adds a favorite, you put a record in UserCCFaves linking the user and the crypto currency
Many-to-many relationships examples
Related
I have two tables in my database..one is candidates_details and another one is users..in the users table i have two types of users one is vendor and another one is user..they both have same user_id column...and i have that user_id column in my candidates_details table..
So what i want to do is when vendor post candidate_details by using form ..i want to store that user_id
(where user_type_id=1)
in candidates_details table automatically..
Can anyone help me..Thanks in advance..
Let me help you out by giving a pictorial example. Assume you have two tables users and candidate_details. In users you are keeping record of all the registered users along with their types. In Candidate Details you are keeping their profile data. You create another table where you keep user types Be it vendor, contractor, supplier etc.
Now when you create your form to post data in your admin panel or which ever interface you have. Just create a dropdown for user_types, get the type id and add the user. With the type id in your users table you can easily query which type of user that is.
Now for saving that user's profile information in candidate_details table you only have to provide user_id. So creating one more table will normalize your db schema and saves a lot of hustle in your query building.
I've been looking into the best way of storing an undetermined amount of information submitted by a user. A friend of mine suggested using nested tables, however these don't appear to be a thing in MySQL.
The application will allow users to store pieces of text information per day (each day is a blank slate so to speak)
What I have currently is
-Users
--ID
--email
--password
-Things
--UID (made from date and user ID)
--Thing1
--Thing2
This works fine. The UID is the users ID and the date combined (i.e 71420150404) as each day will be different but I'm open to changing this. The application checks to see if there are any entries for that UID and if there isn't, creates a new row.
The problem I have is I'd like the user to be able to select how many pieces of information they would like to add per day. So instead of the static 'Thing1, Thing2' the user could theoretically have this go up to 'Thing100', and I'm fairly sure adding these as columns isn't the best way to go about this.
I looked into if its possible to store an array in a cell and I'd access it like that through PHP but the research I came across all suggests I shouldn't do this. Creating a new table per user also seems very inefficient.
What is the best way to go about this?
I would create 2 tables:
entry table: id (auto increment), user id, timestamp - each time a user wants to store things a record is created and the id is retrieved using last_insert_id()
things table: id (auto increment), entry_id (foreign key to entry table), thing ( to store whatever the user wants to store)
If a user wants to store 10 things, then you create an entry record, then using its id you create 10 records within the things table. This way you are completely flexible on the number of things a user can store.
I have 4 tables,one is credentials(it holds an id, email and password), the other 2 are for business users and regular users of the app.
The business users table holds crID(foreign key)name,lastname,address etc...
The regular users table holds crID(foreign key),name,lastname etc...
The 4th is the booking table, it holds a bookingID, bookedfrom,bookedfor(the last 2 being foreign keys that point to the credentials table).
If a regular user registers in the site he closes a bookingslot and that is stored in the booking table, his name,last name are stored in the regular users table and his credentials in the credentials table.
The business user table just holds the business user for which a booking is made by the regular users.
Here is a graph:
db image
The question is what to do if a regular user does not choose the web to make the booking but makes a call. The business users are given the option to make the booking "manually" also. I am just having difficulty how to integrate that in the db.
As I see it I need to make the following:
Create a booking slot in the bookings table
Create a new regular user entry in the regular users table and at the same time create another column that would indicate if the user is registered or not.
create an entry in the credentials table but without password/email since this he will not be a registered user...he just made a booking using the phone.
WHat is your opinion.If you want I will post some show create statements. I think I made my point.
I would personally merge business users, normal users and optionally credentials in one single userstable.
Since I don't see the need of two seperate tables for your users, it would simplify drastically your data model. You just need a flag to determine if the user is a business user or a normal user.
For the rest, I think that having a null password is enough to determine if the user hasn't registered yet.
So, I've been developing a web app and came to this issue...
I need to audit every change that's being made on database tables, but since I have just one database user but a lot of users in my user table, I don't see how can I save into the audit table the exact user who did the change (since I'm doing that with a mysql trigger, and the trigger saves which database user is logged in).
If I don't get to that point of detail, I won't be able, for example, to know which employee changed some data, I just would know that it was made by an employee.
What's the best approach to solve this?
Is it a good practice to have one database user per user?
Is it a good practice to have one database user per user?
No
Have a table of users and mark items in the audit table with the users id (from the users table).
I'm creating a database users. I want to let users to choose notifications they want to receive by email.
Now I have the next columns in table users (boolean type):
notification_comment_photo.
notification_comment_comment.
notification_vote_photo.
notification_vote_comment.
notification_pm.
notification_followed.
notification_news.
What do you think, should I normalise table users and create another table notifications, considering that this table would have one-to-one relationship to table users?
Also I have the same problem with social links (twitter, facebook, google+, etc). Is it better to make a separate table links?
upd. Thanks all, I'll add the separate tables.
It's hard to answer your question, because you're not telling us what problem you're trying to solve.
One issue with your current design is that it requires a schema change for every new type of notification you want to store - if you want to notify users when they've been un_followed, you have to add a column to your users table.
I'd consider a schema like:
TABLE: users
------------------
ID
...
TABLE: notification_types
----------------------
ID
Description
TABLE: user_notifcation_subscriptions
-----------------------------------------
user_id
notification_type_id
subscribed (bool)
You could leave the "subscribed" column out of user_notification_subscriptions and decide that any record linking a user to a notification type means they have subscribed.
This design allows you to add new subscription types without changing the schema. I believe it's similar to the design #Daniel suggests, but he doesn't include the notification_type table, relying instead on name-value pairs. I'm not a fan of this - it can lead to silly, hard-to-find bugs when typos slip into the TYPE column.
You could (and probably should) create a separate table "notification_settings" or something.
ID
USER_ID
TYPE
VALUE
This allows you to easily add notification settings without messing with the database tables. Having a "strict" structure as you suggested sometimes gets in the way in the end and would be harder to expand.
For your social links, you should do the same. Another table named "user_social_accounts"
ID
USER_ID
NETWORK_ID