I have an idea where a user can upload a maximum of 5 images for his or her gallery and can select one of them as his or her profile pic. Is it possible to save the names of all 5 pics in a single column, say, image? Or do I have to make 5 separate columns for storing these file names?
As an example, I could create a column called images and store values in this manner:
{"129cc68678d1e67d18d49d93cec040ce":{"filename":"129cc68678d1e67d18d49d93cec040ce.jpg"},"97ac1e22ea3fd6f02362233d8147ecb5":{"filename":"97ac1e22ea3fd6f02362233d8147ecb5.jpg","primary":true},"eeb239b4edff7e1a09246d38977a5646":{"filename":"eeb239b4edff7e1a09246d38977a5646.jpg"},"55a3810c1b0eaee039c753c12dccbc38":{"filename":"55a3810c1b0eaee039c753c12dccbc38.jpg"}}
Primary:true implies that it's a featured image/ profile picture.
Both of your proposals --- 5 pieces of information in one column and 5 columns --- are bad ideas. What if you ever want to change the limit to 4, or 6, or 20?
Normalize your data instead. Create a table for the images and another for the user-image relationships. In that second table, set a flag for the profile picture.
What you will want to do instead, is create another table to hold your image filenames. Your galleries table would hold an ID and the other info you are storing for the gallery, then your images table would have three columns. One for its ID, one for the filename, and one to store the ID of the gallery it belongs to (called a foreign key).
Related
I have a PHP frontend with an image gallery. The data/metadata for the images is pulled from a sqlite database table.
Now I'd like the user to be able to tag the images, e.g. giving image1 the tags "boat" & "fish", and giving image2 some other or the same tags. How would I set up the database for this?
My idea is to create a new table where each row is a tag with an ID.
But how do I add these IDs into the image details table to connect both tables? Afaik I can't simply add a new column to the image table that contains the tag ids as an array, since sqlite doesn't support that.
How could I do this?
Yes, you would have to create a new table for tags.
In your case, best thing would be to create an intermediate table, (let's call it image_tag) which has an image_id and a tag_id column. Now if you want to let's say assign two tags to an image, you can just insert 2 records in the image_tag table containing that image's id and the ids of the tags.
This is called a many to many relationship as one image could have more than one tag and more than one image could have one tag.
Maybe this could give you a rough idea:
Image Table
id path
1 image.jpg
Tags Table
id name
1 fish
2 boat
image_tag Table
id image_id tag_id
1 1 1
1 1 2
For more info, please refer to this.
If you don't want to use child table then you can add tag in same row same table using serialize fields.
Like,
$returnValue = serialize(array('fish','boat'));
ID IMAGE TAG
1 Image.jpg a:2:{i:0;s:4:"fish";i:1;s:4:"boat";}
And you can simply read this $returnValue = unserialize($row['TAG']);
I should begin by adding that i'm not very familiar with SQL and database structures, i know the basics but don't think that's more than that. I am trying to build a functionality which is supposed to add an article with unknown amount of images. Each article will consist of 4 parts: title, image or multiple images, description and price. The confusing part here is that one article may have more than 1 image, as so far i've only known how to upload single image at a time.
How do i upload multiple images into database at a time?
As for the database i was thinking of going for the following structure: 2 tables, 1st - 'articles' and 2nd - 'images'. the idea was to first upload the image into 'images' with random 16 character hash name and then post in 'articles' all article fields with a hash reference on the end of the row.
Is this a valid solution or are there any other, more efficient ways?
You will want to place a reference to the article that the images belong to in the images table. Ensure they are the same data type. The article_id will need to be unique (primary key)
When it comes time to retrieve the data in your app you can simply pull the images out that correspond to that article.
Article
--------------------
article_id
article_title
article_descr
article_price
Image
--------------------
image_id
image_article (foreign key links to article_id)
image_path
...
You can get creative and use a image_seq_no to indicate what sequence the image would appear in the article or some reference to paragraph or location.
I'm building a website in PHP to share my comics. I'd like to implement categorization to allow people to filter which comics they'd like to see.
I've asked this question before, but at that time my site's architecture was not using a database.I've since implemented a database (which is amazing, btw) so I need to change things up.
I'm thinking the way to do this is:
1) Make 2 tables: 1 for categories, 1 for images
2) Insert images into their respective tables based on which filesystem folder they're in and assign that table id
3) Insert all images into All_Images table with their newly assigned category id
4) Take in user input to decide which images to show. So, if user input = cat 1, then show images with category 1 id.
So, basically I need a way to initially assign categories to the images when they come in from the filesystem. Is there an easier way to do this? Do I have to create multiple tables?
Any thoughts on this?
Thanks!!
The normal way would be to have an images table (presumably with filenames rather than the actual images?) and then a one-to-many relationship to categories so that each comic can have more than one:
Table:Image
-----------
rowid: integer identity
displayname: varchar
filename: varchar
Table:Category
--------------
rowid: integer identity
displayname: varchar
Table:ImageCategoryLink
-----------------------
imageid: integer foreign key references Image:rowid
categoryid: integer foreign key references Category:rowid
Clear?
One table category with id and name etc, one table for image with id src name etc.
Two choices after that :
If an image has one and only one category, put a field id_category in table image
If an image can has several categories make another table image_category with id_image and id_category
Since you are a beginner (no offence) and I don't think there will be millions or cartoons in the table. Use a SET field (or ENUM if your cartoon can only have one category) for you categories.
There are people who will vote this down since there are some negative side effects of using this (mainly when you want to change the categories). But with a relative small table this will not have any effect.
This will be the easiest solution. If you expect the site to grow big, use a second table for your categories and join the tables.
I have a site that allows users to vote on images. Each image has a unique id number. For voting restriction purposes, I'd like to keep track of what each user has liked. How would I go about setting up a row in the USERS table that holds all the different id numbers of the images liked by this particular user?
You should not have all this information in your users table. I persume that you have one table with all your images and one with all your users. Create a table called "user_image_like" for example. And store "user_id" and "image_id". When the user presses like on the image your script will add "user_id" and "image_id" to the table.
When you wan't to see all images liked by a user you can easly get this by a simple sql query.
If you want to store such information in one table and in one field, I have the answer for you.
You can use either ways:
Store the IDs in a CSV format. When you fetch these values you can deal with them as you deal with a CSV file.
Store the IDs in an XML format. Then, you deal with it as any other XML file.
Regards,
This is a Many to Many relation. i.e. one user can like multiple Images and one image can be liked by multiple users.
According to normalization standards you should use these relation in separate table with user_id and image_id. whenever user like an image add a row to this table.
If you still want to store it in single table (users) then store ids in CSV format. be sure to store only unique image ids for each row.
Check this article
http://www.tonymarston.net/php-mysql/many-to-many.html
I have a MYSQL database of photo galleries;
each row contains a field with the list of images included in that gallery, eg:
1,5,134,13,5
these are the IDs of the photos. The same image_id could be included in other galleries.
When I delete a photo, I need to remove the corresponding id from the galleries that contain it.
What's the best way to do this in PHP?
I thought of EXPLODEing the field into an array, remove the value and then IMPLODE back and update the DB, but I'm pretty sure there's a better way?
thanks,
Patrick
THANKS Galen & all.
I'm a newbie and don't know much (=anything) about normalization. if I understand correctly, you're suggesting to have 2 tables: 1 with all the info about the photo (eg, image_id, name, caption, etc..) and another table with just a list of galleries that use that photo, eg:
gallery_id | image_id
1 3
1 7
1 5
2 3
2 8
so by deleting from this table WHERE image_id=3, i would remove that photo from two galleries.
In this case, however, I would I manage the order of photos? Having a string allowed me to have an ordered list of photos.
This is the exact reason why you normalize your tables. Then you could just run the query
delete from images where image_id=5;
delete from imageXgallery where image_id=5;
Where the images table contains all the image info. The imageXgallery table just contains image to gallery references.
I suggest you read up on normalization and update your tables.
EDIT: To allow for image ordering add an order field in your imageXgallery table. When you retrieve your images from the table you can order by that column.
While there may be slightly faster and more elegant solutions, exploding, cutting out and gluing together again is a perfectly acceptable way in my opinion.
Edit: Of course, Galen is right. If you have the chance, change the structure.
As Galen said, you need to normalize. Instead of a tuple (row) like ("gallery_id", "photo_id_1, photo_id_2, ...") you will have multiple tuples each having one gallery_id and photo_id. Then by deleting the photo_id from that table will take care of your problem.
If you don't want to change your table structure, it's probably less expensive to do string operations than to convert the strings into an array and back again. Look into using either str_replace() or preg_replace() for that.
If you can change the database layout, I would do the following:
As each gallery can have multiple images and as each image can be in multiple gallery, you have a many-to-many relationship.
So you have 3 tables, the first one to hold the gallery, with a galleryId primary key and additional fields for gallery info (if galleries have names, for instance, a name field), then you have an image table, with an imageId and all the image information, and then you have third table with just two fields, galleryId and imageId.
So if image 5 has to go to gallery 7, you'd enter 7 and 5 into the relationship table.
to get all the images for gallery 7, you'd run something like
SELECT * FROM images i LEFT JOIN galleryImages gi ON gi.imageId = i.imageId WHERE gi.galleryId=7
with galleryImages being the relationship table.
Likewhise, to delete an image from a gallery, just delete the row in the relationship table.
One thing you might want to pay attention to is to check if there are still entries for an image in the relationship table when you remove it from a gallery. or in other words, check if the images is being used in any galleries, if not, remove the entry from the images table as well, otherwhise you might end up with a lot of garbage image entries that aren't even needed anymore.
hope this helps to clear some things up.