Im wondering if someone could help me out with a little issue im having.
I have some code which enables a user to click a button and it will create a additional file input box ... The amount of times they can click this is unlimited, so realisticly they can add unlimited images to their profile.
The problem im having is im not sure how to go about saving that information to the database, usually i would add a row for a file input and store the name, but as there can be unlimited amounts of filenames, im not sure how i would go about saving it.
Could anyone out there give me some suggestions on how they would do it?
Thanks
I would store additional pieces of information in a separate table. It only needs 2 fields, data and user_id, Then for each additional input, you would store the data and the user's unique user_id. To retrieve the data, just filter using the user_id.
Usually it's doing using 2 tables and foreign keys. One table with users(user) (id, name, ...). Second table with photos of users(user_photo) (id, user_id, photo_path, ...). Foreign key will be created between user.id and user_photo.user_id with cascade delete/update.
Related
I have a table, where I store user uploaded files. There can be 5 different file types: profile picture, cpr file, degree file, video file, background check file.
Table structure is this:
file_id, user_id, file_type, file_size, file_name, file_new_name, file_path, file_cat, date_created
My questions:
Is this structure efficient or should I create 5 different tables?
If I would like to update, lets say user profile picture row, then what would be the best way to do it? --- I came up with a solution that probably is not be the best one- I update the row where file_cat = "profile_picture" and user_id=:user_id. Would that put a lot of load in the system?
First when user signs up, he doesn't have any files. Should I user insert into ... VALUES ... on duplicate key update with a hidden value in a form?
Thank you in advance.
This is three questions not one.
Is this structure efficient or should I create 5 different tables?
One table is good enough
If I would like to update, lets say user profile picture row, then
what would be the best way to do it? --- I came up with a solution
that probably is not be the best one- I update the row where file_cat
= "profile_picture" and user_id=:user_id. Would that put a lot of load in the system?
Not if you have an index on file_cat, user_id (composite index on both fields). If you want to make things a bit leaner you can store constants instead of 'profile_picture' etc. eg
profile_picture = 1
cpr = 2
....
background = 6
This would make the tables and indexes a bit smaller. It might make the queries slightly faster.
First when user signs up, he doesn't have any files. Should I user
insert into ... VALUES ... on duplicate key update with a hidden value
in a form?
No need for that. not having a record for new users actually makes things easier. You can do an COUNT(*) = 0 query or better still an EXISTS query without having to fetch rows and examine them.
Update:
These EXISTS queries are really usefull when you are dealing with JOINs or Sub Queries for example to quickly find if a user has uploaded a profile picc
SELECT * from users WHERE exists (SELECT * from pictures where pictures.user_id = users.id)
If you use the primary key properly then your insert ... on duplicate key update ... query will do everything for you.
For your table you need to define a primary key column. In this case I would say it is your file_id column. So if you do your insert, the MySQL server will check to see if your file_id column is defined already for that value, if so it will update with the new values, other wise it will add a new row of data with the new file_id.
I should be easy enough to separate it though, make 1 script for creating new rows and another for updating. Usually you will know when you are creating as opposed to updating in an application. Again using a primary key correctly will help you out a lot. Using a primary key in your where clause I am pretty sure is one of the most efficient ways to update.
https://dev.mysql.com/doc/refman/5.5/en/optimizing-primary-keys.html
I'm currently in the process of creating a website and want to know how you guys think I should go about storing my information.
I'm making a website which allows users to create an account and then enter/log in workout information each day that they can.
Each time they input a log, there are a few pieces of information they must include (ie. the date, the length of their workout, the type of workout, etc.). The website will then be able to supply them with graphs that analyze their data.
I'm coding using php and mysql. My question revolves around how I should store all the data for the website. I know I need a mysql table that will have a column for id, username, email, and password. However, I'm unsure how to store the daily logs.
Should I create an array for each field (ie. workout duration) and use serialize() to store it in the same table as the users? If so, how would I go about updating the array each time a log is inputed? Thanks.
I would suggest to use several tables for this, for example the tables:
site_users
site_workouts
That way you have all user data stored separately. In your workouts table, you would add a new row per record, and include a foreign key (user_ID) that links each row to a user. So you could match a list of workout logs to a single user.
It's your choice but personally I would use 2 sql tables:
User(id, username, email, and password)
Workout(user_id, date, workout_length, workout_type)
This way you can keep adding logs for users and recieve the data when needed.
You keep comptibility with alot of other services.
And process the sql records with php.
When creating a many to many table, relational database. If for example you are enabling users to scrape images form around the web and tag them.
Would it be better to:
Check to see if the image is already in the database and if it is, create a link in a relational table and if it is not create a new image.
Create a unique instance of the image for every user and when looking to display the most popular images SELECT AND ORDER BY the image with the most duplicates
I hope this makes sense. Thanks in advance for you help.
I assume you have something equivalent to a USERS table and a PICTURES table. Also a table to break up the many to many relationship. U2P I will call it.
The option you listed as option 1 would seem to be the preferred way. Check to see if the picture is in the DB, if it is get primary key from PICTURES corresponding to it. If not, put the picture in the PICTURES table.
Regardless of if it is a new image, or one that is already in there, you will insert the event into the U2P table. This would reference the USERS primary key and the PICTURES primary key corresponding to the event. You would also record other data such as time etc...
I'm sorry if this a stupid question, but I am new to this. I want to store all the information from all my customers' different contact forms in a database so they can retrieve the information later. Each contact form has a different number of fields. Ideally I'd store all of this info in one MYSQL table, but as I said each customer's contact form has a different number of fields.
I was thinking of creating a database with the following fields
ID, customerID, dateTime, data
The data would be the html of the contact form. However I am sure that's not best practice. Also it wouldn't allow me to offer a download option to the customer of all their contact forms as a csv or similar.
I don't want to have a different table for each customer either, and I am sure having a table with 'field1', 'field2', 'field3' etc isn't that good either.
Any ideas?
If you don't need it to be relational, that would be fine. You wouldn't be able to query it very easily.
You could store the answers in another table using keys to link back to the form and field.
Or use a KeyValue store type DB like MongDB, and you could store all your data without worrying about the schema.
Make another table called user_data. In it, have:
id, user_id, data
Then, if they fill out a form with 10 fields, you can enter 10 entries into this table. When you pull data for the user, just also pull any data from the user_data table that has user_id = their id.
If you need more than that, you could also add a "field_name" field or something:
id, user_data, field_name, data
You can use the MySQL database to have a schema for your desired information that relates many tables to one another.
Here is another discussion about database design:
Database Design Best Practices
If you must have only one table, the other choice I would mention is to have the ID created automatically, and then make the fields be not required. This way when a customer fills out one form before the other it won't mess you up. You can then store the ID as a Session Variable and reuse it for different INSERT statements to your database.
You can make a download function for the customer that will output in the desired format that queries your table and then generates the file.
I have a table for storing the postman coverage area. It has two fields
postmanid
covering_pincode
What i am going to implement is, when a user enters a pincode in the textbox, the list of the postman covering that pincodes are displayed.
My doubt is, how can i enter the values in the table
1. Multiple pincodes stored in single row like
postmanid->1, covering_pincode-> 626123, 626124, 626432, 654564
OR
2.Storing each pincode by each seperate fields like
postmanid->1, covering_pincode->626123,
postmanid->1, covering_pincode->626124,
postmanid->1, covering_pincode->626432,
postmanid->1, covering_pincode->654564
Please help which one is best for searching the table by pincode
The rules of normalisation say: use the second one!
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
I'd store each one as a separate row in your table, this would make it easier to add/edit/delete new values without having to append to or extract individual pin codes.
Use a compound key on the database table and you won't need a primary key and shouldn't have duplication.
What you really want is a second table
covering_pincodeid->1,postmanid->1,convering_pincode->626123
covering_pincodeid->2,postmanid->1,convering_pincode->626124
covering_pincodeid->3,postmanid->1,convering_pincode->626125