Suppose a table for products in database. Now product has an "image" field where i will place the image name "image.jpg". Now i want to display more than one images of same product. image1.jpg, image2.jpg , image3.jpg.How can i add these records into that product table in single field and how to implement it in PHP to display those images. And the same scenario in terms of size of product i.e medium, large, extra large etc.
I will assume you have already weighed the pros and cons of storing a file name instead of storing a BLOB.
This sounds like a 1-to-many relationship. You will want a table that holds -- at a minimum -- the file name and a foreign key (FK) for the product table. Then you can have multiple images pointing to the same product FK. After that, in order to get the image for a single product, you would just do a query such as:
SELECT img.fileName
FROM image_table AS img
JOIN product_table prod ON prod.id = img.prod_id
WHERE prod.id = ID_THAT_YOU_WANT
I'm ignoring issues with SQL injection, but you shouldn't. Don't just append the ID to the query.
Related
I've got some question(s)
How many tables should i create for my products ?
2???=products & products pics???
if yes then my mysql tables will be like that ?
1.products= p_id, p_name, p_descr, p_pieces, p_categ, p_subcateg(??) &
2.products_pics= pp_id, product_id, thumb, image, type (???)
Well im a little bit confused cause i think its not so necessary to use products_pics into the db anymore .
My product entries will be around 3.000 for the beginning . Can someone tell me what im going to write-do ??? Thank you very much !
You should make 3 tables
products
images
products_images
In table products you have id_prod (primary key), name_prod, and other.
In table images you have id_img (primary key), name_img or img_src.
In table products_images you link images with products, and structure should be like id (primary), id_prod, id_img.
This way you will not have a duplicate content in tables.
If you only have images / documents pertaining to products only, and you want to store them in your database, you can store the image as blob/longblob directly inside the products table as p_image for example.
But when you want to retrieve it you will get the binary data, so you should write it to a file or convert it to view it as image under browser.
And if you have multiple images for the same product, you should create another table and use p_id as foreign key.
However, it is not advisable to store images in the database, for more information please refer to : Storing Images in DB - Yea or Nay?
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).
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 products table which contains information about products.
Each products can have unlimited pictures. These pictures are stored in a folder named after their product's id, and that's fine as it is, I don't need database to store file names.
But each of these pictures have text captions.
My question is, what is the best solution for storing these captions data?
Should I create a table called products_captions, with the fields
product_id, image_name, caption_text
Or should I create a captions_array field in the product table, containing a serialized array of strings, with the array key corresponding to the file name?
Is there any standard for this???
As per your requirement you can create another table for storing the images name with their captions and product id so when you want to get the caption related to product you can get it by passing product id to the table.
store your caption in another table and map the Image and caption
for example
field column
--------------------
id int
Image Blob
captionID int
field column
----------------------
captionID int
cation varchar(50)
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.